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

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.

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.