Colpitts kick-start in LT Spice

[Steve Wilson]

jlarkin@highlandsniptechnology.com wrote:

On Tue, 12 Nov 2019 09:46:27 -0000 (UTC), Steve Wilson <no@spam.com
wrote:

jlarkin@highlandsniptechnology.com wrote:

On Tue, 12 Nov 2019 03:54:07 -0000 (UTC), Steve Wilson <no@spam.com
wrote:

jlarkin@highlandsniptechnology.com wrote:

On Tue, 12 Nov 2019 01:36:13 -0000 (UTC), Steve Wilson <no@spam.com
wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Mon, 11 Nov 2019 12:19:12 -0800 (PST), Klaus Kragelund
klauskvik@hotmail.com> wrote:

Wow, 1 Henry and multiply farad caps, why are you not using real
values?

It's normalized. Why not?

AFAIR you need to have conditions for oscillation covered,
specifically the gain setting of C1 and C2

It's a perfectly fine oscillator with lots of gain. It just never
starts.

Your model is broken. Use the PSPICE model. It self-starts.

If any oscillator of this kind starts in simulation, something is
indeed broken.

0 multiplied exponentially is still 0.

Wrong math. If your thinking were true, there would be no oscillators
on the planet.

See Barkhausen. Loop gain is greater than 1. Phase shift is zero.

Initial condition is zero.

In a hardware oscillator, thermal noise provides the start signal. In
LTspice, the turnon transient generates the start signal.

But sometimes it doesn't. I posted pics.

And I showed you the device model for the 2N7002 was broken.

The model for the 2N7000 fixes the problem. The 2N7000 is identical
electrically to the 2N7002. I posted this information. Am I just wasting my
time replying to your posts?

The tank feeds the signal to the base or gate. The circuit is an
emitter follower so it appears at the cathode. The split capacitors
feed it back into the tank.

The capacitance ratio gives gain to the loop. The signal amplitude
increases.

Increases from what? In which direction?

In a hardware oscillator, the start signal is random noise. In LTspice,
it depends on the initial conditions.

In either case, it doesn't matter. Even a small loop gain is sufficient
to start the oscillation. The oscillation amplitude increases until it
hits some limit. For example, 1.01^10000 = 1.63582871119e+43

LT Spice is wonderfully numerically quirky. Sometimes it just won't
find the initial start conditions. Sometimes it sims super slow.
Sometimes it sims fine for a while and then stalls. Usually some tiny
change in a part value or the time step or something changes all that.

I found that happens a lot in version XVII. I went back to IV and rarely
see it.

Make sure you are on modified trap. Some sims can change it without telling
you.

I sometimes have to play with things until I can get it to do what
looks reasonable. Is that reality, or did I force it to do what I want
to see?

Your judgement from experience.

> Don't get me started on device models.

Many are wrong, including 2N7002.

 

[Steve Wilson]

jlarkin@highlandsniptechnology.com wrote:

On Tue, 12 Nov 2019 09:29:59 -0600, John S <Sophi.2@invalid.org
wrote:

On 11/12/2019 9:11 AM, jlarkin@highlandsniptechnology.com wrote:
On Tue, 12 Nov 2019 07:43:06 -0600, John S <Sophi.2@invalid.org
wrote:

On 11/11/2019 9:28 PM, jlarkin@highlandsniptechnology.com wrote:
On Tue, 12 Nov 2019 01:36:13 -0000 (UTC), Steve Wilson <no@spam.com
wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Mon, 11 Nov 2019 12:19:12 -0800 (PST), Klaus Kragelund
klauskvik@hotmail.com> wrote:

Wow, 1 Henry and multiply farad caps, why are you not using real
values?

It's normalized. Why not?

AFAIR you need to have conditions for oscillation covered,
specifically the gain setting of C1 and C2

It's a perfectly fine oscillator with lots of gain. It just never
starts.

Your model is broken. Use the PSPICE model. It self-starts.

If any oscillator of this kind starts in simulation, something is
indeed broken.

0 multiplied exponentially is still 0.



In your sim, Remove the kickstart. Then set .tran 0 15000 0.
It begins self-start at about 5k and reached full amplitude at about
8k.

You need more patience. It takes a while for an oscillator to start.

With one set of values, the voltage at the top of the tank is -4 fV
and is absolutely flat.


You're doing something wrong. Try this...

Version 4
SHEET 1 1348 680
WIRE 896 -144 672 -144
WIRE 672 -80 672 -144
WIRE 896 -32 896 -144
WIRE 464 0 304 0
WIRE 624 0 464 0
WIRE 464 80 464 0
WIRE 304 112 304 0
WIRE 896 128 896 48
WIRE 896 128 816 128
WIRE 816 160 816 128
WIRE 464 192 464 144
WIRE 576 192 464 192
WIRE 672 192 672 16
WIRE 672 192 576 192
WIRE 464 240 464 192
WIRE 672 256 672 192
WIRE 896 256 896 128
WIRE 304 400 304 192
WIRE 464 400 464 304
WIRE 464 400 304 400
WIRE 672 400 672 336
WIRE 896 400 896 336
WIRE 896 400 672 400
WIRE 464 432 464 400
FLAG 464 432 0
FLAG 816 160 0
FLAG 576 192 SRC
SYMBOL ind 288 96 R0
WINDOW 0 54 39 Left 2
WINDOW 3 60 70 Left 2
SYMATTR InstName L1
SYMATTR Value 1
SYMBOL cap 448 80 R0
WINDOW 0 51 20 Left 2
WINDOW 3 59 54 Left 2
SYMATTR InstName C1
SYMATTR Value 1
SYMBOL cap 448 240 R0
WINDOW 0 51 20 Left 2
WINDOW 3 59 54 Left 2
SYMATTR InstName C2
SYMATTR Value 5
SYMBOL nmos 624 -80 R0
WINDOW 0 90 24 Left 2
WINDOW 3 70 58 Left 2
SYMATTR InstName M1
SYMATTR Value 2N7002
SYMBOL res 656 240 R0
WINDOW 0 61 43 Left 2
WINDOW 3 60 78 Left 2
SYMATTR InstName R1
SYMATTR Value 500
SYMBOL voltage 896 -48 R0
WINDOW 0 49 45 Left 2
WINDOW 3 48 80 Left 2
SYMATTR InstName V1
SYMATTR Value 20
SYMBOL voltage 896 240 R0
WINDOW 0 53 37 Left 2
WINDOW 3 57 72 Left 2
SYMATTR InstName V2
SYMATTR Value 20
TEXT -192 376 Left 2 !.tran 0 15000 0
TEXT -192 272 Left 2 ;Colpitts Kick-Start
TEXT -168 312 Left 2 ;JL Nov 9 2019

You removed my time step. Set it to 1 ms and wait, very patiently, to
see a beautiful bizarre startup that doesn't oscillate.

Doesn't start. 2N7002 models are bad. Here's the error log:

Questionable use of curly braces in ".model sir870adp vdmos(rg=3 vto=2.9
rd=3.2m rs=1.5m rb={m} kp=100 mtriode=1.85 cgdmax=1.4n cgdmin=70p cgs=2.9n
cjo=3.6n m=.4 a=.7 vj=.7 lambda=20m is=3p ksubthres=.08 mfg=siliconix vds=
100 ron=5.5m qg=53.5n)"
Error: undefined symbol in: "[m]"
Circuit: * C:\0DNLOAD\1.ASC

Direct Newton iteration for .op point succeeded.

Date: Tue Nov 12 12:22:34 2019
Total elapsed time: 150.536 seconds.

tnom = 27
temp = 27
method = modified trap
totiter = 30000048
traniter = 30000040
tranpoints = 15000021
accept = 15000021
rejected = 0
matrix size = 9
fillins = 2
solver = Normal
Matrix Compiler1: off [1.9]/3.8/2.3
Matrix Compiler2: off [2.0]/3.2/22.1

 

On Tue, 12 Nov 2019 09:29:59 -0600, John S <Sophi.2@invalid.org>
wrote:

On 11/12/2019 9:11 AM, jlarkin@highlandsniptechnology.com wrote:
On Tue, 12 Nov 2019 07:43:06 -0600, John S <Sophi.2@invalid.org
wrote:

On 11/11/2019 9:28 PM, jlarkin@highlandsniptechnology.com wrote:
On Tue, 12 Nov 2019 01:36:13 -0000 (UTC), Steve Wilson <no@spam.com
wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Mon, 11 Nov 2019 12:19:12 -0800 (PST), Klaus Kragelund
klauskvik@hotmail.com> wrote:

Wow, 1 Henry and multiply farad caps, why are you not using real values?

It's normalized. Why not?

AFAIR you need to have conditions for oscillation covered, specifically
the gain setting of C1 and C2

It's a perfectly fine oscillator with lots of gain. It just never
starts.

Your model is broken. Use the PSPICE model. It self-starts.

If any oscillator of this kind starts in simulation, something is
indeed broken.

0 multiplied exponentially is still 0.



In your sim, Remove the kickstart. Then set .tran 0 15000 0.
It begins self-start at about 5k and reached full amplitude at about 8k.

You need more patience. It takes a while for an oscillator to start.

With one set of values, the voltage at the top of the tank is -4 fV
and is absolutely flat.


You're doing something wrong. Try this...

Version 4
SHEET 1 1348 680
WIRE 896 -144 672 -144
WIRE 672 -80 672 -144
WIRE 896 -32 896 -144
WIRE 464 0 304 0
WIRE 624 0 464 0
WIRE 464 80 464 0
WIRE 304 112 304 0
WIRE 896 128 896 48
WIRE 896 128 816 128
WIRE 816 160 816 128
WIRE 464 192 464 144
WIRE 576 192 464 192
WIRE 672 192 672 16
WIRE 672 192 576 192
WIRE 464 240 464 192
WIRE 672 256 672 192
WIRE 896 256 896 128
WIRE 304 400 304 192
WIRE 464 400 464 304
WIRE 464 400 304 400
WIRE 672 400 672 336
WIRE 896 400 896 336
WIRE 896 400 672 400
WIRE 464 432 464 400
FLAG 464 432 0
FLAG 816 160 0
FLAG 576 192 SRC
SYMBOL ind 288 96 R0
WINDOW 0 54 39 Left 2
WINDOW 3 60 70 Left 2
SYMATTR InstName L1
SYMATTR Value 1
SYMBOL cap 448 80 R0
WINDOW 0 51 20 Left 2
WINDOW 3 59 54 Left 2
SYMATTR InstName C1
SYMATTR Value 1
SYMBOL cap 448 240 R0
WINDOW 0 51 20 Left 2
WINDOW 3 59 54 Left 2
SYMATTR InstName C2
SYMATTR Value 5
SYMBOL nmos 624 -80 R0
WINDOW 0 90 24 Left 2
WINDOW 3 70 58 Left 2
SYMATTR InstName M1
SYMATTR Value 2N7002
SYMBOL res 656 240 R0
WINDOW 0 61 43 Left 2
WINDOW 3 60 78 Left 2
SYMATTR InstName R1
SYMATTR Value 500
SYMBOL voltage 896 -48 R0
WINDOW 0 49 45 Left 2
WINDOW 3 48 80 Left 2
SYMATTR InstName V1
SYMATTR Value 20
SYMBOL voltage 896 240 R0
WINDOW 0 53 37 Left 2
WINDOW 3 57 72 Left 2
SYMATTR InstName V2
SYMATTR Value 20
TEXT -192 376 Left 2 !.tran 0 15000 0
TEXT -192 272 Left 2 ;Colpitts Kick-Start
TEXT -168 312 Left 2 ;JL Nov 9 2019

You removed my time step. Set it to 1 ms and wait, very patiently, to
see a beautiful bizarre startup that doesn't oscillate.

With an unspecified time step, LT Spice LC tank frequencies are not
very accurate.



--

John Larkin Highland Technology, Inc

lunatic fringe electronics

 

[Steve Wilson]

whit3rd <whit3rd@gmail.com> wrote:

On Monday, November 11, 2019 at 5:15:37 PM UTC-8, John Larkin wrote:

[about a Spice-model of oscillator]

It's a perfectly fine oscillator with lots of gain. It just never
starts.

It shouldn't start at all. There's no reason why it would prefer to
swing positive or negative to get going.

The REAL oscillator has thermal noise to start it. Even a wire
has some Johnson noise. SPICE isn't equipped to handle that,
in transient analysis.

JL is using the 2N7002 model, which is defective. If you use the 2N7000
model from PSPICE, it starts fine. LTspice supplies the initial conditions,
and it runs from there.

Version 4
SHEET 1 2804 680
WIRE 976 -144 816 -144
WIRE 816 -80 816 -144
WIRE 976 -32 976 -144
WIRE 368 0 320 0
WIRE 640 0 480 0
WIRE 688 0 640 0
WIRE 768 0 688 0
WIRE 368 80 368 0
WIRE 640 80 640 0
WIRE 320 96 320 0
WIRE 480 112 480 0
WIRE 976 128 976 48
WIRE 976 128 896 128
WIRE 896 160 896 128
WIRE 640 192 640 144
WIRE 688 192 640 192
WIRE 816 192 816 16
WIRE 816 192 688 192
WIRE 640 240 640 192
WIRE 816 256 816 192
WIRE 976 256 976 128
WIRE 320 400 320 176
WIRE 480 400 480 192
WIRE 480 400 320 400
WIRE 640 400 640 304
WIRE 640 400 480 400
WIRE 816 400 816 336
WIRE 976 400 976 336
WIRE 976 400 816 400
WIRE 640 432 640 400
FLAG 688 0 OSC
FLAG 640 432 0
FLAG 896 160 0
FLAG 688 192 SRC
FLAG 368 80 0
SYMBOL ind 464 96 R0
WINDOW 0 54 39 Left 2
WINDOW 3 60 70 Left 2
SYMATTR InstName L1
SYMATTR Value 1
SYMATTR SpiceLine Rser=1m
SYMBOL cap 624 80 R0
WINDOW 0 51 20 Left 2
WINDOW 3 59 54 Left 2
SYMATTR InstName C1
SYMATTR Value 1
SYMBOL current 320 176 R180
WINDOW 0 63 41 Left 2
WINDOW 3 -214 220 Left 2
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName I1
SYMATTR Value PULSE(0 1 100 1m 1m 50m)
SYMBOL cap 624 240 R0
WINDOW 0 51 20 Left 2
WINDOW 3 59 54 Left 2
SYMATTR InstName C2
SYMATTR Value 5
SYMBOL nmos 768 -80 R0
WINDOW 0 90 24 Left 2
WINDOW 3 70 58 Left 2
SYMATTR InstName M1
SYMATTR Value 2N7000
SYMBOL res 800 240 R0
WINDOW 0 61 43 Left 2
WINDOW 3 60 78 Left 2
SYMATTR InstName R1
SYMATTR Value 500
SYMBOL voltage 976 -48 R0
WINDOW 0 49 45 Left 2
WINDOW 3 48 80 Left 2
SYMATTR InstName V1
SYMATTR Value 20
SYMBOL voltage 976 240 R0
WINDOW 0 53 37 Left 2
WINDOW 3 57 72 Left 2
SYMATTR InstName V2
SYMATTR Value 20
TEXT 456 -136 Left 2 !.tran 0 20 0 1m
TEXT 456 -168 Left 2 ;'2N7000 Colpitts Self-Start
TEXT 328 464 Left 2 !* PWRMOS.LIB \n* NOT SPICE 2G.6 Compatible. FOR USE
WITH MICROSIM PSPICE\n.model 2n7000 NMOS(Level=3 Gamma=0 Delta=0 Eta=0
Theta=0 Kappa=0.2 Vmax=0 Xj=0 Phi=.6 Kp=1.073u W=.12 L=2u Rs=20m Vto=1.73
Rd=.5489 Rds=48MEG Cgso=73.61p Cgdo=6.487p Cbd=74.46p Mj=.5 Pb=.8 Fc=.5 Rg=
546.2 Is=10f N=1 Rb=1m)

[Transient Analysis]
{
Npanes: 1
{
traces: 1 {524291,0,"V(osc)"}
X: (' ',0,0,2,20)
Y[0]: ('p',0,-1e-009,2e-010,1e-009)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: ('p',0,0,1,-1e-009,2e-010,1e-009)
Log: 0 0 0
GridStyle: 1
}
}

 

[whit3rd]

On Monday, November 11, 2019 at 5:15:37 PM UTC-8, John Larkin wrote:

[about a Spice-model of oscillator]

It's a perfectly fine oscillator with lots of gain. It just never
starts.

It shouldn't start at all. There's no reason why it would prefer to
swing positive or negative to get going.

The REAL oscillator has thermal noise to start it. Even a wire
has some Johnson noise. SPICE isn't equipped to handle that,
in transient analysis.

 

[John S]

On 11/12/2019 10:48 AM, jlarkin@highlandsniptechnology.com wrote:

You removed my time step. Set it to 1 ms and wait, very patiently, to
see a beautiful bizarre startup that doesn't oscillate.

Why?

With an unspecified time step, LT Spice LC tank frequencies are not
very accurate.

What kind of not accurate? Frequency, voltage, etc? Please specify.
And how do you know about very accurate? Have you built them to verify?

I showed you that your own model self-starts in LTSpice without a
kickstart. You said it never would, but it does. You never mentioned
accuracy. Build one and bench test it. Report back here with your
results. Be honest and don't change the stream in the middle of a horse.

 

[John Larkin]

On Tue, 12 Nov 2019 14:04:56 -0600, John S <Sophi.2@invalid.org>
wrote:

On 11/12/2019 10:48 AM, jlarkin@highlandsniptechnology.com wrote:

You removed my time step. Set it to 1 ms and wait, very patiently, to
see a beautiful bizarre startup that doesn't oscillate.

Why?

With an unspecified time step, LT Spice LC tank frequencies are not
very accurate.

What kind of not accurate? Frequency, voltage, etc? Please specify.

Frequency.

>And how do you know about very accurate? Have you built them to verify?

Built? I compare the LT spice frequency to the calculated value. Even
bare LCs are a bit wrong at the default settings.

I showed you that your own model self-starts in LTSpice without a
kickstart. You said it never would, but it does. You never mentioned
accuracy. Build one and bench test it. Report back here with your
results. Be honest and don't change the stream in the middle of a horse.

The issue isn't bench testing, it is the hazards of LT Spice, and the
general weirdness of numerical simulation of physical systems.

It used to be that LT Spice wouldn't allow you to run if one end of a
capacitor was open, or if you have two caps in series. Now it does.

--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[Clifford Heath]

On 12/11/19 10:51 pm, Jeroen Belleman wrote:

A real oscillator will start up just fine, but a simulation may or
may not. Either way, it would be wrong to take this as a model of
reality. You *must* kick-start an oscillator simulation.

I have both simulated and built quite a few oscillators using LTSpice,
allowing them to start by amplifying the noise in the models. Anything
reasonable seems to start in LTSpice and in real life, once you get the
gain and phase right. I've never used a kick-start in any case.

 

[Steve Wilson]

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Tue, 12 Nov 2019 14:04:56 -0600, John S <Sophi.2@invalid.org
wrote:

On 11/12/2019 10:48 AM, jlarkin@highlandsniptechnology.com wrote:

You removed my time step. Set it to 1 ms and wait, very patiently, to
see a beautiful bizarre startup that doesn't oscillate.

Why?

With an unspecified time step, LT Spice LC tank frequencies are not
very accurate.

What kind of not accurate? Frequency, voltage, etc? Please specify.

Frequency.

And how do you know about very accurate? Have you built them to verify?

Built? I compare the LT spice frequency to the calculated value. Even
bare LCs are a bit wrong at the default settings.

If you are referring to the test you did on July, 2015, you compared the
amplitudes of a shocked LC circuit and a generated sine wave.

you ignored the fact that the inductor ESR defaults to 1 milliohm unless
you specify otherwise.

As you ran the sym, the LC amplitude decayed.

You took the difference in amplitudes between the LC and generated sine
waves and found a difference. How you translated that into a percentage
frequency error I'll never know.

Also, you have to set an appropriate timestep. If you don't specify any
timestep, the sym produces garbage.

Here is your statement from July, 2015:

LT Spice goes for sim speed, so it tends to use coarse time steps. If
you shock a simple LC and let it ring, at default settings the
resonant frequency will be off by percentages. Similarly, oscillator
sims will be unrealistic.

This is in "SPICE tarnsient analysis of oscillators - sampling time"

https://groups.google.com/forum/?hl=en#!
searchin/sci.electronics.design/steve$20wilson$20larkin$20lc$20accuracy%
7Csort:date/sci.electronics.design/4cScUlUOldk/3zQjf2pFAwAJ

I posted a LTspice file with an appropriate inductor ESR and timestep that
showed the frequency error is in the parts per billion. It is difficult to
measure. And you still go around spouting false information.

LTspice can give very accurate answers if you give it correct data. GIGO.

Here is the sym:

Version 4
SHEET 1 880 680
WIRE 224 -192 64 -192
WIRE 416 -192 224 -192
WIRE 480 -192 416 -192
WIRE 64 -112 64 -192
WIRE 416 -32 336 -32
WIRE 480 -32 416 -32
WIRE 336 -16 336 -32
WIRE 224 0 224 -192
WIRE 288 0 224 0
WIRE 64 16 64 -32
WIRE 288 48 224 48
WIRE 224 112 224 48
WIRE 224 112 64 112
WIRE 320 112 224 112
WIRE 416 112 320 112
WIRE 480 112 416 112
WIRE 64 160 64 112
WIRE 320 160 320 112
WIRE 224 176 224 112
WIRE 64 288 64 240
WIRE 224 288 224 240
WIRE 320 288 320 240
FLAG 224 288 0
FLAG 320 288 0
FLAG 64 288 0
FLAG 64 16 0
FLAG 336 64 0
FLAG 416 -32 DIFF
FLAG 416 -192 IDEAL
FLAG 416 112 LC
SYMBOL ind 304 144 R0
WINDOW 0 46 29 Left 2
WINDOW 3 50 62 Left 2
SYMATTR InstName L1
SYMATTR Value 0.1591549430918953357688837634
SYMATTR SpiceLine Rser=1u Cpar=1p
SYMBOL cap 208 176 R0
WINDOW 0 24 -3 Left 2
WINDOW 3 -84 189 Left 2
SYMATTR InstName C1
SYMATTR Value 0.1591549430918953357688837634
SYMATTR SpiceLine Rser=1n Lser=1p
SYMBOL current 64 160 R0
WINDOW 0 -70 50 Left 2
WINDOW 3 -165 99 Left 2
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName I1
SYMATTR Value PULSE(1 0 0.5)
SYMBOL voltage 64 -128 R0
WINDOW 0 -109 61 Left 2
WINDOW 3 -188 104 Left 2
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName V1
SYMATTR Value SINE(0 1 1 0.5)
SYMBOL e 336 -32 R0
WINDOW 0 60 40 Left 2
WINDOW 3 53 74 Left 2
SYMATTR InstName E1
SYMATTR Value -1
TEXT 16 -232 Left 2 !.tran 0 1000 0 100u
TEXT 16 -264 Left 2 ;'LTSpice Compare LC Frequencies Larkin July 2015
TEXT 592 -232 Left 2 !.options numdgt=15
TEXT 264 -168 Left 2 ;Can't tell if frequency is changing or\ntank
amplitude is dropping. A frequency\ndifference will case a linear ramp.
Exponential\ndecay due to Q will cause an exponential rise.

Here is the PLT file:

[Transient Analysis]
{
Npanes: 3
Active Pane: 1
{
traces: 1 {524292,0,"V(ideal)"}
X: ('K',3,2304,3,2334)
Y[0]: (' ',1,-1,0.2,1)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: (' ',0,0,1,-1,0.2,1)
Log: 0 0 0
GridStyle: 1
},
{
traces: 1 {268959746,0,"V(lc)"}
X: ('K',3,2304,3,2334)
Y[0]: ('ľ',0,-0.0008,0.0001,0.0008)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: ('ľ',0,0,0,-0.0008,0.0001,0.0008)
Log: 0 0 0
GridStyle: 1
},
{
traces: 1 {268959747,0,"V(diff)"}
X: ('K',3,2304,3,2334)
Y[0]: (' ',0,-100,20,100)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: (' ',0,0,0,-100,20,100)
Log: 0 0 0
GridStyle: 1
}
}

 

[Steve Wilson]

Steve Wilson <no@spam.com> wrote:

> Here is the sym:

Rats. Line wrap kills the file. Here is the fixed version:

Version 4
SHEET 1 880 680
WIRE 224 -192 64 -192
WIRE 416 -192 224 -192
WIRE 480 -192 416 -192
WIRE 64 -112 64 -192
WIRE 416 -32 336 -32
WIRE 480 -32 416 -32
WIRE 336 -16 336 -32
WIRE 224 0 224 -192
WIRE 288 0 224 0
WIRE 64 16 64 -32
WIRE 288 48 224 48
WIRE 224 112 224 48
WIRE 224 112 64 112
WIRE 320 112 224 112
WIRE 416 112 320 112
WIRE 480 112 416 112
WIRE 64 160 64 112
WIRE 320 160 320 112
WIRE 224 176 224 112
WIRE 64 288 64 240
WIRE 224 288 224 240
WIRE 320 288 320 240
FLAG 224 288 0
FLAG 320 288 0
FLAG 64 288 0
FLAG 64 16 0
FLAG 336 64 0
FLAG 416 -32 DIFF
FLAG 416 -192 IDEAL
FLAG 416 112 LC
SYMBOL ind 304 144 R0
WINDOW 0 46 29 Left 2
WINDOW 3 50 62 Left 2
SYMATTR InstName L1
SYMATTR Value 0.1591549430918953357688837634
SYMATTR SpiceLine Rser=1u Cpar=1p
SYMBOL cap 208 176 R0
WINDOW 0 24 -3 Left 2
WINDOW 3 -84 189 Left 2
SYMATTR InstName C1
SYMATTR Value 0.1591549430918953357688837634
SYMATTR SpiceLine Rser=1n Lser=1p
SYMBOL current 64 160 R0
WINDOW 0 -70 50 Left 2
WINDOW 3 -165 99 Left 2
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName I1
SYMATTR Value PULSE(1 0 0.5)
SYMBOL voltage 64 -128 R0
WINDOW 0 -109 61 Left 2
WINDOW 3 -188 104 Left 2
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName V1
SYMATTR Value SINE(0 1 1 0.5)
SYMBOL e 336 -32 R0
WINDOW 0 60 40 Left 2
WINDOW 3 53 74 Left 2
SYMATTR InstName E1
SYMATTR Value -1
TEXT 16 -232 Left 2 !.tran 0 1000 0 100u
TEXT 16 -264 Left 2 ;'LTSpice Compare LC Frequencies Larkin July 2015
TEXT 592 -232 Left 2 !.options numdgt=15

Here is the PLT file:

[Transient Analysis]
{
Npanes: 3
Active Pane: 1
{
traces: 1 {524292,0,"V(ideal)"}
X: ('K',3,2304,3,2334)
Y[0]: (' ',1,-1,0.2,1)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: (' ',0,0,1,-1,0.2,1)
Log: 0 0 0
GridStyle: 1
},
{
traces: 1 {268959746,0,"V(lc)"}
X: ('K',3,2304,3,2334)
Y[0]: ('ľ',0,-0.0008,0.0001,0.0008)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: ('ľ',0,0,0,-0.0008,0.0001,0.0008)
Log: 0 0 0
GridStyle: 1
},
{
traces: 1 {268959747,0,"V(diff)"}
X: ('K',3,2304,3,2334)
Y[0]: (' ',0,-100,20,100)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: (' ',0,0,0,-100,20,100)
Log: 0 0 0
GridStyle: 1
}
}

 

[John Larkin]

On Tue, 12 Nov 2019 22:38:09 -0000 (UTC), Steve Wilson <no@spam.com>
wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Tue, 12 Nov 2019 14:04:56 -0600, John S <Sophi.2@invalid.org
wrote:

On 11/12/2019 10:48 AM, jlarkin@highlandsniptechnology.com wrote:

You removed my time step. Set it to 1 ms and wait, very patiently, to
see a beautiful bizarre startup that doesn't oscillate.

Why?

With an unspecified time step, LT Spice LC tank frequencies are not
very accurate.

What kind of not accurate? Frequency, voltage, etc? Please specify.

Frequency.

And how do you know about very accurate? Have you built them to verify?

Built? I compare the LT spice frequency to the calculated value. Even
bare LCs are a bit wrong at the default settings.

If you are referring to the test you did on July, 2015, you compared the
amplitudes of a shocked LC circuit and a generated sine wave.

you ignored the fact that the inductor ESR defaults to 1 milliohm unless
you specify otherwise.

As you ran the sym, the LC amplitude decayed.

You took the difference in amplitudes between the LC and generated sine
waves and found a difference. How you translated that into a percentage
frequency error I'll never know.

Also, you have to set an appropriate timestep. If you don't specify any
timestep, the sym produces garbage.

Here is your statement from July, 2015:

LT Spice goes for sim speed, so it tends to use coarse time steps. If
you shock a simple LC and let it ring, at default settings the
resonant frequency will be off by percentages. Similarly, oscillator
sims will be unrealistic.

This is in "SPICE tarnsient analysis of oscillators - sampling time"

https://groups.google.com/forum/?hl=en#!
searchin/sci.electronics.design/steve$20wilson$20larkin$20lc$20accuracy%
7Csort:date/sci.electronics.design/4cScUlUOldk/3zQjf2pFAwAJ

I posted a LTspice file with an appropriate inductor ESR and timestep that
showed the frequency error is in the parts per billion. It is difficult to
measure. And you still go around spouting false information.

LTspice can give very accurate answers if you give it correct data. GIGO.

Here is the sym:

Version 4
SHEET 1 880 680
WIRE 224 -192 64 -192
WIRE 416 -192 224 -192
WIRE 480 -192 416 -192
WIRE 64 -112 64 -192
WIRE 416 -32 336 -32
WIRE 480 -32 416 -32
WIRE 336 -16 336 -32
WIRE 224 0 224 -192
WIRE 288 0 224 0
WIRE 64 16 64 -32
WIRE 288 48 224 48
WIRE 224 112 224 48
WIRE 224 112 64 112
WIRE 320 112 224 112
WIRE 416 112 320 112
WIRE 480 112 416 112
WIRE 64 160 64 112
WIRE 320 160 320 112
WIRE 224 176 224 112
WIRE 64 288 64 240
WIRE 224 288 224 240
WIRE 320 288 320 240
FLAG 224 288 0
FLAG 320 288 0
FLAG 64 288 0
FLAG 64 16 0
FLAG 336 64 0
FLAG 416 -32 DIFF
FLAG 416 -192 IDEAL
FLAG 416 112 LC
SYMBOL ind 304 144 R0
WINDOW 0 46 29 Left 2
WINDOW 3 50 62 Left 2
SYMATTR InstName L1
SYMATTR Value 0.1591549430918953357688837634
SYMATTR SpiceLine Rser=1u Cpar=1p
SYMBOL cap 208 176 R0
WINDOW 0 24 -3 Left 2
WINDOW 3 -84 189 Left 2
SYMATTR InstName C1
SYMATTR Value 0.1591549430918953357688837634
SYMATTR SpiceLine Rser=1n Lser=1p
SYMBOL current 64 160 R0
WINDOW 0 -70 50 Left 2
WINDOW 3 -165 99 Left 2
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName I1
SYMATTR Value PULSE(1 0 0.5)
SYMBOL voltage 64 -128 R0
WINDOW 0 -109 61 Left 2
WINDOW 3 -188 104 Left 2
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName V1
SYMATTR Value SINE(0 1 1 0.5)
SYMBOL e 336 -32 R0
WINDOW 0 60 40 Left 2
WINDOW 3 53 74 Left 2
SYMATTR InstName E1
SYMATTR Value -1
TEXT 16 -232 Left 2 !.tran 0 1000 0 100u
TEXT 16 -264 Left 2 ;'LTSpice Compare LC Frequencies Larkin July 2015
TEXT 592 -232 Left 2 !.options numdgt=15
TEXT 264 -168 Left 2 ;Can't tell if frequency is changing or\ntank
amplitude is dropping. A frequency\ndifference will case a linear ramp.
Exponential\ndecay due to Q will cause an exponential rise.

Here is the PLT file:

[Transient Analysis]
{
Npanes: 3
Active Pane: 1
{
traces: 1 {524292,0,"V(ideal)"}
X: ('K',3,2304,3,2334)
Y[0]: (' ',1,-1,0.2,1)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: (' ',0,0,1,-1,0.2,1)
Log: 0 0 0
GridStyle: 1
},
{
traces: 1 {268959746,0,"V(lc)"}
X: ('K',3,2304,3,2334)
Y[0]: ('ľ',0,-0.0008,0.0001,0.0008)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: ('ľ',0,0,0,-0.0008,0.0001,0.0008)
Log: 0 0 0
GridStyle: 1
},
{
traces: 1 {268959747,0,"V(diff)"}
X: ('K',3,2304,3,2334)
Y[0]: (' ',0,-100,20,100)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: (' ',0,0,0,-100,20,100)
Log: 0 0 0
GridStyle: 1
}
}

You set the time step to 100u. That makes it more accurate.

My Colpitts frequency changes most of a per cent when I set a max time
step low, compared to the LT Spice default. Run time goes way, way up.

--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[John Larkin]

On Wed, 13 Nov 2019 08:23:41 +1100, Clifford Heath
<no.spam@please.net> wrote:

On 12/11/19 10:51 pm, Jeroen Belleman wrote:
A real oscillator will start up just fine, but a simulation may or
may not. Either way, it would be wrong to take this as a model of
reality. You *must* kick-start an oscillator simulation.

I have both simulated and built quite a few oscillators using LTSpice,
allowing them to start by amplifying the noise in the models. Anything
reasonable seems to start in LTSpice and in real life, once you get the
gain and phase right. I've never used a kick-start in any case.

High-Q oscillators, especially crystal oscillators, can take thousands
or millions of cycles to settle. And need a small time step to model
accurately. That can make a run take hours.

I like to force initial conditions close to what the steady-state
values will be. It starts instantly. Then I can zoom up on what it's
doing and see if the amplitude is increasing or decreasing.

--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[Steve Wilson]

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Wed, 13 Nov 2019 08:23:41 +1100, Clifford Heath
no.spam@please.net> wrote:

On 12/11/19 10:51 pm, Jeroen Belleman wrote:
A real oscillator will start up just fine, but a simulation may or
may not. Either way, it would be wrong to take this as a model of
reality. You *must* kick-start an oscillator simulation.

I prove this wrong in a separate post. But you have to be sure to use the
correct model.

I have both simulated and built quite a few oscillators using LTSpice,
allowing them to start by amplifying the noise in the models. Anything
reasonable seems to start in LTSpice and in real life, once you get the
gain and phase right. I've never used a kick-start in any case.

High-Q oscillators, especially crystal oscillators, can take thousands
or millions of cycles to settle. And need a small time step to model
accurately. That can make a run take hours.

I like to force initial conditions close to what the steady-state
values will be. It starts instantly. Then I can zoom up on what it's
doing and see if the amplitude is increasing or decreasing.

I take that to mean letting it run for many cycles then looking at the
envelope to see if it is constant. Then adjust the initial conditions as
appropriate.

You don't have to do that. There's a better way.

I show how to do this in oscillators.zip

https://drive.google.com/open?id=1ZsbpkV0aaKS5LURIb1dfu_ndshsSaYtf

You start the oscillator and let it run for an appropriate length of time,
then measure the peak voltage across the crystal ESR. Convert that to the
voltage required to produce that current, and set the initial conditions to
produce that voltage across the inductor and ESR resistor. This produces a
current in the inductor that matches the value measured after many cycles.

The result is the oscillator starts and settles within a few cycles, at
exactly the correct amplitude.

Even complex stabilization methods, such as suggested by Bruce Griffiths,
settle extremely quickly. I also show this in Oscillators.zip

It's a technique I have used for decades, and often posted to SED.

An extension of this technique is suggested by Kevin Aylward of Superspice:

http://www.kevinaylward.co.uk/

He starts by looking at the formula Q = XL / R

He reasons you can make a high Q oscillator run faster by lowering the Q.
Then you have to increase C by the same amount to maintain the same
frequency. He cautions to not try to go beyond a factor of 100.

His suggestion does indeed work. But it changes the frequency slightly,
which may be important in some applications.

 

[John Larkin]

On Wed, 13 Nov 2019 01:13:53 -0000 (UTC), Steve Wilson <no@spam.com>
wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Wed, 13 Nov 2019 08:23:41 +1100, Clifford Heath
no.spam@please.net> wrote:

On 12/11/19 10:51 pm, Jeroen Belleman wrote:
A real oscillator will start up just fine, but a simulation may or
may not. Either way, it would be wrong to take this as a model of
reality. You *must* kick-start an oscillator simulation.

I prove this wrong in a separate post. But you have to be sure to use the
correct model.

I have both simulated and built quite a few oscillators using LTSpice,
allowing them to start by amplifying the noise in the models. Anything
reasonable seems to start in LTSpice and in real life, once you get the
gain and phase right. I've never used a kick-start in any case.

High-Q oscillators, especially crystal oscillators, can take thousands
or millions of cycles to settle. And need a small time step to model
accurately. That can make a run take hours.

I like to force initial conditions close to what the steady-state
values will be. It starts instantly. Then I can zoom up on what it's
doing and see if the amplitude is increasing or decreasing.

I take that to mean letting it run for many cycles then looking at the
envelope to see if it is constant. Then adjust the initial conditions as
appropriate.

Each setting of initial conditions can be run for just a few cycles to
see if the amplitude is increasing or decreasing. Zoom the heck up on
the peaks. Then tweak the conditions and try again. It converges fast.

Got to be careful about bias, which can involve long time constants.

You don't have to do that. There's a better way.

I show how to do this in oscillators.zip

https://drive.google.com/open?id=1ZsbpkV0aaKS5LURIb1dfu_ndshsSaYtf

You start the oscillator and let it run for an appropriate length of time,

That's the problem. The appropriate screen time may be hours. Maybe
days with a good time step.

then measure the peak voltage across the crystal ESR. Convert that to the
voltage required to produce that current, and set the initial conditions to
produce that voltage across the inductor and ESR resistor. This produces a
current in the inductor that matches the value measured after many cycles.

Why not just measure the voltage and current of all the crystal
elements? It has shunt and series paths, so the current through the
series resistance is only part of the story.

The result is the oscillator starts and settles within a few cycles, at
exactly the correct amplitude.

It only settles at its normal rate, which might be a million cycles.

Even complex stabilization methods, such as suggested by Bruce Griffiths,
settle extremely quickly. I also show this in Oscillators.zip

It's a technique I have used for decades, and often posted to SED.

An extension of this technique is suggested by Kevin Aylward of Superspice:

http://www.kevinaylward.co.uk/

He starts by looking at the formula Q = XL / R

He reasons you can make a high Q oscillator run faster by lowering the Q.
Then you have to increase C by the same amount to maintain the same
frequency. He cautions to not try to go beyond a factor of 100.

His suggestion does indeed work. But it changes the frequency slightly,
which may be important in some applications.

An XO must be analyzed in time domain to estimate the voltages and
currents. It's basically impossible to do PPM or PPB frequency
analysis in time domain. Best switch to frequency domain for that.


--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[Steve Wilson]

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Wed, 13 Nov 2019 01:13:53 -0000 (UTC), Steve Wilson <no@spam.com
wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Wed, 13 Nov 2019 08:23:41 +1100, Clifford Heath
no.spam@please.net> wrote:

On 12/11/19 10:51 pm, Jeroen Belleman wrote:
A real oscillator will start up just fine, but a simulation may or
may not. Either way, it would be wrong to take this as a model of
reality. You *must* kick-start an oscillator simulation.

I prove this wrong in a separate post. But you have to be sure to use
the correct model.

I have both simulated and built quite a few oscillators using LTSpice,
allowing them to start by amplifying the noise in the models. Anything
reasonable seems to start in LTSpice and in real life, once you get
the gain and phase right. I've never used a kick-start in any case.

High-Q oscillators, especially crystal oscillators, can take thousands
or millions of cycles to settle. And need a small time step to model
accurately. That can make a run take hours.

I like to force initial conditions close to what the steady-state
values will be. It starts instantly. Then I can zoom up on what it's
doing and see if the amplitude is increasing or decreasing.

I take that to mean letting it run for many cycles then looking at the
envelope to see if it is constant. Then adjust the initial conditions as
appropriate.

Each setting of initial conditions can be run for just a few cycles to
see if the amplitude is increasing or decreasing. Zoom the heck up on
the peaks. Then tweak the conditions and try again. It converges fast.

That's trial and error and guesswork. You can spend a lot of time trying to
get close.

> Got to be careful about bias, which can involve long time constants.

LTspice settles the bias conditions for you.

You don't have to do that. There's a better way.

I show how to do this in oscillators.zip

https://drive.google.com/open?id=1ZsbpkV0aaKS5LURIb1dfu_ndshsSaYtf

You start the oscillator and let it run for an appropriate length of
time,

That's the problem. The appropriate screen time may be hours. Maybe
days with a good time step.

I have never seen more than a few minutes. Your time step is way too small.

then measure the peak voltage across the crystal ESR. Convert that to
the voltage required to produce that current, and set the initial
conditions to produce that voltage across the inductor and ESR resistor.
This produces a current in the inductor that matches the value measured
after many cycles.

Why not just measure the voltage and current of all the crystal
elements? It has shunt and series paths, so the current through the
series resistance is only part of the story.

The ESR is the one you are interested in. It gives the exact value needed
to start the oscillator and settle in a few cycles, maybe one or two.

The result is the oscillator starts and settles within a few cycles, at
exactly the correct amplitude.

It only settles at its normal rate, which might be a million cycles.

I don't think you are paying attention. I stated a few cycles. If your
trial and error technique works, why do you reject mine?

Even complex stabilization methods, such as suggested by Bruce
Griffiths, settle extremely quickly. I also show this in Oscillators.zip

It's a technique I have used for decades, and often posted to SED.

An extension of this technique is suggested by Kevin Aylward of
Superspice:

http://www.kevinaylward.co.uk/

He starts by looking at the formula Q = XL / R

He reasons you can make a high Q oscillator run faster by lowering the
Q. Then you have to increase C by the same amount to maintain the same
frequency. He cautions to not try to go beyond a factor of 100.

His suggestion does indeed work. But it changes the frequency slightly,
which may be important in some applications.

An XO must be analyzed in time domain to estimate the voltages and
currents. It's basically impossible to do PPM or PPB frequency
analysis in time domain. Best switch to frequency domain for that.

Nonsense. Let the oscillator run for 1,000 or 10,000 cycles, then measure
the frequency and divide by the number of cycles.

You can use Keven's method to speed things up, although I have never run
into an occasion that really needs it.

I don't think frequency domain can get down to ppb. You are dealing with a
response curve at the peak, which is quite flat on these scales.

 

[Steve Wilson]

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Tue, 12 Nov 2019 22:38:09 -0000 (UTC), Steve Wilson <no@spam.com
wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Tue, 12 Nov 2019 14:04:56 -0600, John S <Sophi.2@invalid.org
wrote:

On 11/12/2019 10:48 AM, jlarkin@highlandsniptechnology.com wrote:

You removed my time step. Set it to 1 ms and wait, very patiently,
to see a beautiful bizarre startup that doesn't oscillate.

Why?

With an unspecified time step, LT Spice LC tank frequencies are not
very accurate.

What kind of not accurate? Frequency, voltage, etc? Please specify.

Frequency.

And how do you know about very accurate? Have you built them to
verify?

Built? I compare the LT spice frequency to the calculated value. Even
bare LCs are a bit wrong at the default settings.

If you are referring to the test you did on July, 2015, you compared the
amplitudes of a shocked LC circuit and a generated sine wave.

you ignored the fact that the inductor ESR defaults to 1 milliohm unless
you specify otherwise.

As you ran the sym, the LC amplitude decayed.

You took the difference in amplitudes between the LC and generated sine
waves and found a difference. How you translated that into a percentage
frequency error I'll never know.

Also, you have to set an appropriate timestep. If you don't specify any
timestep, the sym produces garbage.

Here is your statement from July, 2015:

LT Spice goes for sim speed, so it tends to use coarse time steps. If
you shock a simple LC and let it ring, at default settings the
resonant frequency will be off by percentages. Similarly, oscillator
sims will be unrealistic.

This is in "SPICE tarnsient analysis of oscillators - sampling time"

https://groups.google.com/forum/?hl=en#!
searchin/sci.electronics.design/steve$20wilson$20larkin$20lc$20accuracy%
7Csort:date/sci.electronics.design/4cScUlUOldk/3zQjf2pFAwAJ

I posted a LTspice file with an appropriate inductor ESR and timestep
that showed the frequency error is in the parts per billion. It is
difficult to measure. And you still go around spouting false
information.

LTspice can give very accurate answers if you give it correct data.
GIGO.

Here is the sym:

Version 4
SHEET 1 880 680
WIRE 224 -192 64 -192
WIRE 416 -192 224 -192
WIRE 480 -192 416 -192
WIRE 64 -112 64 -192
WIRE 416 -32 336 -32
WIRE 480 -32 416 -32
WIRE 336 -16 336 -32
WIRE 224 0 224 -192
WIRE 288 0 224 0
WIRE 64 16 64 -32
WIRE 288 48 224 48
WIRE 224 112 224 48
WIRE 224 112 64 112
WIRE 320 112 224 112
WIRE 416 112 320 112
WIRE 480 112 416 112
WIRE 64 160 64 112
WIRE 320 160 320 112
WIRE 224 176 224 112
WIRE 64 288 64 240
WIRE 224 288 224 240
WIRE 320 288 320 240
FLAG 224 288 0
FLAG 320 288 0
FLAG 64 288 0
FLAG 64 16 0
FLAG 336 64 0
FLAG 416 -32 DIFF
FLAG 416 -192 IDEAL
FLAG 416 112 LC
SYMBOL ind 304 144 R0
WINDOW 0 46 29 Left 2
WINDOW 3 50 62 Left 2
SYMATTR InstName L1
SYMATTR Value 0.1591549430918953357688837634
SYMATTR SpiceLine Rser=1u Cpar=1p
SYMBOL cap 208 176 R0
WINDOW 0 24 -3 Left 2
WINDOW 3 -84 189 Left 2
SYMATTR InstName C1
SYMATTR Value 0.1591549430918953357688837634
SYMATTR SpiceLine Rser=1n Lser=1p
SYMBOL current 64 160 R0
WINDOW 0 -70 50 Left 2
WINDOW 3 -165 99 Left 2
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName I1
SYMATTR Value PULSE(1 0 0.5)
SYMBOL voltage 64 -128 R0
WINDOW 0 -109 61 Left 2
WINDOW 3 -188 104 Left 2
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName V1
SYMATTR Value SINE(0 1 1 0.5)
SYMBOL e 336 -32 R0
WINDOW 0 60 40 Left 2
WINDOW 3 53 74 Left 2
SYMATTR InstName E1
SYMATTR Value -1
TEXT 16 -232 Left 2 !.tran 0 1000 0 100u
TEXT 16 -264 Left 2 ;'LTSpice Compare LC Frequencies Larkin July 2015
TEXT 592 -232 Left 2 !.options numdgt=15
TEXT 264 -168 Left 2 ;Can't tell if frequency is changing or\ntank
amplitude is dropping. A frequency\ndifference will case a linear ramp.
Exponential\ndecay due to Q will cause an exponential rise.

Here is the PLT file:

[Transient Analysis]
{
Npanes: 3
Active Pane: 1
{
traces: 1 {524292,0,"V(ideal)"}
X: ('K',3,2304,3,2334)
Y[0]: (' ',1,-1,0.2,1)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: (' ',0,0,1,-1,0.2,1)
Log: 0 0 0
GridStyle: 1
},
{
traces: 1 {268959746,0,"V(lc)"}
X: ('K',3,2304,3,2334)
Y[0]: ('ľ',0,-0.0008,0.0001,0.0008)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: ('ľ',0,0,0,-0.0008,0.0001,0.0008)
Log: 0 0 0
GridStyle: 1
},
{
traces: 1 {268959747,0,"V(diff)"}
X: ('K',3,2304,3,2334)
Y[0]: (' ',0,-100,20,100)
Y[1]: ('_',0,1e+308,0,-1e+308)
Volts: (' ',0,0,0,-100,20,100)
Log: 0 0 0
GridStyle: 1
}
}

You set the time step to 100u. That makes it more accurate.

Not enough to go from a few percent to parts-per-billion. That's 7 orders
of magnitude.

You did not know the inductor ESR defaults to 1 milliohm. This caused the
amplitude to decay. You measured the difference in amplitudes, which
cannot distinguish between a frequency or amplitude change. You assumed
the error was caused by a frequency difference when it was actually
amplitude decay.

You would have seen this if you had overlapped the IDEAL and LC waveforms.
It stands out like a sore thumb.

If you set the inductor ESR to 1u, the curves overlap exactly even after
1,000 cycles. It is extremely difficult to measure the error.

My Colpitts frequency changes most of a per cent when I set a max time
step low, compared to the LT Spice default. Run time goes way, way up.

Reduce the time step until the runtime increases, then back off. I do this
in Oscillators.zip and get very reasonable run times, except when showing
the startup and settle times in crystal oscillators.

 

[Steve Wilson]

Steve Wilson <no@spam.com> wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Wed, 13 Nov 2019 01:13:53 -0000 (UTC), Steve Wilson <no@spam.com
wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

High-Q oscillators, especially crystal oscillators, can take
thousands or millions of cycles to settle. And need a small time step
to model accurately. That can make a run take hours.

I like to force initial conditions close to what the steady-state
values will be. It starts instantly. Then I can zoom up on what it's
doing and see if the amplitude is increasing or decreasing.

I take that to mean letting it run for many cycles then looking at the
envelope to see if it is constant. Then adjust the initial conditions
as appropriate.

Each setting of initial conditions can be run for just a few cycles to
see if the amplitude is increasing or decreasing. Zoom the heck up on
the peaks. Then tweak the conditions and try again. It converges fast.

That's trial and error and guesswork. You can spend a lot of time trying
to get close.

Got to be careful about bias, which can involve long time constants.

LTspice settles the bias conditions for you.

You don't have to do that. There's a better way.

I show how to do this in oscillators.zip

https://drive.google.com/open?id=1ZsbpkV0aaKS5LURIb1dfu_ndshsSaYtf

You start the oscillator and let it run for an appropriate length of
time,

That's the problem. The appropriate screen time may be hours. Maybe
days with a good time step.

I have never seen more than a few minutes. Your time step is way too
small.

Vig, April 2012, Page 81, shows the maximum Q of a crystal:

The maximum Q of a resonator can be expressed as:

Qmax = 1/(2*pi*F*t)

For 10 MHz,
Qmax = 1/(2*pi*1e7*1e-14) = 1,591,549

where F is the frequency in Hz, and t is an empirically determined
"motional time constant" in seconds, which varies with the angles of
cut and the mode of vibration. For example, t = 1 x 10 -14 s for the
AT-cut's c-mode (Qmax= 3.2 million at 5 MHz), t = 9.9 x 10 -15 s for
the SC-cut's c-mode, and t = 4.9 x 10 -15 s for the BT-cut's b-mode.

https://www.vcamerica.com/pub/media/documents/vig3.pdf

The ASC file below shows a 10MHz crystal oscillator.

The Q of the crystal is Q = XL/R = 2 * pi * 1e7 * 25e-3 / 1 = 1,570,796,
which is close to the maximum of 1,591,549.

The total elapsed time is 161.732 seconds, or about 2.68 minutes.

If you are getting a run time of hours or days, you are doing something
wrong.

Here is the crystal oscillator:

Version 4
SHEET 1 880 680
WIRE 208 48 16 48
WIRE 304 48 208 48
WIRE 336 48 304 48
WIRE -480 64 -496 64
WIRE -352 64 -400 64
WIRE 336 64 336 48
WIRE 16 80 16 48
WIRE -496 128 -496 64
WIRE -432 128 -496 128
WIRE -352 128 -352 64
WIRE -352 128 -368 128
WIRE -160 128 -352 128
WIRE -144 128 -160 128
WIRE 208 160 208 48
WIRE 336 160 336 144
WIRE -544 208 -592 208
WIRE -496 208 -496 128
WIRE -496 208 -544 208
WIRE -480 208 -496 208
WIRE -368 208 -400 208
WIRE -256 208 -288 208
WIRE -240 208 -256 208
WIRE -144 208 -144 128
WIRE -144 208 -176 208
WIRE -128 208 -144 208
WIRE -48 208 -64 208
WIRE 16 208 16 160
WIRE 16 208 -48 208
WIRE 96 208 16 208
WIRE 144 208 96 208
WIRE -592 240 -592 208
WIRE 16 240 16 208
WIRE -496 256 -496 208
WIRE -48 256 -48 208
WIRE 16 320 16 304
WIRE 112 320 16 320
WIRE 208 320 208 256
WIRE 208 320 112 320
WIRE -592 336 -592 320
WIRE -496 336 -496 320
WIRE 16 336 16 320
WIRE 208 336 208 320
WIRE -48 352 -48 336
WIRE 16 416 16 400
WIRE 208 432 208 416
FLAG 16 416 0
FLAG 96 208 Q1B
FLAG 112 320 Q1E
FLAG -160 128 R7C7
FLAG 304 48 Vcc
FLAG -592 336 0
FLAG -496 336 0
FLAG 208 432 0
FLAG 336 160 0
FLAG -544 208 Vout
FLAG -256 208 L1C1
FLAG -48 352 0
SYMBOL npn 144 160 R0
WINDOW 3 57 69 Left 2
SYMATTR Value 2N3904
SYMATTR InstName Q1
SYMBOL res 0 64 R0
SYMATTR InstName R2
SYMATTR Value 10k
SYMBOL res 192 320 R0
SYMATTR InstName R3
SYMATTR Value 2k
SYMBOL voltage 336 48 R0
WINDOW 123 0 0 Left 2
SYMATTR InstName V1
SYMATTR Value 5
SYMATTR SpiceLine Rser=0.1
SYMBOL cap 0 336 R0
SYMATTR InstName C2
SYMATTR Value 390p
SYMBOL cap 0 240 R0
WINDOW 3 25 49 Left 2
SYMATTR Value 100p
SYMATTR InstName C4
SYMBOL cap -512 256 R0
SYMATTR InstName C5
SYMATTR Value 33p
SYMBOL res -608 224 R0
SYMATTR InstName R5
SYMATTR Value 100k
SYMBOL cap -64 192 R90
WINDOW 0 0 32 VBottom 2
WINDOW 3 32 32 VTop 2
SYMATTR InstName C7
SYMATTR Value 1n
SYMBOL res -384 48 R90
WINDOW 0 0 56 VBottom 2
WINDOW 3 32 56 VTop 2
SYMATTR InstName R7
SYMATTR Value 1E7
SYMBOL cap -176 192 R90
WINDOW 0 0 32 VBottom 2
WINDOW 3 32 32 VTop 2
SYMATTR InstName C1
SYMATTR Value 0.01p
SYMBOL ind -384 224 R270
WINDOW 0 32 56 VTop 2
WINDOW 3 5 56 VBottom 2
SYMATTR InstName L1
SYMATTR Value 25m
SYMATTR SpiceLine Rser=0
SYMBOL res -384 192 R90
WINDOW 0 0 56 VBottom 2
WINDOW 3 32 56 VTop 2
SYMATTR InstName R8
SYMATTR Value 1
SYMBOL cap -368 112 R90
WINDOW 0 0 32 VBottom 2
WINDOW 3 32 32 VTop 2
SYMATTR InstName C8
SYMATTR Value 5p
SYMBOL res -32 240 M0
SYMATTR InstName R1
SYMATTR Value 10k
TEXT -264 -56 Left 2 !.tran 0 50m 0 10n
TEXT -264 -88 Left 2 ;'10MHz Xtal Osc

 

On Wednesday, 13 November 2019 13:52:07 UTC+1, Steve Wilson wrote:

Steve Wilson <no@spam.com> wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

On Wed, 13 Nov 2019 01:13:53 -0000 (UTC), Steve Wilson <no@spam.com
wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

High-Q oscillators, especially crystal oscillators, can take
thousands or millions of cycles to settle. And need a small time step
to model accurately. That can make a run take hours.

I like to force initial conditions close to what the steady-state
values will be. It starts instantly. Then I can zoom up on what it's
doing and see if the amplitude is increasing or decreasing.

I take that to mean letting it run for many cycles then looking at the
envelope to see if it is constant. Then adjust the initial conditions
as appropriate.

Each setting of initial conditions can be run for just a few cycles to
see if the amplitude is increasing or decreasing. Zoom the heck up on
the peaks. Then tweak the conditions and try again. It converges fast.

That's trial and error and guesswork. You can spend a lot of time trying
to get close.

Got to be careful about bias, which can involve long time constants.

LTspice settles the bias conditions for you.

You don't have to do that. There's a better way.

I show how to do this in oscillators.zip

https://drive.google.com/open?id=1ZsbpkV0aaKS5LURIb1dfu_ndshsSaYtf

You start the oscillator and let it run for an appropriate length of
time,

That's the problem. The appropriate screen time may be hours. Maybe
days with a good time step.

I have never seen more than a few minutes. Your time step is way too
small.

Vig, April 2012, Page 81, shows the maximum Q of a crystal:

The maximum Q of a resonator can be expressed as:

Qmax = 1/(2*pi*F*t)

For 10 MHz,
Qmax = 1/(2*pi*1e7*1e-14) = 1,591,549

where F is the frequency in Hz, and t is an empirically determined
"motional time constant" in seconds, which varies with the angles of
cut and the mode of vibration. For example, t = 1 x 10 -14 s for the
AT-cut's c-mode (Qmax= 3.2 million at 5 MHz), t = 9.9 x 10 -15 s for
the SC-cut's c-mode, and t = 4.9 x 10 -15 s for the BT-cut's b-mode.

https://www.vcamerica.com/pub/media/documents/vig3.pdf

The ASC file below shows a 10MHz crystal oscillator.

The Q of the crystal is Q = XL/R = 2 * pi * 1e7 * 25e-3 / 1 = 1,570,796,
which is close to the maximum of 1,591,549.

The total elapsed time is 161.732 seconds, or about 2.68 minutes.

If you are getting a run time of hours or days, you are doing something
wrong.

I get 90 seconds

 

[Steve Wilson]

klaus.kragelund@gmail.com wrote:

On Wednesday, 13 November 2019 13:52:07 UTC+1, Steve Wilson wrote:
Steve Wilson <no@spam.com> wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote:

[...]

You start the oscillator and let it run for an appropriate length of
time,

That's the problem. The appropriate screen time may be hours. Maybe
days with a good time step.

I have never seen more than a few minutes. Your time step is way too
small.

Vig, April 2012, Page 81, shows the maximum Q of a crystal:

The maximum Q of a resonator can be expressed as:

Qmax = 1/(2*pi*F*t)

For 10 MHz,
Qmax = 1/(2*pi*1e7*1e-14) = 1,591,549

where F is the frequency in Hz, and t is an empirically determined
"motional time constant" in seconds, which varies with the angles of
cut and the mode of vibration. For example, t = 1 x 10 -14 s for the
AT-cut's c-mode (Qmax= 3.2 million at 5 MHz), t = 9.9 x 10 -15 s for
the SC-cut's c-mode, and t = 4.9 x 10 -15 s for the BT-cut's b-mode.

https://www.vcamerica.com/pub/media/documents/vig3.pdf

The ASC file below shows a 10MHz crystal oscillator.

The Q of the crystal is Q = XL/R = 2 * pi * 1e7 * 25e-3 / 1 = 1,570,796,
which is close to the maximum of 1,591,549.

The total elapsed time is 161.732 seconds, or about 2.68 minutes.

If you are getting a run time of hours or days, you are doing something
wrong.

I get 90 seconds

Thanks. I have an older computer for legacy and compatibility reasons, and
I'm only running 1 CPU out of a possible 4 in Virtualbox. Your computer is
about twice as fast. That's a good number, which means everybody should get
better results than I do. That should make them glee with joy.

 

[Clifford Heath]

On 13/11/19 10:50 am, John Larkin wrote:

On Wed, 13 Nov 2019 08:23:41 +1100, Clifford Heath
no.spam@please.net> wrote:

On 12/11/19 10:51 pm, Jeroen Belleman wrote:
A real oscillator will start up just fine, but a simulation may or
may not. Either way, it would be wrong to take this as a model of
reality. You *must* kick-start an oscillator simulation.

I have both simulated and built quite a few oscillators using LTSpice,
allowing them to start by amplifying the noise in the models. Anything
reasonable seems to start in LTSpice and in real life, once you get the
gain and phase right. I've never used a kick-start in any case.

High-Q oscillators, especially crystal oscillators, can take thousands
or millions of cycles to settle. And need a small time step to model
accurately. That can make a run take hours.

True, but the way they start and settle tells you quite a lot about the
loop conditions, especially amplitude stability.

I like to force initial conditions close to what the steady-state
values will be. It starts instantly. Then I can zoom up on what it's
doing and see if the amplitude is increasing or decreasing.