As The Photon says, SPICE is an analog simulator and none of them will simulate with a fixed timestep, due to the inherent engine, which works by deploying a derivative: if the changes become too abrupt, the derivative tends to blow up, so the timestep is halvened. If the changes go even more abrupt, the timestep is halvened further, until it can't anymore and coughs up timestep too small
errors. On the other hand, if the circuit is flowing smoothly, it doubles its step, and keeps on doing it (within some limits) to not slow down the simulation when it can go faster.
The solution mentioned by both the previous answers to impose a timestep will only limit the simulator's largest step, that is, if abrupt changes come, the timestep will automatically reduce (and there's nothing you can do about it), but when the circuit can go faster, the maximum timestep will be the one imposed by you. The result is, again, uneven time points.
As The Photon mentions, you can try to postprocess in Excel (never tried) or, alternatively, you can use a decicated small utility, ltsputil.exe
, which deals with exactly these sort of things. It can be found in the LTspice Yahoo Groups home page, in the Files > Util > ltsputil
(you'll need registration, though, to avoid spammers). I recommended it, though.
If you need to export your simulation with a fixed timestep, the only option LTspice provides is to use the .wave
command -- see the help for LTspice > Dot Commands > .WAVE
. This option, however is limited to \$\pm1\text{V}\$, so, unless you're constrained to precision, you should take steps to fit your waveform within those limits, otherwise it will be hard-limited.
As an addendum, for linear and very linear circuits driven by sine waves (and their ilk), the engine will, in general, not have problems, and the solver will fly over the steps. Imposing a timestep will help, for your case, but not by much. A minor trick to use if you want specific timesteps, is to add a pulse source with PULSE 0 1 0 {1m*T} 0 0 {T}
. This creates a pulsed source with an imposed period -- representing your desired timestep -- and a sharp(er) rising edge (0.1% of T, or less, but no need to overdo it) -- which will force the engine to slow down around it. The explanation is that LTspice creates a timetable from the source with known steps provided by your input, which means that the solver will not have to deal with derivative > search > adapt (for the source's case) since it knows ahead when the points come in time, so it can slow down anticipated, deal with the sharp rise, then resume, faster, the "fly-mode". The effect is that, since the whole circuit obeys the timestep, everyting will be slightly more detailed around the sharp edges imposed by the source. This can come in handy when using FFTs, for example, or ltsputil
.
As a final note, in your picture I see you are using a total simulation time of 1us
, but a timestep of 1s
, which will be ignored by LTspice since the timestep is greater than the total simulation time. Maybe you meant it the other way around -- .tran 0 1 0 1u
? If yes, it's an overkill, usually a 0.1% of the total simulation time is enough, even if it may need some more reducing, depending on the situation. Still, it doesn't seem to be your case, because it looks like you are only doing an .OP
analysis, which has a dedicated command of its own -- see LTspice's help for LTspice > Dot Commands > .OP
. But, .OP
doesn't produce waveforms, so I don't really know what you meant to do.