Simulating a power amp design in progress, i found the following:
The same circuit that was simulated (.trans) in less than 10 seconds, when the OLG 180° point existed after the 0dB gain in TIAN simulation, takes days if, with an other compensation, this 180° point is never reached any more.
How to get rid of this behavior ?
(Thanks in advance for your help)
The same circuit that was simulated (.trans) in less than 10 seconds, when the OLG 180° point existed after the 0dB gain in TIAN simulation, takes days if, with an other compensation, this 180° point is never reached any more.
How to get rid of this behavior ?
(Thanks in advance for your help)
Attachments
Do you mean that a transient analysis of an oscillating amplifier takes longer than a transient analysis of a stable amplifier? That's perfectly normal simulator behaviour; as the voltages are changing faster and more often in an oscillating amplifier, the simulator needs to take smaller time steps to converge.
You can take a smaller final time or reduce simulation accuracy (increase tolerances) or use a faster computer if you really want to transient simulate an oscillating amplifier.
You can take a smaller final time or reduce simulation accuracy (increase tolerances) or use a faster computer if you really want to transient simulate an oscillating amplifier.
Thanks for your answer, Marcel.
Please, explain-me, looking at this curve why it is an oscillating amplifier ?
And, BTW, how to "increase tolerance" ?
Last edited:
In theory, when the plot in post number 1 is a loop gain plot, the amplifier should not oscillate, or at least not under small-signal conditions. It's unusual, though, that the loop gain levels off to a constant value. Can you show a schematic and indicate what nodes fb and inm are?
Does the amplifier oscillate in the long transient run?
Does the amplifier oscillate in the long transient run?
Until I have finished my work, i do not want to share the full schematic. Attached is where my Tian Voltage source is. inm is at the -input as requested, fb at the middle point of the feedback attenuator, as requested. I was surprised too by the "constant value" OLG at very HF, reason why i simulated up to 10 Terahertz ;-) The CLG is normal. I cannot answer about the long run. Not enough patience.
Attachments
Last edited:
In fact, it seems LTSpice turn totally crazy with this schematic. May-be because I dislike him and its not user friendly interface. My amp is a CFA, with fast devices. LTS show both incredible low slew rate and ultra low distortion numbers that I do not believe neither. Tried various Models: Little changes.
I think your method of determining loop gain is incorrect unless either the impedance to the right of the source (node fb) is zero or the impedance to the left of it (node inm) is infinite. Since neither of these conditions is met, you can do two things:
1. Shift the source to the other side of the feedback impedance, then at least the impedance on the right of the source is lower than the impedance on its left.
2. Look up the papers of professor Middlebrook and apply his full method.
It is easy to see that the method goes wrong by looking at an extreme case: replace the (active part of the) amplifier with a current-controlled voltage source with finite (or even zero) gain. As a current-controlled voltage source has zero input impedance, V(inm) will be zero and the ratio will be infinite, even though the loop gain obviously can't be infinite.
The ratio between V(fb) and V(inm) for frequency approaching infinity is simply the ratio of the high-frequency impedances on both sides of the source. The amplifier doesn't amplify anymore at 10 THz, but you get a voltage division between parasitic impedances.
You could try simulating the response to a 5 mV step over 10 us or so. Besides, LTSpice usually allows you to look at the intermediate results when the transient run is still running, as long as you don't instruct it not to store the initial part of the signal.
Last edited:
I will finish my amp on the bench. I'm crossed against LTSPICE. Too complicated, too unpractical for an old guy like me. And how to believe in the results when you need to set hundred of tricks at all steps ? Now it is the FFT that is f..up with no major change in my circuit ! I give-it up.
Thanks a lot for your nice help, Marcel.
Last edited:
If the amplifier is oscillating, that will also mess up the spectrum of the output signal. The oscillation frequency will never be exactly at the centre of an FFT bin, so you will probably see peaks due to oscillations with skirts around them.
If the amplifier is not oscillating and if it is working just fine, there are still many ways to get a messed up FFT result. For example, insufficient settling time, insufficient simulation accuracy, LTSpice output data compression, coarse interpolation between the simulation time points if the simulator isn't instructed to calculate exactly the time points that the FFT needs.
When you want to measure loop gain on the bench, you probably end up with the same issues as when you want to simulate it plus some extra due to equipment limitations, such as the lack of a perfectly floating signal source. I usually just look at the small-signal step or square wave response (both in simulation and in real life) to see if the circuit is small-signal stable, and then at the recovery from overload to see the large-signal stability.
If the amplifier is not oscillating and if it is working just fine, there are still many ways to get a messed up FFT result. For example, insufficient settling time, insufficient simulation accuracy, LTSpice output data compression, coarse interpolation between the simulation time points if the simulator isn't instructed to calculate exactly the time points that the FFT needs.
When you want to measure loop gain on the bench, you probably end up with the same issues as when you want to simulate it plus some extra due to equipment limitations, such as the lack of a perfectly floating signal source. I usually just look at the small-signal step or square wave response (both in simulation and in real life) to see if the circuit is small-signal stable, and then at the recovery from overload to see the large-signal stability.
Totally agree with marcel. My experience with LTspice is quite similar - if it takes too long there is something wrong with the schematics. Break it and seek the cause. In most cases spice finds oscillations in the TeraHertz range - that do not exist in reality. This is not the fault of spice but modelling is too simple, i.e. idealized like voltage sources with zero impedance etc etc. Indeed these difficulties sometimes can drive you mad.
Whats happens is VERY strange. The Trans is fast, now, and, if I can rely on my TIAN, phase margin is 75° and gain margin 8dB.
No overshoot on square waves little signal.
Now, if I try the FFT, it works at 10KHz, it works at 30Hz, but look how it is at 1000Hz.
If i try the FFT on an other point than Out, it works as expected.
Here are my options and params:
.param Freq=1000
.param numcyc=30
.param dlycyc=10
.param FFT=2**16
.param simtime=numcyc/Freq+dlytime
.param dlytime=dlycyc/Freq
.param timestep=(simtime-dlytime)/FFT
.four {Freq} V(Vin) V(out)
;ac oct 1k 10 100000000
.tran 0 {simtime} {dlytime} {timestep}
.options plotwinsize=0
.options method=gear
.options numdgt=15
.option reltol=1e-6
.option noopiter
.option ptrantau=0
;step param prb list -1 1 ; set prb=0 to turn off probe
;set prb=0
I cannot believe such a GUY. There is no fast way to swap between trans and AC, but editing in a box where letters are so little that I cannot see them with my old eyes, I cannot understand why Middlebrook is not implemented as a default simple fonction, why, sometimes the program has so strange behaviors. Not recognizing fb, as an example. LTSPICE is the most complicated and unachieved program I never used. Powerfull, but, the exact opposite of user friendly. I know it is free, but that is not an excuse. Open source and free programs are usually better than commercial ones, because huge community behind. And the models, the bugs, what a nightmare !
It is a tool. A tool that need years of learning ?
No overshoot on square waves little signal.
Now, if I try the FFT, it works at 10KHz, it works at 30Hz, but look how it is at 1000Hz.
If i try the FFT on an other point than Out, it works as expected.
Here are my options and params:
.param Freq=1000
.param numcyc=30
.param dlycyc=10
.param FFT=2**16
.param simtime=numcyc/Freq+dlytime
.param dlytime=dlycyc/Freq
.param timestep=(simtime-dlytime)/FFT
.four {Freq} V(Vin) V(out)
;ac oct 1k 10 100000000
.tran 0 {simtime} {dlytime} {timestep}
.options plotwinsize=0
.options method=gear
.options numdgt=15
.option reltol=1e-6
.option noopiter
.option ptrantau=0
;step param prb list -1 1 ; set prb=0 to turn off probe
;set prb=0
I cannot believe such a GUY. There is no fast way to swap between trans and AC, but editing in a box where letters are so little that I cannot see them with my old eyes, I cannot understand why Middlebrook is not implemented as a default simple fonction, why, sometimes the program has so strange behaviors. Not recognizing fb, as an example. LTSPICE is the most complicated and unachieved program I never used. Powerfull, but, the exact opposite of user friendly. I know it is free, but that is not an excuse. Open source and free programs are usually better than commercial ones, because huge community behind. And the models, the bugs, what a nightmare !
It is a tool. A tool that need years of learning ?
Attachments
Last edited:
Found the issue: "gmin stepping failed".
It comes from my DC Servo. Replaced its output with an equivalent voltage source. See attached.
Don't know how to fix-it. If I replace their +-12V with a pulse, trying various rise time, it seems to not work at all when I plot the output DC voltage.
Spending more time to get rid of LTSpice behaviors than to design circuits ?
Very touched by your nice help, Marcel. I will sing a Jacques Brel song in your honor. Rain expected.
YouTube ;-)
Attachments
Last edited:
Do you also get error messages about non-convergence or only gmin stepping failed?
I'm more used to Spectre RF than to LTSpice, so I really don't know whether what I'm about to write applies to LTSpice, but when Spectre RF says that gmin stepping failed, it is not a big deal. It just means that the first of a whole bunch of algorithms it has to find a bias point didn't work out and it continues with the next one. In fact we often switch off gmin stepping for large circuits because it almost never converges and just wastes time.
If gmin stepping is the only algorithm that LTSpice supports, then a failing gmin stepping means that the bias point is all wrong. That could give you completely non-physical results.
There are a couple of things you can try to get rid of DC convergence problems. One is to use nodeset statements to provide initial guesses for a couple of node voltages. A second one is using a somewhat higher reltol (but not too high, as otherwise the distortion simulation gets inaccurate). A third one is to start from zero and slowly ramp up the supplies, but I understand you already tried that. A fourth trick is to randomly change a few parameters by a very small amount, for example reducing the supply voltage by a few millivolts. I know that sometimes worked for PSpice 20 years ago.
I'm more used to Spectre RF than to LTSpice, so I really don't know whether what I'm about to write applies to LTSpice, but when Spectre RF says that gmin stepping failed, it is not a big deal. It just means that the first of a whole bunch of algorithms it has to find a bias point didn't work out and it continues with the next one. In fact we often switch off gmin stepping for large circuits because it almost never converges and just wastes time.
If gmin stepping is the only algorithm that LTSpice supports, then a failing gmin stepping means that the bias point is all wrong. That could give you completely non-physical results.
There are a couple of things you can try to get rid of DC convergence problems. One is to use nodeset statements to provide initial guesses for a couple of node voltages. A second one is using a somewhat higher reltol (but not too high, as otherwise the distortion simulation gets inaccurate). A third one is to start from zero and slowly ramp up the supplies, but I understand you already tried that. A fourth trick is to randomly change a few parameters by a very small amount, for example reducing the supply voltage by a few millivolts. I know that sometimes worked for PSpice 20 years ago.
Or creating an 0.1% asymmetry in an otherwise symmetrical circuit. Both methods still work in PSpice
.The nodeset() method is probably the best way to improve convergence in all Spice distros. Reason is buried in the Newton-Raphson-SOR venerable algorithm, the foundation of Spice since the Berkley days.
It is unavoidable for the algorithm iterations to avoid passing close to points where the estimated solution derivative is infinite, unless you start with initial conditions that do not require a more than pi/2 rotation of the solution estimate in the phase space. Otherwise, if the derivative estimate approaches infinity, closer than the numerical precision, then the algorithm gets stuck.
Don't ask me where/how I know this, I would have to kill you after answering
.
As Marcel said: when Gmin or other processes take too long to complete, try to ESCape, sometimes a number of times and examine the result (if convergence is actually achieved) with critical eyes: is it realistic, plausible?
If not, you will have to do your homework, and add realistic imperfections to otherwise idealistic components, mainly the reactive ones, use another solver, change the options, etc.
If the result looks plausible, you can postpone the convergence mods, but when your design is finalized, it is a good idea to make it work without skipping the various simulation steps.
The Yahoo LTspice group offers a lot of help for this type of problem, and if you cannot find an answer, you can always post your question (but without disclosing your circuit, it will be difficult).
That said, I agree with you about the user interface of the XVII version: it is full of bugs, crashes regularly, etc.
The takeover of LT by AD was clearly bad news for LTspice: the AD management doesn't want to kill LTspice immediately, because of the fame and success, but the strategy seems to be a slow suffocation, that will lead to a progressive abandonment of the software
If not, you will have to do your homework, and add realistic imperfections to otherwise idealistic components, mainly the reactive ones, use another solver, change the options, etc.
If the result looks plausible, you can postpone the convergence mods, but when your design is finalized, it is a good idea to make it work without skipping the various simulation steps.
The Yahoo LTspice group offers a lot of help for this type of problem, and if you cannot find an answer, you can always post your question (but without disclosing your circuit, it will be difficult).
That said, I agree with you about the user interface of the XVII version: it is full of bugs, crashes regularly, etc.
The takeover of LT by AD was clearly bad news for LTspice: the AD management doesn't want to kill LTspice immediately, because of the fame and success, but the strategy seems to be a slow suffocation, that will lead to a progressive abandonment of the software
Every time I've had a transient analysis simulation suddenly change from quick-to-run on Wednesday, to slow-to-run on Thursday, I've found that the simulated circuit was oscillating. Every . single . time .
Just let it run super slowly for a half hour, then stop the simulation ("hand" icon) then plot some voltages and currents. In five minutes you'll find at least one and probably several, that are oscillating. Is this instability "real"? In my experience, in many cases, yes. But in some cases, no. Based upon what's oscillating, make a small change to the circuit and simulate again. It may take several trial-and-error experiments to find a fix. Or you may never find a fix.
Things to try (one at a time, not all at once) if you're completely desperate and if electrical engineering theory seems to be full of contradictory falsehoods,
Just let it run super slowly for a half hour, then stop the simulation ("hand" icon) then plot some voltages and currents. In five minutes you'll find at least one and probably several, that are oscillating. Is this instability "real"? In my experience, in many cases, yes. But in some cases, no. Based upon what's oscillating, make a small change to the circuit and simulate again. It may take several trial-and-error experiments to find a fix. Or you may never find a fix.
Things to try (one at a time, not all at once) if you're completely desperate and if electrical engineering theory seems to be full of contradictory falsehoods,
- Exit LTSPICE, turn computer off, count to twenty. Try again.
- Method=Gear
- GMIN=1E-10
- One of the other LTSPICE "solvers"
- .IC (forces initial conditions) ... "nodeset" merely suggests initial conditions
I also find if the frequency of the signal is high and simulation time long it takes a long time to plot the output.
In fact it sometimes stops and redraws the plot from the start.
In general I find LTSPICE very good. It has been realistic on a few "out there" circuits I have tried compared to the real circuit on a pcb.
In fact it sometimes stops and redraws the plot from the start.
In general I find LTSPICE very good. It has been realistic on a few "out there" circuits I have tried compared to the real circuit on a pcb.
No, not entirely true.
.NODESET gives Spice an initial guess for the DC bias point. Spice then iterates changing the .NODESET values until the circuit converges (DC bias point found).
.IC allows initial conditions for transient analysis to be specified. A DC solution is performed, using the initial .IC values as rigid constraints.
The difference is not trivial; .IC is essentially hard coding nodes voltages/branch currents, no deviation from the .IC values is allowed during the iterations and in the final solution. The resulting overall solution is as correct as the .IC conditions. .NODESET is an initial condition for iterating toward a solution; the final values can be different from the .NODESET values.
IC is a much more heavy handed workaround for convergence issues, and can easily lead to wrong solutions. Using .NODESET is the recommended method to improve convergence.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.