> On Thu, 14 Nov 2019 15:46:32 -0600, John S <Sophi.2@invalid.org>
> wrote:
>
>> On 11/12/2019 2:58 PM, John Larkin 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.
>>>
>>>>
>>>> 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.
>>>
>>
>> If you are unhappy with LTSpice, don't use it or make your own
>> simulator. LTSpice is free. What's wrong with you?
>
> I'm not unhapy with LT. I love it. But any numerical simulation of a
> complex physical system will have weirdnesses and numerical
> instabilities and has to be driven carefully.
>
> I have written my own circuit and control system simulators. But LT
> Spice is better. Well, one PLL could probably only be simulated with
> custom code.
>
> You are more interested in being obnoxious than in designing
> electronics. What's wrong with you?
>

PKB

Reply by Joseph Gwinn●November 15, 20192019-11-15

On Nov 13, 2019, Steve Wilson wrote
(in article<XnsAB06794AFB969idtokenpost@144.76.35.198>):

> 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

It can be difficult to decode Vig�s slides without his talk. Look around
and find Vig�s full slide deck in MS PowerPoint. On the Notes pages (not
available in the pdf version it appears), you will find background
information and literature references. This usually solves the Hih? problem.
Joe Gwinn

Reply by John Larkin●November 14, 20192019-11-14

On Thu, 14 Nov 2019 15:46:32 -0600, John S <Sophi.2@invalid.org>
wrote:

>On 11/12/2019 2:58 PM, John Larkin 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.
>>
>>>
>>> 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.
>>
>
>If you are unhappy with LTSpice, don't use it or make your own
>simulator. LTSpice is free. What's wrong with you?

I'm not unhapy with LT. I love it. But any numerical simulation of a
complex physical system will have weirdnesses and numerical
instabilities and has to be driven carefully.
I have written my own circuit and control system simulators. But LT
Spice is better. Well, one PLL could probably only be simulated with
custom code.
You are more interested in being obnoxious than in designing
electronics. What's wrong with you?
--
John Larkin Highland Technology, Inc
picosecond timing precision measurement
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

Reply by John S●November 14, 20192019-11-14

On 11/12/2019 2:58 PM, John Larkin 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.
>
>>
>> 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.
>

If you are unhappy with LTSpice, don't use it or make your own
simulator. LTSpice is free. What's wrong with you?

Reply by Clifford Heath●November 13, 20192019-11-13

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.
>

Reply by Steve Wilson●November 13, 20192019-11-13

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:
>>>
>>>> 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.

I have uploaded an illustration of how to measure 8 parts-per-billion in
LTspice. You can download it at
https://drive.google.com/file/d/1jPoXyNQmRrb5r3hu_6LjNyFHajpsOjp8/view
This turned out to be one of the most difficult articles I have uploaded to
google drive. Please let me know if you have trouble following it.

Reply by Steve Wilson●November 13, 20192019-11-13

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.

Reply by ●November 13, 20192019-11-13

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 :-)

Reply by Steve Wilson●November 13, 20192019-11-13

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:

>>>> 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.

>>>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

Reply by Steve Wilson●November 12, 20192019-11-12

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.

> 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.