3

This took me three days to figure out. Consider this simple circuit in LTspice:

enter image description here

Looks pretty innocent. The output is a 1V sine wave, as expected. Going to View->FFT, setting number of data points to 5000, Start Time 50u, End Time 100us. No filtering. This is the output:

enter image description here

An output like this does not quite make sense for a sine wave output and/or a weakly nonlinear system in which the harmonic should fall gently.

Now delete V6 and re-run. Voila, the spectrum makes more sense.

LTspice does not allow for "commenting out" certain blocks and does not even remember the parameters. So if I switch between sin and pulse input, I always have to recreate and memorize the entire parameter set. Hence it makes sense to place all the sources on the schematic and just connect the one with which I am working right now.

I have the suspicion that it has to do with the discrete-time timesteps which are enfored by merely placing a pulse source.

My question is:

  • What did I do wrong?
  • How can this be avoided? In other words, how can I trust the output of a transient analysis?
  • Unfortunately LTspice seems so spartan: Are there any options to enfore a fixed sample step? Any options to resample the transient output such that it is suitable for a DFT?
divB
  • 1,312
  • 14
  • 32
  • I am wondering if you connect V6 to ground through a resistor instead of leaving it floating would make any difference? In any case the harmonics are -120 dB so I wonder why you think that is a problem? – EE_socal Jul 17 '18 at 23:30
  • Go to the control panel and look at the spice tab there. Plenty of interesting things there to adjust -- such as gmin, for example. But I think you did guess correctly about the step size. Try using 1e-10 instead of 10e-9. See what happens. – jonk Jul 18 '18 at 01:51
  • 1
    Also see [this answer](https://electronics.stackexchange.com/q/370920/95619), but there are a few details that can be addressed separately. – a concerned citizen Jul 18 '18 at 05:39

2 Answers2

2

There is nothing wrong with what you did, but it can be improved. As per the comments and @HKOB's answer, the extra source has a 1ps rise/fall times, compared to its duty cycle of 0.5us. While the PULSE sources are internally fixed valued per timestep -- that is, throughout the simulation, at any time, LTspice knows what values are at what times -- the solver still needs to reduce its timestep in order to accomodate the very sharp rise/fall times. This is, in this case, mostly due to the very smooth nature of the signals (sine input, sine output). This, together with your imposed timestep of 10ns for a period of 1us, makes LTspice generate additional noise, despite .opt plotwinsize=0, but also notice that the values of the induced noise are very small, comparable to the ones for the missing source.

BTW, you can add a 0 to the beginning of the pulse, followed by a comment: 0;pulse ..., this will make the source be zero valued. Or, you can prepare it to be ready for a .step like this: pulse {-a*0.8} {a*0.8} 0 {1p*a} {1p*a} {0.5u*a} {1u*a}, where a can be .step param a list 1 0, for example. Here's the result with these settings:

comp

Notice that the noise (until 100MHz) is actually less than the harmonics due to relatively large timestep, which means it's safe to ignore them, or improve the simulation: simply make the timestep 1ns (1000x less than the period), and re-run.

less

You can go lower, but for the amount of time you're simulating it will get very slow for little added benefit, which means you can reduce the total simulation time to 8-10 periods or similar (unless you really mean to capture the very low frequencies, too) and the result will be faster and with the same relevance.

Unfortunately (and, at least to my knowledge), there is no SPICE simulator that has a true fixed timestep and that is due to the nature of the solver. What timestep you impose only has the effect of restricting the solver to the maximum of those timesteps, but it will go lower if it needs to.

a concerned citizen
  • 21,167
  • 1
  • 20
  • 40
  • 2
    Numdgt should help here too – PlasmaHH Jul 18 '18 at 07:09
  • Thanks! Yes I suspected rise/fall times of the vpulse already in my question. Regarding your knowledge: I had fairly good experiences and control with spectre. I had similar issues there but can force either force a fixed time step of strobing. Furthermore it is waaaay more powerful to just add a single variable and make it work whereas in LTspice it seems one has to continuously add/remove/memorize stuff, manually run sweeps, extract data etc. In any case the trick with .step is nice. – divB Jul 19 '18 at 03:44
0

With the additional source you are adding extra forced timepoints due to the 1ps rise and fall time. The extra time points introduce slight numerical discrepancies in the solutions. Two things to look at: (1) If numerical errors are due to convergence then reltol is typically the option to reduce. E.g.: ".option reltol=1e-6". Also reducing dTmax in the .tran statement should also produce more accurate results. The typical advice is to reduce these two a fair bit and then loosen them until you are satisfied your solution is accurate enough. I am not able to test right now but I think (2) if the timepoints are interferring with the FFT sampling then in LTspice you can set Tstep (print step) to a fixed value e.g.: ".tran 10e-9 100u 0 10e-9".

HKOB
  • 1,130
  • 9
  • 19