It is my observation that the 'stop time' specification drastically effects certain simulations in erroneous ways:

For example: A plot of the EMF across a capacitor charging from 0V to Ca. 2kV is as expected for 'stop times' < 2 seconds, while greater 'stop time' settings produce increasingly bizarre results, and, in fact, settings of 5 seconds and greater produce a flat (i.e. 0V to a few tens of picovolts) plot over the entire interval!? Moreover the 'maximum step' setting has no effect upon this...

FWIW the (obviously) erroneous simulations tend to complete instantaneously whereas the (apparently) accurate 'runs' are rather slow (several minutes)...

Any insight into this will be *GREATLY* appreciated!

Best regards
HP

 

Here's the schematic file:

To reproduce the described behavior please:

1) Set the 'stop time' to 1 second then run the simulation with trace added for 'V(out)' --- Notice that the results are 'plausible' following the Ca. 90ms oscillator start-up latency...

2) Repeat step 1 (above) but with 'stop time' set to 5 seconds --- The trace will be flat, rising to ~ 27uV during the last 250ms...

Greater 'stop time' settings produce different, and often, stranger results...

Thus it is that the 'stop time' command interacts with the simulation in unexpected and erroneous ways!

Again, many advanced thanks for any info, advice or feedback!

Best regards
HP

 

The attached sim works fine for me. I see no problem.

 

The attached sim works fine for me. I see no problem.

Thanks! Please try running my circuit attached in post #2

With grateful regards
HP

 

In reviewing my circuit I see that I incorrectly drafted the bridge rectifier -- the (sloppily) corrected schematic is attached (below) Of course correction did not solve the simulation problem... Intriguingly, it did change the erroneous result (to an even more bizarre one) 'tho...

Best regards
HP

 

Not a bug. You have rediscovered the difficulty of using (any) Spice to simulate oscillators. The 32bit floating-point numerical domain that these simulators operate in is virtually "noiseless", so when simulating the start-up behavior of an oscillator, a bit of noise (or pertubation) must be inserted somewhere. The two transistors are perfectly (non-physically) matched, too.

First thing I tried was to add the startup directive to the simulation command. Check the "start all external DC supplies at 0V" when viewing the .TRAN dialog box. The transient as the supply turns on perturbs the oscillator to the point where the oscillations are beginning at 0s.

Second method of kick-starting the oscillator. I labeled the base of Q1 b1 and Q2 b2, respectively. When plotted (with no pertubation), they are both 922.7mV at 0s (as a result of the pre-TRAN DC bias solution). Add the directive .IC B(b2)=922.699m. This will create a 1uV differential between V(b1) and V(b2) at 0s. This also starts oscillations immediately.

 

Not a bug. You have rediscovered the difficulty of using (any) Spice to simulate oscillators. The 32bit floating-point numerical domain that these simulators operate in is virtually "noiseless", so when simulating the start-up behavior of an oscillator, a bit of noise (or pertubation) must be inserted somewhere. The two transistors are perfectly (non-physically) matched, too.

First thing I tried was to add the startup directive to the simulation command. Check the "start all external DC supplies at 0V" when viewing the .TRAN dialog box. The transient as the supply turns on perturbs the oscillator to the point where the oscillations are beginning at 0s.

Second method of kick-starting the oscillator. I labeled the base of Q1 b1 and Q2 b2, respectively. When plotted (with no pertubation), they are both 922.7mV at 0s (as a result of the pre-TRAN DC bias solution). Add the directive .IC B(b2)=922.699m. This will create a 1uV differential between V(b1) and V(b2) at 0s. This also starts oscillations immediately.

Many, many thanks! Your suggestions solved the problem (and, I might add, restored my faith in circuit simulation software!) --- How truly an 'ideal world' is not without its asperities!

A further question: Why do you suppose the oscillator (eventually) started only at the lower 'stop time' settings?

Again many sincere thanks!!!

Best regards
HP

 

Likely because of the timestep algorithm. If the sim time is long, the timestep stretches out to the point where very small stuff gets stepped over before the noise finally gets the oscillator started.

 

It's my understanding that the time step Spice (any flavour) selects depends on the stop time. The simulation accuracy/resolution depends on the time step, as might the perturbation amount needed to get the oscillator going.

 

This brings up a more general caveat when using a simulator.
Unlike real life all the devices of the same part number and value will be perfectly identical to each other unless you specify otherwise. This will generally give a too perfect idea of the accuracy, frequency response, gain, etc. of the circuit.
Some Spice simulators have a Monte Carlo option that will randomly assign a selected tolerance to all the parts for each run. Performing many runs with these different random part tolerances gives a more accurate idea of how the circuit will operate in the real world.
That is especially useful in simulating filters as you can see the effect of the component tolerances on the filter response.
Unfortunately LTspice does not have an easy option to do that as a group command but it can be done for individual components using the mc command.