Modeling osc circuit in Spice?

[D.]

I am new to spice. Can someone give me an example
or general directions on how to simulate a typical 32.768Khz
crystal oscillator circuit in either LTspice or plain
old fashioned spice. I am particularly interested in the
startup conditions.

Thanks!
Doug

 

[Tim Wescott]

I am new to spice. Can someone give me an example
or general directions on how to simulate a typical 32.768Khz
crystal oscillator circuit in either LTspice or plain
old fashioned spice. I am particularly interested in the
startup conditions.

Thanks!
Doug

Spice really doesn't do well with simulating circuits with high-Q
resonators. While I might use Spice's linear modeling to evaluate an
oscillator (which would apply well to start-up, come to think of it),
you'll spend a _long_ time waiting for it to simulate your oscillator
operating. Better to use CopperSpice -- build a sample board and try it
out!

HP used to sell RF modeling software (compact harmonica, or something
like that) that used some perversion of the Volterra series, but even
that software wasn't really happy simulating oscillators. You might try
Agilent if you want to see what they do now.

 

[Mike Engelhardt]

Doug,

I am new to spice. Can someone give me an example
or general directions on how to simulate a typical 32.768Khz
crystal oscillator circuit in either LTspice or plain
old fashioned spice. I am particularly interested in the
startup conditions.

There's an example circuit in LTspice you can run.
../examples/Educational/Pierce.asc. It's 10MHz Xtal,
but you can set the tank circuit modeling the Xtal
to be a different frequency and impedance.

--Mike

 

[D.]

Thanks mike,
I tried the example circuit. I fudged the esl parameter to slow it down,
but I'm not sure I applied the xtal specs properly to the tank circuit.
It still seems to be oscillating fast - before crashing my computer

 

[Kevin Aylward]

I am new to spice. Can someone give me an example
or general directions on how to simulate a typical 32.768Khz
crystal oscillator circuit in either LTspice or plain
old fashioned spice. I am particularly interested in the
startup conditions.

There is a xtal oscillator example in SuperSpice.

Kevin Aylward
[email protected]
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Genome]

| I am new to spice. Can someone give me an example
| or general directions on how to simulate a typical 32.768Khz
| crystal oscillator circuit in either LTspice or plain
| old fashioned spice. I am particularly interested in the
| startup conditions.
|
| Thanks!
| Doug
|

There's an example of an inverter oscillator circuit in LTspice in the
binaries newsgroup.

Have fun

DNA

 

[D.]

Thanks DNA,
I tweaked the xtal to get 32.768, and the HCU04 is what I actually have,
so it works great on the screen. Now I'll see what happens in real life.

Thanks!
Doug

 

[Genome]

| Thanks DNA,
| I tweaked the xtal to get 32.768, and the HCU04 is what I actually
have,
| so it works great on the screen. Now I'll see what happens in real
life.
|
| Thanks!
| Doug
|

That's OK.

I'll warn you again that I fudged the crytal/resonator and load
capacitor values to get the thing to go and you'll have to get more
representative data for the actual device you want to use. In particular
I think I changed the mode of operation from series to parallel..... or
perhaps the other way around.

Mike circuit was for a Pierce oscillator, I think the one with the
inverter is a Colpitts oscillator. I am seriously uncertain as to what
I'm really talking about.

The inverter was a rip off from some Philips data which I think is kind
of reliable.

Call it a starting point but you will have to verify the thing yourself.

DNA

 

[ddwyer]

Thanks DNA,
I tweaked the xtal to get 32.768, and the HCU04 is what I actually have,
so it works great on the screen. Now I'll see what happens in real life.

Thanks!
Doug

Im currently developing a 14kHz mechanical resonator circuit with ALC .
The high Q means there is high energy storage, noise is regenerated
round the loop and amplified on each cycle , many cycles are necessary
till the limiting amplitude (gain of 1) is reached (gain reduced to) .
The above applies to the transient mode.
All this means that theres lots of data and this can crash a PC.

My question to Mike relates to the effects of varying the Trtol number.
A low number (2) slows simulation but seems to give better fidelity, it
alters the convergance of my 3 term loop filter, which never reaches an
asymptotic value in 1 second simulated time.
with Tritol 5 all works OK and stabilises by 1 second.
With Tritol 10 the oscillation never builds above an initial value.

Which is correct?

Note for xtal oscillator designers the alternative design means which is
to be preferred in my opinion demonstrate circuit activity. Use AC
analysis to drive a swept signal through say 10 to 100kHz into the port
across which the crystal would sit .
Drive from finite source resistance and observe the voltage across the
port which will be a vector result and includes the negative resistance
component that must exceed the 50k or so necessary to oscillate a 32kHz
crystal.
The above assumes Xtal maintaining circuit configuration of inverting
amplifier with C from I/P and O/P to ground , inverting amp either nor
gate or single transistor. A correct result will show shallow peak of
negative resistance at 32kHz.
Berkley spice copes with vector quantities and yields negative
resistance directly.


Email replies to [email protected] (remove bs)

 

[Mike Engelhardt]

Doug,

My question to Mike relates to the effects of varying the Trtol
number. A low number (2) slows simulation but seems to give
better fidelity, it alters the convergence of my 3 term loop
filter, which never reaches an asymptotic value in 1 second
simulated time. with Tritol 5 all works OK and stabilises by
1 second. With Tritol 10 the oscillation never builds above
an initial value.

Which is correct?

They're probably all correct within some tolerance. Usually,
the lower the tolerance, the slower and more accurate the
solution. This sounds like the situation you're in from
your story.

There's limits to how well you can expect stability of simulation
to be meaningful. Real oscillators have some form of agc due if
for no other reason than limiting. One example that helps some
people get a grip on how accurate they can expect a simulation to
be that deals with oscillation is this deck:

*
L1 1 0 10u
C1 1 0 1000p
..ic V(1)=1
..tran 3m 3m skipbp
..probe
..end

The oscillation will die away in a hundred cycles or so(depending
on timestep size) with Gear integration. With trap, it can go
an quite a while. While I'm not a fan of Gear integration, it is
an accepted method and is "correct" to some level of tolerance.
BTW, in LTspice you have to make sure that the default damping
supplied for inductors is turned off for the oscillations to run forever,
though this damping is usually less of an error then you get with
an integration method like Gear.

When you simulate oscillators, one approach is to see the whole
thing oscillate in SPICE. You are then very sensitive to the
accuracy of the numerical methods used. While LTspice is the
most accurate that I know of, it's still might be a better approach
to break the loop and separately look at the transfer and agc
functions. Sometimes that can let you look directly at the
function of oscillator that you can design.

--Mike

 

[ddwyer]

There's limits to how well you can expect stability of simulation
to be meaningful. Real oscillators have some form of agc due if
for no other reason than limiting. One example that helps some
people get a grip on how accurate they can expect a simulation to
be that deals with oscillation is this deck:

If a real oscillator has a high quality op amp in the loop then I would
expect the linearity to be sufficient such that until limiting, the gain
with resistive feedback would be constant and hence the oscillation
build up would be exponential till limit when gain reduces to 1.
My problem is that with various Tritol values oscillation starts but
doen not build or builds ok or......
Are there friggs there or injected noise that starts oscillation which
then cease?

 

[Mike Engelhardt]

Doug,

There's limits to how well you can expect stability of simulation
to be meaningful. Real oscillators have some form of agc due if
for no other reason than limiting. One example that helps some
people get a grip on how accurate they can expect a simulation to
be that deals with oscillation is this deck:

If a real oscillator has a high quality op amp in the loop then I
would expect the linearity to be sufficient such that until limiting,
the gain with resistive feedback would be constant and hence the
oscillation build up would be exponential till limit when gain
reduces to 1.

Sort of. The problem is that *tiny* differences in gain can make
the thing exponentially increase verses exponentially decrease.
The more linear the oscillator and closer it's gain is 1, the more
like it's amplifying the same signal over and over again, so tiny
errors in integration will give entirely difference answers. But,
within a given accuracy of integration, both answers are correct
no matter how unsatisfying that sounds.

My problem is that with various Tritol values oscillation starts
but doen not build or builds ok or...... Are there friggs there
or injected noise that starts oscillation which then cease?

The noise in a .tran analysis is numeric. Changes in trtol changes
step size so noise changes. In principle, this is another thing
that can cause an oscillator to start or not in SPICE. My experience
has been that smaller trtol is more likely to get the thing
oscillating because it's more like that the corresponding smaller
noise is found to start the thing going. Without trtol limiting the
stepsize, the step keeps increasing and eventually you're taking
step sizes much longer then the oscillation's period, so the
oscillation is never found. It's best not to rely on integration
noise to get the thing buzzing. Kick it somehow at the start of
the simulation, either with a signal or an initial condition.

--Mike