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

# Colpitts kick-start in LT Spice

Started by ●November 11, 2019

Reply by ●November 12, 20192019-11-12

Reply by ●November 12, 20192019-11-12

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

Reply by ●November 12, 20192019-11-12

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.

Reply by ●November 12, 20192019-11-12

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

Reply by ●November 12, 20192019-11-12

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.

Reply by ●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.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.

Reply by ●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:>>>> 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

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

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.