# LTSpice Transient Analysis - How to specify the number of data points per step

I performed a 1us duration transient analysis on a basic inverting op-amp circuit with the resistor value Rx sweeping from 846 Ohms to 1385 Ohms. When I export the data to a text file (File -> Export data as text), the resulting text file has multiple data points for each "step". As an example, for Rx = 848, LTSpice creates 3 data points at 0s, 819ns, and 1us (See Figure 2).

Parsing this text file in excel is a bit annoying but not impossible, I just need to extract every 4th element. However, the problem is that LTSpice generates more data points for some "steps". In Figure 3, for Rx = 1.38k, LTSpice generates 4 data points instead of 3. Now data parsing in excel becomes annoying because sometimes I need to extract every 5th element, while other times I need to extract every 6th element.

So my question is: Is there a way to specify the number of data points created in each step?

Figure 1:

Figure 2:

Figure 3:

In general, SPICE uses an adaptive step-size in transient simulations to minimize simulation time while maintaining accuracy. When circuit variables (node voltages, for example) are changing rapidly, it will take shorter time steps, and when circuit variables are changing slowly, it will take longer time steps.

You can specify a "maximum timestep" in case you want to override the built-in algorithm (either because you find the built-in algorithm doesn't give accurate results or to produce denser points for plotting). In your case, specifying a maximum of maybe 0.1 or 0.2 us would likely result in this timestep being used for all your simulation runs, at the cost of longer simulation times. Specify this in the "Edit Simulation Command" dialog.

Alternatively, you could post-process the results to interpolate output values on whatever time intervals you want, or simply do an x vs y plot in Excel instead of the standard y vs category plot.

While the simulation engine will automatically set its calculation time step on the fly according to how the transient behaviour is progressing, limited by any maximum you've set, the print step parameter will force an output to file at specified times.

Most flavours of Spice have this facility, LT certainly does.

Syntax: .tran {print_step} {print_stop} [print_start [dTmax]] [modifiers]

In most tutorials and examples you see, print_step is set to zero or omitted, which will give you all calculation points in the output file. A finite value will result in a file with those steps. Print_start can be handy, if you have a simulation with a long start up transient which you're not interested in. dTmax is where you can force the simulation engine to take smaller steps than it strictly needs. Modifiers is for things like UIC, use initial conditions.

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.