Two options work very well in LTspice:
plotwinsize (disable compression)
numdgt
How to use these options in Kicad 8(ngspice)? or something equivalent?
best regards
Two options work very well in LTspice:
1 Like
What kind of improvement are you anticipating?
What do numdgt and plotwinsize do?
What I am considering is a request to improve plotting by allowing the user to selct log and lin of all axes, in addition to min and max.
What else should be done?
Thanks for your response!
Below is the description from the LTspice manual:
[ plotwinsize ] Number of data points to compress in one window. Set to zero to disable compression.
[ numdgt ] Historically “numdgt” was used to set the number of significant figures used for output data. In LTspice, if “numdgt” is set to be > 6, double precision is used for dependent variable data.
Attached an example image of LTspice which is pure from a signal source.
I believe there is something similar to be used in ngspice, but I have no experience with it.
FWIW, a couple of notes – I have not used ngspice (I have used ltspice) so I can’t comment on the available options to tweak. An FFT display shows amplitude vs frequency, of course, but you can change things to optimize resolution of one or the other. The more time-domain sample points in the fft buffer the better the resolution of frequency (narrower peaks) and a better representation of the noise floor amplitude is seen. Also, a windowing function is applied to taper the amplitudes of the beginning and end of the fft buffer before computation. Google “fft window function” to learn more.
I have a python/numpy fft display I use for adc work, but I can also start it with perfect test sinusoids to see the differences in fft representation. The test signals are:
Chan-1 (yellow) is 5 Hz plus a little 6.93 Hz mixed in
Chan-2 (red) is 13.5 Hz mixed with 16.1 Hz
Chan-3 (green) is 25.5 Hz
Chan-4 (blue) is 40 Hz, plus some 60Hz added in
First, a peek at buffer length using a rectangular (no) window. When a signal fits the buffer perfectly (an integer number of periods), the signal resolves nicely. Non-integer-period signals tend to smear. Here are 500 to 5000 time-domain samples used for fft – sometimes the signals are a perfect buffer fit, sometimes not:
This set of snips is the same thing using a Hann window which is my general-purpose go-to window function:
The above set of snips have the same input signals and the same Hann window function, so the only thing changing is the size of the buffer passed to the fft. You can see how close signals are resolved better with more points, and how the noise floor starts to drop.
Now a Hann window is sometimes called a Hanning window, but that can be confused with a Hamming window, which is different (but is also a general-purpose window). If you really want to get amplitude accuracy, use a Flat-Top window (but don’t expect to see close signals). A Rectangular window is no window at all, so integer-period signals that fit perfectly in the window resolve nicely, and the others smear, as shown above. This makes more sense when you learn how window functions are applied.
This next set of snips use the same signals and a fixed 1000-point buffer. Only the window function changes:
If you look at general-purpose Hann vs Hamming above, Chan-2 shows how Hann resolves a bit better. Blackman is kinda meh imho. Flat-Top is for resolving amplitudes of peaks. Barlett is an oddball.
So before drawing a conclusion about a signal’s fft, you need to know the calculation tradeoffs.
I am unsure how you would set the fft buffer size for ngspice, but here is the window availability:
Open invitation here for folks to add comments…