Installing and using LTspice IV (now including LTXVII), From beginner to advanced

Administrator
Joined 2007
Paid Member
Trying this for my own curiosity. Using the library model for the LT1056A opamp set up for a gain of 100 gives the following FFT. I'm using the longhand version of working out the sim settings. I also added a delay of 5 cycles before saving data calculated as taking 1/F and multiplying by 5. No numdgt command used.


I see the cycle starts part way through and not at the zero crossing. That seems to be phase shift caused by the opamp. Reduce gain to 10 and its almost in phase with the input signal. I can accept that...

Back to a gain of 100 and this time with numdgt=7 added.

That's a starting point to experiment some more.

(the last two images are the OP07 (0.3V/uS) at a gain of 100 with and then without numdgt=7)
 

Attachments

  • FFT Opamp 1.JPG
    FFT Opamp 1.JPG
    218.4 KB · Views: 150
  • FFT Opamp 2.jpg
    FFT Opamp 2.jpg
    415.9 KB · Views: 149
  • FFT Opamp 3.JPG
    FFT Opamp 3.JPG
    218.1 KB · Views: 148
  • FFT Opamp 4.JPG
    FFT Opamp 4.JPG
    200.3 KB · Views: 170
  • FFT Opamp 5.JPG
    FFT Opamp 5.JPG
    212.9 KB · Views: 151
  • FFT Opamp 6.JPG
    FFT Opamp 6.JPG
    212 KB · Views: 70
Here is what I've been able to figure out so far. This all assumes that the number of simulation points is an integer multiple of the number of FFT points.

1: Triggering the integrator is bad. Deactivate (entirely) any sharp waveform generators.

2: Don't use an FFT window much larger or smaller than the number of points in the simulation.

3: Check for discontinuities in base/gate currents using d().

4: For very large timesteps (IE for simulations of say 50 cycles), trtol should be larger. This is because the integrator is more likely to be triggered when there is a lot of unknown empty space between data points. For example one of my simulations with 2**10 points wants trtol=10. Using trtol=1g would seem to be a good solution to prevent triggering the integrator, but while this prevents the spurious generation of harmonics, it does for some reason raise the noise floor.

5: Don't use warmup cycles if you don't need to. I can't get -300db noise floors if I do. It seems that if the wave start transients are simulated correctly they do not limit resolution. On the other hand, excluding them seems to cause spectral leakage in the FFT. If your circuit needs warmup cycles because of DC drift, consider replacing capacitors with voltage sources.

Attached is an FFT showing the results of stepping trtol from 1g down to 1m in 7 steps. Not all steps are shown because some had identical results. The orange and yellow are with trtol too large. Magenta is with trtol too slow, the waveform-dependent timestep variation causes integration errors to manifest as harmonics and a high noise floor.

This simulation used 2**12 points per simulation and there were 7 simulations, total elapsed time is 0.932 seconds. Not bad for a -330db noise floor!

Now if you wanted to do a simulation of say, 500 cycles, the advantages are obvious.
 

Attachments

  • -330db.png
    -330db.png
    27.3 KB · Views: 91
  • PlainKuartlotronSimulation-330db.asc
    4.9 KB · Views: 52
FdW, I've been thinking about your simulation rig.

Every cycle in your rig gets 2**FFT points. Since there is always an integer number of cycles N, the FFT will take every Nth point out of say 7 points if there are 7 cycles in the simulation. In this way the points are time-aligned.

The problem is this. If we use 10 cycles at 2**10 points per cycle, and use 2**10 FFT points, we are fine. But if we use 2**8 FFT points, that is 4x less points, we lose time alignment because 10 is not freely divisible by 4. Half of the FFT points will be taken from interpolated, useless data. This is not a problem if you rigorously set your FFT points, but it is another thing to click on and keep track of. A workaround is to use only powers of 2 as the number of cycles. So 2**3, 2**4, 2**5, etc. Not as easily countable as 10, 15, 20, etc.

However it is also inefficient. If you use 10 cycles, 90% of the simulation points are not used in the FFT. You can only double the number of FFT points to get 80% inefficiency, because 10 does divide by 2 once to get 5. But you can't go higher because 5 isn't freely divisible by 2. You can use powers of 2 for the number of cycles again, but 8 cycles is a little low to be foolproof and 16 cycles is usually not necessary.

So in most cases your rig ends up taking 5-10 times longer to simulate than it needs to.

It does have a feature I like, and that is that when you increase the number of cycles, the time resolution doesn't decrease. This is unlike my rig where the entire simulation is locked to the number of FFT points regardless of the number of cycles. So you have to increase the number of cycles by powers of 2 if you want to get the same effect.

So your rig keeps the number of points per cycle constant, mine keeps the number of points per simulation constant. They both do 1 thing well that the other doesn't.

The next logical step would be a system that satisfies both requirements without adding any cognitive load to the user or reducing efficiency.

My solution at this moment is to make the simulation in chunks of 2**FFT where each chunk is 10 cycles, and add another variable "length" or so which simply multiplies the number of chunks. This way you can either increase the number of cycles to get a longer simulation without a loss in speed, or you can increase length to do the same thing without a loss in resolution. I need to think more about how this affects the time alignment.
 
Last edited:
My solution at this moment is to make the simulation in chunks of 2**FFT where each chunk is 10 cycles, and add another variable "length" or so which simply multiplies the number of chunks.

This works in general but I thought I read that LTSPICE uses a prime factor FFT so power of 2 is not necessary. The best solution is to add a directive to turn off interpolation and force a transient analysis to stop at each specified FFT point and converge.
 
Synchronizing the sine wave to the FFT points is not necessary. However synchronizing the simulation points to the FFT appears to be (if you want extreme resolution). The FFT allows you to choose the number of points and they are all powers of 2. If you want to test how the FFT reacts to non powers of 2, try using points=15.5 in this schematic. I tend to get -270db noise floors that way, which isn't a disaster.

Here is what I have come up with to try and consistently get -300db noise floors.

The point is not to process Voyager transmissions in LTSpice. The higher the quality of the data, the less of it we need, the less time we spend in the simulator. When the simulator is more efficient you can do things which you perhaps could not before.

The options are explained on the schematic. You can change resolution, simulation length and number of cycles independently. Everything is locked to powers of 2 except for the number of cycles. 10 cycles will finish in the same time as 100 cycles, it is independent of resolution. If you need to increase the number of cycles without losing resolution, you add lengths.

It has a voltage node to tell you what to set your FFT to so you don't have to guess or do math. The power of 2 inputs may take some getting used to though.

If you use LTSpiceXVII you will have to ctrl-click on the param lists otherwise the LTSpice "helper" window will destroy the formatting.
 

Attachments

  • keansim-330db-FFT.png
    keansim-330db-FFT.png
    23.8 KB · Views: 90
  • keansim-330db.png
    keansim-330db.png
    48.2 KB · Views: 92
  • PlainKuartlotronSimulation-330db-4.asc
    5.8 KB · Views: 50
Last edited:
A further note on FFTs on data points that aren't powers of 2. If you have a lot more datapoints than you need, then there is not a big penalty from getting your time alignment wrong. But if that is the case your simulation may be taking 10x longer than it needs to.

For instance at 2**15.5 datapoints I get a -270db noise floor. But at 2**12.5 datapoints I get -200db.

But at 2**15 and 2**12 points I get -300db noise floors. And the 2**12 simulates 8x faster.

Now say you're running a monte carlo simulation and you want 1000 outputs or something. If you stick to powers of 2 you can increase simulation speed without losing FFT resolution more than you normally could if you did not use powers of 2.
 
I notice that with simulations with 2**12 points, trtol=10 seems to often be an improvement. It makes sense that trtol used to be 7 by default, if computers were so slow that it was important to run the simulator with a low number of points for speed.

Edit: Just found a simulation that prefers trtol=100. Sometimes it helps to step trtol through a wide range of values to find what works best, which is why I have the Y parameter on that schematic that is commented out.
 
Last edited:
http://www.elettrotecnica.unina.it/files/demagistris/didattica/TdC/SPICE_like_simulation.pdf

This is of real interest for selecting the TRTOL value

The mechanism described in the preceding paragraph is illustrated in Fig. 4 for a one-dimensional example

Fig. 4 March-in-time simulation, predictor-corrector

using a first-order predictor (e.g. the forward Euler) and, by implication, a first-order integrator (e.g. the backward Euler). In this Figure, it is assumed, for simplicity of explanation, that an exact solution has been obtained at point 1 on the time axis and that a next time step h has already been selected by some means. The slope of the solution at the point is used to predict the solution P at the next time point 2. The prediction, which is within the region of convergence of the Newton-Raphson process (indicated by range bars in the figure), is used as the initial estimate, and so the solution converges to the correction C. The difference between the actual solution (on the curve) and C is the local truncation error, but the curve is not known, so, that between C and P is used as the measure of local truncation error and, this being within the prescribed simulation precision (TRTOL), the solution is accepted. Had the error been too large, the time step h would have been cut, and the solution at a revised time point (after point 1) re-evaluated, repeatedly if necessary. In either event, the measure of truncation error and the prescribed simulation precision are used to evaluate a suitable value for the next time step h. In some simulators, the next time step is not reevaluated unless either the time step must be cut or the solution at the point is deemed far too precise. In Fig. 4,h is unchanged for the next step. Having decided h, the prediction P at time point 3 is made and is within the region of convergence, and so the correction C is obtained
 
Last edited:
This is a good refresher on simulator-specific issues.

http://www.analog.com/media/en/tech...ticles/x49_en-spice.pdf?domain=www.linear.com

I think in situations where the default value of trtol doesn't work, maybe

.options trapdamp=x

Would be helpful? Another experiment.

Gear integration achieves stability by damping itself and everything else in the circuit, trap integration is more accurate simulating oscillation but prone to ringing, modified-trap is less prone to ringing than trap.
 
AX tech editor
Joined 2002
Paid Member
Great discussions!
Can I address another topic? Do any of you use the Nyquist diagram to assess circuit stability?
As you probably know, if the Nyquist diagram of beta*Aol does not enclose the point 1,0i on the complex plane, the circuit is stable. It is unstable if it does enclose this point.
So a quick check with two examples attached shows a circuit Nyquist plot, one stable, the other unstable, difference is the comp cap. I only show the high freq portion (500kHz to 100MHz).

What I would like to do, to make this easier to evaluate, is to add a circuit on the schematic that gives me a vertical line at 1,0i on the Nyquist plot. Then I would see, in a glance, whether the curve cuts the line left or right of 1,0i. Especially with full freq range plots it can be hard to see otherwise.

Anybody has an idea how to put up the vertical through 1,0i?

Jan
 

Attachments

  • stable.JPG
    stable.JPG
    139.8 KB · Views: 122
  • unstable.JPG
    unstable.JPG
    123.7 KB · Views: 128
Hmm. Try add trace and then enter 0. Then try it again and enter freq, which is the global variable for frequency in AC plots. It works in Nyquist plots too.

freq work for me to plot a horizontal line, but I can't test 0 because the X axis doesn't change to the real component like it should. Probably a bug...
 
Last edited:
AX tech editor
Joined 2002
Paid Member
Actually, if you could display the Nyquist of a sine source, like the source on the schematic, it would just be a point at 1,0i because the magnitude is 1 and the phase shift zero for all frequencies.

The problem is that a single pixel doesn't show on the plot, except when you turn on 'show data points'.
Now this gives a nice view of the stability situation. The amplifier in the first plot is stable.

Jan
 

Attachments

  • src nyq.JPG
    src nyq.JPG
    135.2 KB · Views: 117
  • comp step.JPG
    comp step.JPG
    137 KB · Views: 122
Last edited:
It depends on what the condition is. If the condition is a capacitor on the output, it depends on the impedance of the capacitor and the wires leading to it. If the condition is internal instability at a given output current and/or voltage, then it's possible but all bets are off because once oscillation starts it is limited only by nonlinear behaviors which tend to cause the frequency to shift. But I think it will be the frequency where the line crosses 0.0iV.

Since a Nyquist plot in LTSpice doesn't show frequency, you may have to plot a horizontal line. I guess just plotting 0 won't work because magnitude has to sweep with frequency.

Try this. Make a 2nd order filter with E-sources that has 12b/oct gain and 180 degrees phase shift. Then invert the output to get the line on the right side of 0.
 
Sorry, just got around to figuring out exactly what you asked for. Here is a picture.

Make sure the ESR of the inductors is low enough not to tilt the lines. Changing inductance or the gain of the transconductors will change the length of the lines. If you need to put a line on the other side of 0, just invert the gain of a transconductor.
 

Attachments

  • nyquist-circuit.png
    nyquist-circuit.png
    46.7 KB · Views: 120
This is a good refresher on simulator-specific issues.

http://www.analog.com/media/en/tech...ticles/x49_en-spice.pdf?domain=www.linear.com

I think in situations where the default value of trtol doesn't work, maybe

.options trapdamp=x

Would be helpful? Another experiment.

Gear integration achieves stability by damping itself and everything else in the circuit, trap integration is more accurate simulating oscillation but prone to ringing, modified-trap is less prone to ringing than trap.

And then again :) SPICE Differentiation | Analog Devices

What is needed is a method with the speed and accuracy of trap but without the ringing artifact. To this quest, whereas PSpice eliminated trap ringing by using Gear integration but tries to pick a good time step, another approach is to use a de-tuned version of trap integration so that it will damp trap ringing but only introduce a hopefully acceptably small error in the true circuit behavior. It is actually possible, but not recommended, to de-tune LTspice’s trap integration with the undocumented option called trapdamp, by adding the SPICE directive

.options trapdamp=.01

to your schematic. You might be able to find a value of trapdamp that duplicates the integration behavior of HSPICE8. Nevertheless, I do not recommend using this option because it dampens real circuit behavior and it isn’t necessary in LTspice, which uses a better method of eliminating trap ringing.

LTspice uses an integration method, modified trap, that has the speed and accuracy of trap but without the ringing artifact. Modified trap is a method I invented some years ago and was widely available first in LTspice. To the best of my knowledge, it is the best means to integrate the differential equations of an analog circuit and is not duplicated in any other SPICE program. It is the only method I recommend for circuit design. LTspice does also support the use of the other known methods, trap and Gear, but simply so that a user can duplicate the erroneous results from other SPICE simulators to verify that the models are interpreted the same and only the integration method is different.
 
Jan, to shift the lines horizontally you can add +1.0 to the trace, or to shift it vertically you can add +1.0i. So if you wanted the vertical trace to be at 1.0, then you would plot

V(outV)+1.0

To shift it down so it's on both sides of 0.0i, you would use

V(outV)+1.0-4.0i

Varying 1.0 and 4.0 of course depending on where you want to put it.
 
Last edited: