I'm running spice on a Mac, and the user interface is a little unrefined compared to what seems to be available in the windows version. I've got a functioning model of an amp that I'm toying with, but as soon as I add feedback, it gives me a "time step too small" error. hooked up one way, it doesn't like one of the output tubes, hooked up with the other side of the output transformer grounded, it doesn't like node V3, which is off of the grid of the same tube. I've attached the file, but it won't let me put the triodes.sub and the 6080.sub spice model files.
My analysis is set to ".tran 0 12ms 10ms" I don't 100% know what that means, but it works on the model with no feedback loop. Maybe someone can explain to me how to adjust the parameters of the transient analysis so that it will be happy? or maybe there's something else in the circuit that needs adjusting? I don't seem to have many of the nice dialog boxes that make the windows version a little more user friendly, but rather am reduced to typing in commands.
Thanks in advance!!
My analysis is set to ".tran 0 12ms 10ms" I don't 100% know what that means, but it works on the model with no feedback loop. Maybe someone can explain to me how to adjust the parameters of the transient analysis so that it will be happy? or maybe there's something else in the circuit that needs adjusting? I don't seem to have many of the nice dialog boxes that make the windows version a little more user friendly, but rather am reduced to typing in commands.
Thanks in advance!!
Can you tell me how to do this? I know I would need to edit the line: (.tran 0 12ms 10ms). I know that the difference between the two times I have show the extent of what is displayed in the analysis window, but not much beyond that.
So I haven't figured out the time step parameter yet, but I did add a "proper" transformer model that I found on another thread, and the problem seems to have gone away.
Not sure if i am right but try right click on "tran" to open the context menu which is much easier to understand than the pure code!
And of course this thread is full of valuable information: https://www.diyaudio.com/community/...ding-ltxvii-from-beginner-to-advanced.260627/
And of course this thread is full of valuable information: https://www.diyaudio.com/community/...ding-ltxvii-from-beginner-to-advanced.260627/
then go to the menu: "simulate" -> "edit simulation cmd"
that should bring up the simulation command window.
that should bring up the simulation command window.
As I understand it, time step needs to be a factor of the FFT size. There is a lot I have yet to figure out between settling time ( pretty obvious) number of samples, FFT size and minimum step. Vary these parameters and yo can get the same circuit with .0001% distortion, or 1%. Some folks have tried to help providing their magic combination of values, but the relationships just are not clear to me.
I run LTSpice on a PC. FWIW, it was written for engineers, not hobbyists. Engineers are expected to understand the parameters.
FWIW, here is what I am currently using.
I run LTSpice on a PC. FWIW, it was written for engineers, not hobbyists. Engineers are expected to understand the parameters.
FWIW, here is what I am currently using.
Attachments
Time step too small means there is something changing so abruptly that SPICE can't find a solution. In LTSpice, you could try the alternate solver. Other things you can try are increasing pulse source rise and fall times, if applicable, adding parasitic capacitances, damping ideal inductors, removing parasitic inductances and reducing accuracy settings. Unfortunately, it's all very much trial and horror.
For the record, I'm an electronics engineer who has simulated analogue and mixed-signal circuits for a couple of decades, and for me solving convergence issues is trial and horror. 🙁 Maybe the applied mathematicians and computer programmers who actually write these programs know better ways to get it to converge than just trying the things listed in post #10, but I don't.
Last edited:
You turned off the infamous LTSpice waveform compression, reserved time for settling, took an integer number of periods of the signal into your FFT window and specified the number of digits, so that's all good.
I wonder why you make the maximum step size equal to 10 times the FFT sample period, .param step=(({stop}-{start})/FFT)*10. Why not equal to the FFT sample period, or maybe even the FFT sample period divided by some small positive integer number? Now some interpolation algorithm or other may have to guesstimate up to nine intermediate points between each two simulated points to get the data needed for the FFT.
You haven't specified a reltol. Sometimes the default is small enough, sometimes you have to set it to a smaller value. SPICE has lots of parameters that influence the simulation accuracy, but reltol is the one that usually has the clearest effect.
I can't say whether 300 periods is enough for settling. Usually you just keep increasing it until the results don't change substantially anymore. If settling takes an unacceptable amount of simulation time, you can try to replace any big capacitors with ideal voltage sources with the same DC voltage across them.
Regarding having an integer number of periods of the signal in the FFT, or more generally DFT (Discrete Fourier Transform), window and the DFT size, when you try to approximate the Fourier series of a continuous-time waveform with a discrete Fourier transform, what happens is essentially this:
A. The waveform gets sampled. According to the sampling theorem, this leads to aliasing when the signal contains frequency components above half the sample rate. That is, your spectrum is messed up unless the sample rate is at least two times the frequency of the highest non-negligible frequency component of the signal. If you are interested in 1 ppm distortion levels, only components that are way below 1 ppm of the fundamental are negligible.
B. You take a finite number of samples that just represent a part of the signal with a finite length, which I will call the DFT window length.
C. The DFT algorithm will calculate what sines and cosines at integer multiples of 1/(DFT window length) have to be added to get a waveform that passes through all the samples. As all frequencies are multiples of 1/(DFT window length), the waveform that you get when you add all those sines and cosines will be periodical with a period of at most 1/(DFT window length).
As a consequence, you get a weird spectrum when the number of periods of the signal in the DFT window is not integer. For example, suppose you have 1.25 periods: a complete sine wave and a quarter of a sine. The DFT will then come up with a set of sines and cosines that when summed together pass precisely through all samples of the 1.25 periods, then jumps back to zero and continues, something like this (apologies for the poor drawing):
The sudden jump every 1/(DFT window length) will lead to lots of high harmonics.
There are tricks to mitigate the effect of a non-integer number of periods, those are known as windowing functions. Those taper off the signal at the edges of the DFT window, so you don't get any jumps in the periodic continuation. I frequently use the Hann window when for some reason I can't get an integer number of periods in the DFT window length. They also make the interpretation of the results more difficult, so don't use them unless you have to. See Wikipedia for details.
The number of points in the DFT has to be large enough to avoid aliasing. Having a number of points that's a power of two allows the use of a clever DFT algorithm known as the Fast Fourier Transform, FFT.
I wonder why you make the maximum step size equal to 10 times the FFT sample period, .param step=(({stop}-{start})/FFT)*10. Why not equal to the FFT sample period, or maybe even the FFT sample period divided by some small positive integer number? Now some interpolation algorithm or other may have to guesstimate up to nine intermediate points between each two simulated points to get the data needed for the FFT.
You haven't specified a reltol. Sometimes the default is small enough, sometimes you have to set it to a smaller value. SPICE has lots of parameters that influence the simulation accuracy, but reltol is the one that usually has the clearest effect.
I can't say whether 300 periods is enough for settling. Usually you just keep increasing it until the results don't change substantially anymore. If settling takes an unacceptable amount of simulation time, you can try to replace any big capacitors with ideal voltage sources with the same DC voltage across them.
Regarding having an integer number of periods of the signal in the FFT, or more generally DFT (Discrete Fourier Transform), window and the DFT size, when you try to approximate the Fourier series of a continuous-time waveform with a discrete Fourier transform, what happens is essentially this:
A. The waveform gets sampled. According to the sampling theorem, this leads to aliasing when the signal contains frequency components above half the sample rate. That is, your spectrum is messed up unless the sample rate is at least two times the frequency of the highest non-negligible frequency component of the signal. If you are interested in 1 ppm distortion levels, only components that are way below 1 ppm of the fundamental are negligible.
B. You take a finite number of samples that just represent a part of the signal with a finite length, which I will call the DFT window length.
C. The DFT algorithm will calculate what sines and cosines at integer multiples of 1/(DFT window length) have to be added to get a waveform that passes through all the samples. As all frequencies are multiples of 1/(DFT window length), the waveform that you get when you add all those sines and cosines will be periodical with a period of at most 1/(DFT window length).
As a consequence, you get a weird spectrum when the number of periods of the signal in the DFT window is not integer. For example, suppose you have 1.25 periods: a complete sine wave and a quarter of a sine. The DFT will then come up with a set of sines and cosines that when summed together pass precisely through all samples of the 1.25 periods, then jumps back to zero and continues, something like this (apologies for the poor drawing):
The sudden jump every 1/(DFT window length) will lead to lots of high harmonics.
There are tricks to mitigate the effect of a non-integer number of periods, those are known as windowing functions. Those taper off the signal at the edges of the DFT window, so you don't get any jumps in the periodic continuation. I frequently use the Hann window when for some reason I can't get an integer number of periods in the DFT window length. They also make the interpretation of the results more difficult, so don't use them unless you have to. See Wikipedia for details.
The number of points in the DFT has to be large enough to avoid aliasing. Having a number of points that's a power of two allows the use of a clever DFT algorithm known as the Fast Fourier Transform, FFT.
