Re: LTspice accuracy, used for calculations and measurements
On Sun, Apr 20, 2025 at 03:19 AM, Udo Huhn-Rohrbacher wrote:
Spice error log shows:
z_value: z=3.14159265359
?
To our surprise, we observed different results between users, although the same setup was implemented.
Mike Engelhardt¡¯s LTspice XV!! Help-file Copyright ? 1998-2018 Analog Devices Corporation Shows on page 105:
The following constants are internally defined:
Name Value
E 2.7182818284590452354
pi 3.14159265358979323846
Looks OK so far.? The value listed in the Help just has more digits (greater precision) than the values printed in the Error Log file.? It should be obvious why that happened.
?
Do you have the different values for pi that you found from different users?? Can we see them?
?
If the value differed in different LTspice versions, perhaps its value was updated internally.? Anything identified as LTspice 24 was done by Analog Devices, not by Mike Engelhardt as either an LTC employee or an ADI employee.? Mike's value for pi might have been unchanged since before 2000 when he started working on SwitcherCAD III which became LTspice III.? New pairs of eyes (after Mike left) may have noticed that pi's value needed to be corrected.
?
The solver was set to ?Alternate¡°. We assume, "Alternate" is 1000 times more accurate compared to ¡°Normal¡±
Let's be really careful about that statement.? The Alternate solver is not necessarily 1000 times more accurate, even if the wording in the Help suggests that.? The Alternate solver has about 3 digits more numerical resolution because of the way its numbers are stored internally, and that extra resolution could be capable of yielding better accuracy, but it does not guarantee it.? Accuracy is not the same as resolution.
?
Because SPICE/LTspice is a nonlinear circuit solver, what Tony said is true, that every result of a circuit calculation is an approximation and not exact.? This is not about numerical resolution or math calculation accuracy; it is because you can't get exact results from circuits that are nonlinear and whose parameters shift with the slightest change in the inputs, making it impossible to solve a voltage or current's value exactly.? This is where the SPICE *TOL settings affect the outcome.? SPICE/LTspice calculates differently when a circuit is 100% linear, and those calculations (and results) theoretically could be as accurate as the math allows them to be - those solutions are theoretically "exact", to the degree that the number resolution and the math allows them to be.
?
The values you printed from parameters has nothing to do with that.? Parameter values are set, or calculated from math formulas and then set, but they are never subject to Newton iterations which are at the core of SPICE's/LTspice's need to approximate nonlinear circuits.? Well, you did calculate a square-root and then a square, so yes, those calculations might be subject to whatever math (in)accuracy there is in your operating system's math routines.
?
Note that when LTspice needs to do a math calculation, it calls the appropriate O.S. math routine to actually do that calculation.? This is why we sometimes get strange error codes, coming from your O.S.'s math routines, which end up in the waveforms - values such as -1.#QNAN.? That is the math routine's error code.? Wine users and Windows users and MAC users might see different error codes in a few cases, because they are OS-specific.
?
Andy
?
|
Re: LTspice models do not work in Qspice
I saw that you had entirely different errors from QSPICE that you described in the QSPICE forum, than the ones you said you were having, in this group.
?
I have to wonder, what's going on?
?
Why did you tell us you had an error about "PROP_DELAY" when there was no such text anywhere in your model?
?
Why did you tell is you had errors about missing subcircuits here (COMPHYS_BASIC_GEN), but did not mention that in the QSPICE forum?? Over there, why did you say all the errors were about missing parameters and shorted resistors, but did not mention any of that here in this group?
?
Sorry, but it somewhat ruins your credibility.
?
Andy
?
|
Re: LTspice models do not work in Qspice
Suded,
?
Another thing that I was thinking (but forgot to state here) was this:
?
Since the problem seems to be that your QSPICE simulation was not picking up all the subcircuit definitions in TI's model, you could have loaded the full UCC27282 model file into your simulation, yourself.? Add this line:
?
? ? .inc ucc27282.lib
?
to the simulation and that would insure that the full set of subcircuits is brought into the simulation - even if QSPICE's model import process extracted only one of the subcircuits from the model file and ignored the other 48.
?
But as should be clear by now, it was really unclear to me what was going on.? I really like to understand WHY something fails when it goes bad, not just to know that an update magically makes everything work.
?
Andy
?
|
Re: LTspice models do not work in Qspice
Hi Andy, Tony
I managed to run the schematic for synchronous buck boost converter (the same uploaded schematic) in Qspice after I updated it
Many thanks for your help
Best regards,
Suded
|
Re: LTspice accuracy, used for calculations and measurements
Thank you Tony.
?
Regards
Udo
|
Re: LTspice accuracy, used for calculations and measurements
On 20/04/2025 09:19, Udo Huhn-Rohrbacher via groups.io wrote:
Hi All,
I had a discussion with LTspiceVXII and LTspice24 users about the accuracy of measurement results, shown up in the spice error log. To verify how the constant ¡°pi¡± is handled, we made a simple example, such as:
.opt plotwinsize=0 numdgt=15 measdgt=15
.param x=pi
.param y=sqrt(x)
.param z=y**2
.op or .tran
.meas z_value param z
.meas x_value param x
Spice error log shows:
z_value: z=3.14159265359
x_value: x=3.14159265359
?
To our surprise, we observed different results between users, although the same setup was implemented.
Mike Engelhardt¡¯s LTspice XV!! Help-file Copyright ? 1998-2018 Analog Devices Corporation Shows on page 105:
The following constants are internally defined:
Name Value
E 2.7182818284590452354
pi 3.14159265358979323846
K 1.3806503e-23
Q 1.602176462e-19
?
The solver was set to ?Alternate¡°. We assume, "Alternate" is 1000 times more accurate compared to ¡°Normal¡±
?
My question is now a general one, independent on the practical significance of pi:
What is the accuracy LTspiceXVII and LTspice24¡. Is using for calculations and measurements, shown in the log-file ?
and are there differences between LTspice versions?
?
Thanks a lot in advance
---
regards
Udo
We've had similar discussions here in the past. Printed results in LTspice's logfile are double precision floating point, if measdgt>6 is assigned. Otherwise, it is single precision. Double precision can only support a maximum of 16 decimal digits, and single precision a maximum of 7, although sometimes you will get only 6 (hence the significance of measdgt).
The "constants" pre-assigned in LTspice are variously imprecise:
Constant??? LTspice??? ??? ??? ??? ??? "Accepted or SI definition"
--------------------------------------------------------------------------
e????????? 2.7182818284590452354????? 2.718281828459045235360287471352..
¦Ð????????? 3.14159265358979323846???? 3.141592653589793238462643383279..
k??? ??? ? 1.3806503e-23????????????? 1.380649e?23
q??? ??? ? 1.602176462e-19??????????? 1.602176634e?19
You can see that e and ¦Ð are simply rounded truncations. But k and q were re-defined by SI in 2019, i.e. since the constants were originally coded into LTspice (SWCAD) - possibly even the original Berkeley SPICE. (SI defines elementary charge as "e", not "q".) It seems like LTspice has never updated its values for k and q, even in 24.1.x. It doesn't seem much to get upset about, but LTspice ought to respect the accepted values.
Simulation accuracy is a tricky subject, because the way SPICE works is to approximate the operating point at every step according defined "tolerances" listed in Control Panel > SPICE. Changing any one of those settings may have subtle or major effects on the assumed behaviour of the circuit, i.e. the solution at any one point will probably be "wrong". But because SPICE is assumed deterministic, the result should be same every time you run it with unchanged conditions.
As the solver code is tweaked for convergence, you could expect minor variations in simulated results. After all, if you use enough precision, you will get minor variations in the physically measured value of anything.
--
Regards,
Tony
?
|
Re: LTspice models do not work in Qspice
Hi Andy,
The example I got from Qspice forum for UCC27282 worked, I had to update Qspice to the latest version, there are few warnings but they are ignored and simulation is running and waveform window appears with the plots, I will try to regenerate the models/.SUCKT in the new version and run the simulation (Qspice)
Many thanks,
Suded
|
Re: LTspice models do not work in Qspice
Hi Tony,
ok, many thanks
Suded
|
Re: LTspice models do not work in Qspice
On 20/04/2025 02:26, suded emmanuel via
groups.io wrote:
By the way Temp was
preventing me from uploading the same file name it says it already
has it, so i changed the name to Buck Boost only and uploaded it,
it took it so it should be there!
Don't try to upload a file of the same name as another that already
exists in /Temp. That's problematic in any file system. If it's an
update to an existing file, click on the "Update" icon immediately
to the right of the file name. Momentarily hover the mouse cursor
over the icons, and the function name will pop-up.
--
Regards,
Tony
|
LTspice accuracy, used for calculations and measurements
Hi All,
I had a discussion with LTspiceVXII and LTspice24 users about the accuracy of measurement results, shown up in the spice error log. To verify how the constant ¡°pi¡± is handled, we made a simple example, such as:
.opt plotwinsize=0 numdgt=15 measdgt=15
.param x=pi
.param y=sqrt(x)
.param z=y**2
.op or .tran
.meas z_value param z
.meas x_value param x
Spice error log shows:
z_value: z=3.14159265359
x_value: x=3.14159265359
?
To our surprise, we observed different results between users, although the same setup was implemented.
Mike Engelhardt¡¯s LTspice XV!! Help-file Copyright ? 1998-2018 Analog Devices Corporation Shows on page 105:
The following constants are internally defined:
Name Value
E 2.7182818284590452354
pi 3.14159265358979323846
K 1.3806503e-23
Q 1.602176462e-19
?
The solver was set to ?Alternate¡°. We assume, "Alternate" is 1000 times more accurate compared to ¡°Normal¡±
?
My question is now a general one, independent on the practical significance of pi:
What is the accuracy LTspiceXVII and LTspice24¡. Is using for calculations and measurements, shown in the log-file ?
and are there differences between LTspice versions?
?
Thanks a lot in advance
---
regards
Udo
?
?
|
Re: LTspice models do not work in Qspice
In LTspice, when the waveform window does not show up, it usually means that LTspice is still working, trying to find the initial operating point.? Sometimes it can get stuck there.
?
Andy
?
|
Re: LTspice models do not work in Qspice
Hi Andy,
Many thanks for that, Im trying to get something on the Qspice forum as we speak, they said there are errors that could be ignored, but in my case the waveform window is not showing up, they sent me an example but still not running with errors and the waveform window not showing up!
Regards,
Suded
|
Re: LTspice models do not work in Qspice
I can't see much reason for the simulation going bad in QSPICE.
?
But I am not currently running QSPICE, and I do not know the steps it uses to import a model - or, more precisely, to create a schematic symbol for a new part, since that should be all it needs to do.? The UCC27282 is a SPICE model already so it should not need to be modified or converted.
?
Mind you, LTspice spits out several warnings and errors, about curly braces and undefined symbols.? Those are usually caused by doubled-up { { curly braces } } in many of TI's models.? They are improper in LTspice, but I think we can ignore those messages.? Also there are a lot of warnings about "empty" pin currents, which can be ignored.? And the circuit simulates rather slowly.
?
I am assuming that "PROP_DELAY" error was from a different simulation because that text is totally absent from this one.
?
But the "COMPHYS_BASIC_GEN" errors could have come from this model.? I think it should not have, if QSPICE used the full ucc27282.lib model file, but maybe there is a reason why it does not.? I wonder if there is a setting in QSPICE for that.? I think the PARAMs are OK.? That's all I can say.
?
Andy
?
|
Re: LTspice models do not work in Qspice
Hi Andy,
Just uploaded the .ZIP file:
Buck Boost 1 converter to Temp, it has ucc27282.lib
Regards,
Suded
|
Re: LTspice models do not work in Qspice
Sorry, I had a typo.
?
The model file you uploaded: "UCC27282 model.txt".
?
The model file needed: "ucc27282.lib".
?
Both the main part of the filename and the extension do not match.
?
Andy
?
|
Re: LTspice models do not work in Qspice
Suded,
?
Thank you for the new upload.? It has all the pieces, for LTspice at least.
?
It does have 2 problems, though, both of which are fixable on our end:
- The auto-generated symbol points to a location on your computer only, which does not work for anyone else.? This is a consequence of auto-generating the symbol.? I think it is best to edit every auto-generated symbol, press Ctrl-A, and edit the ModelFile attribute to remove the drive and path, leaving just the filename.ext.? Save it.? Then put the model file either in the same directory with the schematic, or in a user-defined location for your model files.
- The symbol calls for a model file named "ucc27282.lib", but the model file you uploaded (inside the .zip) is named "UCC27282 model.lib".? That needs to be fixed.? The upper/lower case makes no difference, but the extra word in the filename makes it fail.
?
Is there any chance that "ucc27282.lib" and "UCC27282 model.lib" are not the same?
?
Andy
?
|
Re: LTspice models do not work in Qspice
Hi Andy,
Yes, I can see it, "Buck Boost Converter.Zip in Temp
deleted the rest!
Regards,
Suded
|
Re: LTspice models do not work in Qspice
Hi Andy,
Yes, I replaced it with IRFR7446 in Qspice, since ?BSZ076N06NS3 is built in LTspice only, IRFR7446 should do the same job
By the way Temp was preventing me from uploading the same file name it says it already has it, so i changed the name to Buck Boost only and uploaded it, it took it so it should be there!
Regards,
Suded
|
Re: LTspice models do not work in Qspice
On Sat, Apr 19, 2025 at 08:05 PM, suded emmanuel wrote:
Yes, I had to upload moadel (.SUBCKT) for IRFR7446 mosfet,
There is no IRFR7446 on your schematic.? I think you did not need to "upload" (? - did you mean "include"?) that model file.
I have for of them in H-bridge configuration, but they are working well
Did you mean the BSZ076N06NS3 MOSFET?
?
Let me back up here.
?
Are we even talking about the same schematic, the same circuit?? You have told us about error messages which could not have come from your schematic because they did not have those devices.? Now you're saying there are MOSFETs that were not on your schematic.
?
Maybe you can explain what you are actually doing?
?
Andy
?
|
Re: LTspice models do not work in Qspice
Reason for button click "include all files", I was looking into Qspice forum, in one thread Mike suggested that this button should be ticked, which I tried for another model for TLV1831 comparator, and only when i ticked this box the model/simulation worked in Qspice, so I thought I do the? same for UCC27282 but that didnt work and it gave whole bunch of errors like:
?
Ignoring shorted resistor: "RSDUM?XNSW1?X_U1_U11?X1"
Warning: Unresolved parameter: "RONVAL"
GOUT: Trouble evaluating "" for I.
Warning: Unresolved parameter: "RONVAL"
?
"RONVAL" is in the .SUBCKT file
but for TLV1831 simulation worked smoothly!
Regards,
Suded
|
Tony Casey