Re: LTspice models do not work in Qspice
On Sun, Apr 20, 2025 at 08:41 PM, suded emmanuel wrote:
I could not upload my simulation file to Qspice it says that I have to earn few badges to do that!
It is kind of a "bummer" that Qorvo's QSPICE forum is like that.? New, first-time members there can't attach/upload their files.? On the one hand it makes some sense to stop new forum members from spamming them, but IMHO it makes little sense for customer support where first-time posters are the ones likely to need help with their models and schematics.? One hopes their settings are liberal enough to quickly overcome that hurdle.
?
I guess it is one of the problems of corporate-run support.
?
Andy
?
?
|
Re: Modeling a CPE in LTPSICE
On Mon, Apr 21, 2025 at 03:25 PM, Maile, Keith wrote:
This has been asked before and I am just looking for the schematic: Files > Temp > Constant_phase_element1.asc
All files in Temp are there temporarily.? Hence the directory name "Temp".
?
That file is now found here:
?
Files > z_yahoo > Examples > Educational
Files > z_yahoo > Examples > Educational > Constant_phase_element1.asc
?
There are other files near it with similar filenames.
?
Andy
?
|
Modeling a CPE in LTPSICE
This has been asked before and I am just looking for the schematic: Files > Temp > Constant_phase_element1.asc
?
Here¡¯s the old request and answer, Helmut did a great job but I can¡¯t find the schematic.
?
toggle quoted message
Show quoted text
--- In LTspice@..., "Helmut Sennewald"
<helmutsennewald@...> wrote:
--- In LTspice@..., "ks_bilder" <transients@> wrote:
Hello,
just started using LTspice and I don't know how to do the
following: In electrochemistry it is common practice to use
a so called constant phase element (CPE) in impedance analysis
of electrodes. The CPE is defined as follows:
Z = 1/( C * (j*w)^alpha )
where Z is the impedance, C equivalent capacitance, j imaginary
unit, w=2*pi*freq and 0 < alpha <= 1. For alpha=1 the CPE is
identical to an ideal capacitor.
What is the best way to define such an element in LTspice?
I would like to use the element in AC as well as in time
dependent modeling.
any help is appreciated!
Klaus
Hello Klaus,
Do you have some literature how other people have simulated it?
I think only a Laplace function can do the job.
There is absolutely no problem with any Laplace function in the
frequency domain simulation in (LT-)SPICE (.AC simulation).
The transient simulation (.TRAN) can make a lot of trouble with
these functions. The most important rule for transient simulation
is at least with LTspice that the value of a Laplace function
should fall to zero for high frequencies.
This means function with 1/s, 1/s**2 are good functions.
Now to some examples.
The value of the parameter alpha can be defined with a "param"-
statement. The character for exponent is ** and not ^ in LTspice.
.param alpha=1
CPE with G-source: OK in .AC but bad in .TRAN
Laplace=1e-6*s**{alpha}
CPE with E-source: OK in .AC, useful in .TRAN
The E-source circuit requires an additional current meter.
It's also necessary to add a small real value of 1u(1e-6)
to get useful results.
LAPLACE {I(V2)} = {1/(s**{alpha}*1e-6+1u)}
I have uploaded a test circuit to the Files section.
Files > Temp > Constant_phase_element1.asc
Best regards,
Helmut
?
|
Re: Non-converging oscillation problem of inverse Jiles-Atherton model in LTspice
Thank you very much for your suggestion ¡ª you solved a problem that had troubled me for weeks. The convergence is indeed much better now. However, there are still some aspects of the model that puzzle me.
When my input B is a 50?Hz sine wave, the simulation only converges when the delay "tau" is set to 300?ns. If I reduce tau to 200?ns or smaller, the simulation still gets stuck at some point. Moreover, when I try to increase the frequency of B, tau = 300?ns no longer works. This behavior seems to make the model not very robust across different conditions.
Do you have any insights into what might be causing this?
(The new one is here: /g/LTspice/files/Temp/invJAmodel_2.asc)
Again, thank you so much for taking the time to help!
|
Re: Non-converging oscillation problem of inverse Jiles-Atherton model in LTspice
Try to implement the delay not using LC, but using RC. I replaced the voltage sources with an equivalent in the form of a controlled current source and an Rpar and Cpar connected to it. TAU=Rpar*Cpar~50nsec. ?But this is the case if the received voltage is not applied anywhere, but is used only in mathematical terms.
|
Re: Non-converging oscillation problem of inverse Jiles-Atherton model in LTspice
Thanks for your efforts! I¡¯ve seen the JA model you shared earlier¡ªit¡¯s excellent!
However, the circuit I¡¯m working on is the "inverse JA model", where B is the input and H is the output, unlike the usual forward case. I previously implemented the forward model (usual JA model) myself and it worked well without major convergence issues. But this time, the inverse version performs poorly in LTspice, and I¡¯m not sure why. Have you encountered similar convergence problems before?
Additionally, I also tested the inverse model in MATLAB in advance, and it behaved correctly there. But, since MATLAB updates variables sequentially accroding to my codes, while LTspice seems uses matrix-based solving, I wonder if it might be affecting the results. Do you have any suggestions?
|
Re: Non-converging oscillation problem of inverse Jiles-Atherton model in LTspice
Hi.
I managed to make a Jiles-Atherton model in LTspice. I also made a model taking into account the non-magnetic gap, and also derived H and B. I posted models on this forum. I also made the Jiles-Atherton model in Qspice.
|
Re: LTspice accuracy, used for calculations and measurements
Thank you Andy for your explanations.
?
I will post results observed from other user for different LTspice versions as soon as possible.
----
Udo
|
Non-converging oscillation problem of inverse Jiles-Atherton model in LTspice
Hi all,
I¡¯m implementing an inverse Jiles-Atherton model in LTspice, mainly based on this paper:
The simulation stops around a quarter cycle. It seems to get stuck when "dH/dt" approaches zero ¡ª likely because of? "delta", which is the sign of "dH/dt"
I¡¯ve tried replacing the "delta" with a smooth "tanh" function, but the oscillation and convergence issue still remains.
Any suggestions on how to solve this problem?? I've posted my schematic here: /g/LTspice/files/Temp/invJAmodel_dynamictest.zip
Thanks!
|
Re: LTspice models do not work in Qspice
Hi Andy,
When I updated Qspice to the latest version I was able to run the simulation example for UCC27282 sent to me from Qspice forum (not my own one but one uses half bridge only), so that drew me to the conclusion that i had to rebuild/resimulate my file with the updated version of Qspice , I want to mention here that I copied and pasted the model for UCC27282 from the example I was sent by Q form into my own simulation that makes two of UCC27282, also I used different MOSFETs (4 of them) which I got from Qspice built in library:
BSC070N10NS5
The rest I had to place my self, only at this point the simulation was ok and the waveform screen appeared, it gives you a set of errors but it overrides them and simulation runs smoothly!
I could not upload my simulation file to Qspice it says that I have to earn few badges to do that!
Regards,
Suded
?
|
Re: LTspice models do not work in Qspice
Hi Andy,
After I regenerated the model in Qspice and ticked the box that says include all the file, I stopped having this error:
COMPHYS_BASIC_GEN
I had the set of errors I mentioned on Q forum !, before I joined the forum on Q i saw one reply by Mike he suggested this box should be ticked, i think i mentioned this at some stage in this forum!
Also when I ticked the box mentioned above I could simulate TLV1831 on a different file which I couldnt before ticking the box when loading the model in Qspice, I think this should be considered with all models!
Regards,
Suded
|
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
|
Tony Casey