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)
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
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.
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
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.
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:
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.
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
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.
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.
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
This is of real interest for selecting the TRTOL value
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.
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.
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
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
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...
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:
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
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
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.
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.
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
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.
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: