[time-nuts] Framework for simulation of oscillators

Magnus Danielson magnus at rubidium.dyndns.org
Mon Mar 21 20:11:41 EDT 2016



On 03/21/2016 11:14 PM, Attila Kinali wrote:
> Good nat!
>
> On Sun, 20 Mar 2016 23:52:22 +0100
> Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
>
>>> I'm currently using the code from Brooker and Inggs[1,2], but the code
>>> is quite convoluted and it will take me some time to extract it and
>>> get it working properly. (but then, it's the only piece of code
>>> that I found that does seem to be viable at all)
>>
>> Could not get to the article. Looking at the code, it honestly does not
>> seem to be very different to that of Barnes&Greenhall.
>
> It is very similar in the approach. The only difference is that it
> uses a multirate filter chain with multiple gaussian noise sources
> instead of filtering just one. This and one additional trick make
> this numerically more efficient then the Barnes&Greenhall approach,
> especially when long simulation times with high accuracy are needed.

I have been considering similar methods, fairly natural development for 
long-term stuff.

>>>> You probably want a systematic effect model of phase, frequency and
>>>> drift. Also a cubic frequency vs. temperature. All the properties needs
>>>> to be different for each instance. Similarly, the flicker filter needs
>>>> to be independent for each oscillator.
>>>
>>> What do you mean with "the flicker filter needs to be independent"?
>>> Each oscillator will get its own noise source, if you mean that.
>>
>> Yes. When you have a white noise-source, you can take all your samples
>> from the same source. With non-white sources, you take white noise and
>> filter it, that filtering mechanism holds a state, and if you need two
>> or more independent sources, then that state would make the assumption
>> of independent sources invalid.
>
> Yes, of course. Noise is generally not i.i.d. and thus one cannot use
> the same generator for more than one model in the same simulation.
>
> Oh.. and just to make things more complicated: Gaussian noise is not
> necessarily white (only if it's Gaussian distributed and i.i.d.).
> And noise with white spectrum is not necessarily Gaussian or i.i.d.
> (only if phase and amplitude noise are both white).

Indeed.

BTW. You are increasingly PhD damaged in your use of abbreviations 
without explaining them on first use, as you should.

>>> I am not sure yet, how to model the Q, or whether that actually needs
>>> to be modelled with anything else but the proper noise/stability
>>> characteristics and the low pass on the EFC.
>>
>> Consider that you have an integrator for the oscillator, and a null due
>> to the Q. Look at the Leeson model (Feb 1966), see also Enrico's book on
>> phase noise.
>
> I don't see how the Q, beside acting as an integrator, will affect my system
> (keep in mind, the "loop" is non-linear). But I havent gone through the
> math here...

Without going through Leeson in details, only the part of the spectrum 
being inside of the f/Q bandwidth will behave as integration for the 
noise inside the loop. Signals from the outside will integrate, after 
being low-pass filtered by the f/Q bandwidth. The oscillator is just 
like a loop.

>>> The current plan is to implement an oscillator model that mimics the
>>> correct stability i'm seeing, then add EFC (first w/o low pass filtering).
>>> This should already work "properly" and give a first indication on how
>>> the system behaves. Then step by step add the non-idealities, like the
>>> low pass filter on the EFC, the high DNL of the TDC, the noise on the
>>> pulse output and the TDC input, ... until I get close to what we measure.
>>
>> Just being able to simulate the locking mechanism should be a good
>> start. Then you should try to get it to simulate the noise-curves you're
>> seeing.
>
> Not all noise curves. The high jitter is mostly due to the DNL (and thus
> lack of accuracy) of the TDC. Leaving this out will give me the imporovement
> of stability compared to the free running oscillator, but will be quite a bit
> better than with the TDC correctly modelled.

TDC and noise is "interesting".

>>>> The EFC measures you have done so far indicate that your steering
>>>> essentially operates as if you do where doing something similar to
>>>> charge-pump operation.
>>>
>>> Hmm.. can you elaborate a bit on why you think so?
>>
>> The correction pulse every now and then is how a charge-pump PLL
>> operates. In between the corrections the oscillator coasts undiciplined
>> with the filters state as memory. The 4046 charge-pump has a dead-band
>
> Ah.. Well, I have only ever used modern charge pump PLLs that don't have
> the dead band issue (or at least not to the extend to be annoying) :-)

Depends on what you are doing. For some stuff it may be good enough.

>> Something according to those lines might be where your systems behavior
>> can be explained.
>
> Well, we do not really have a deadband (save the TDC resolution and
> my guess is that the inherent noise in the system does a good job
> in decreasing this "deadband" as well). The long cycle time results
> rather in a small loop bandwidth. As we only measure one pulse per
> cycle, everything that happens between pulses averages out. Ie if we
> have any deadband like jitter behavior, we don't see it.

Well, maybe not really, but what you have is kinda similar as the 
outermost will have a higher gain being pushed back and the more central 
will have weaker pull-in. The time between pulses is indeed a measure to 
loop time-constant/bandwidth.

I just say the dead-band give similar pulses.

Cheers,
Magnus


More information about the time-nuts mailing list