LTspice26.0.1 bug: terminated TL (y2) produces overshoot.

Hi twopif ,

Will take a look. 

mike

Hi twopif ,

Clearly, you found one solution. The fact that there is only one data point in the overshoot suggests a time step problem, which you figured out. That said, you can also get rid of the overshoot by getting rid of the discontinuity built into an unrealistic pulse. Turn on Smooth half-sine transitions in the V source helper dialog:

That still produces a small overshoot, which is eliminated by using the 70ps time step.

I see that there is a little rise time in the longer time step. Here with 70ps:

mike

Hi Mike,

The half-sine smoothing is sometimes even making the overshoot worse. Also in your last picture there is still some overshoot (Y-scale is 0/1.1V, not 0/1.0V), so it is not fully eliminated. Only by reducing the max. time step significantly (100ns->10ps), the simulation result becomes accurate, but also impractical due to a much longer simulation time.
Other Spice programs, including previous LTspice releases, do not show any overshoot when using the same basic circuit with large or small time-steps. No tuning is needed to get a proper result.

By comparing the waveforms generated by LTspice24.1.9 and LTspice26.0.1 I found that the time stepping in the overshoot region (@t=2us) was almost identical (100ns steps) but near the first edge of the input signal x1 (@t=1us) it was quite different. So, most likely the time steps near t=1us matter. By adding a B-source with tripdt=14ns in the circuit I was able to reduce the time step after the 1ns edge from 16ns to 14ns (see example file).Issue13_LTspice26.0.1_part2.zip

With this minor modification, the overshoot changes from 282% to the expected 0%.
How is it possible that such a small time-step change (16ns->14ns) just after the edge has such a dramatic effect (1us later)? If you can explain that you most likely also know how to solve this issue.

I also noticed that LTspice26.0.1 is using a quite different time stepping protocol. For example, the time step after the first edge is only 30ps in LTspice24.1.9, while it is 16ns in LTspice26.0.1. That might explain why this TL was always producing proper results in the past.

Hope this extra information helps to find the root cause.