LTspice Schmitt-Trigger spikes

[Detzi]

Hi there,
i created a 3rd Order Low Pass Elliptic Filter and attached an Schmitt-Trigger behind. On the Output i can see some huge spikes. Does someone know why and where these come from?
Thanks in advance!

[Audioguru]

Obviously the spikes are produced by the No-name Schmitt Trigger that has no power supply to clamp its output level.

[T3sl4co1l]

SPICE mixed signal simulation is notoriously bad.  Here's an example from Altium:



The best solution is to use an analog (transistor level simulation or behavioral equivalent) model, but this does slow down the simulation a bit, and is impractical with more than a few gates.

Tim

[Detzi]

Obviously the spikes are produced by the No-name Schmitt Trigger that has no power supply to clamp its output level.

Obviously you are wrong, the ''No-name Schmitt Trigger''  is a universal with LTspice supplied model which gets configured and its ''Power constaints'' through the spice lines. Which are for this reason visible in my picture above (see ''SpiceLine'' and ''SpiceLine2'') .

SPICE mixed signal simulation is notoriously bad.  Here's an example from Altium:

...

The best solution is to use an analog (transistor level simulation or behavioral equivalent) model, but this does slow down the simulation a bit, and is impractical with more than a few gates.

Tim

Thanks man, so i do not have to worry then. Also good to know that Altium does it too

[Zero999]

You could try using the 555 timer model for the schmitt trigger, but it's inverting, so you'd need two in series, if that's an issue.

[StillTrying]

My old version of LT doesn't show it.

Setting the 'Max Timestep' in 'Edit Simulation Cmd.' to about 25n should fix it.

[Detzi]

You could try using the 555 timer model for the schmitt trigger, but it's inverting, so you'd need two in series, if that's an issue.

The good old 555  little that can't be done with it.

My old version of LT doesn't show it.

Setting the 'Max Timestep' in 'Edit Simulation Cmd.' to about 25n should fix it.

That really did fix it. Thanks for your input. Strange that the problem is a too large timestep value, choosen by the solver. I would not have expect that. Changing the default integration method to ''Gear'' does also fixes it, no need for a min timestep there.