[time-nuts] Framework for simulation of oscillators

Magnus Danielson magnus at rubidium.dyndns.org
Sun Mar 20 18:52:22 EDT 2016


Goder afton Attila,

On 03/20/2016 10:20 PM, Attila Kinali wrote:
> God kväll Magnus,
>
> On Sun, 20 Mar 2016 20:43:00 +0100
> Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
>
>>> If not, does someone have pointers how to write realistic oscillator models
>>> for this kind of short and long term simulation?
>>
>> It is a large field that you tries to cover. What you need to do is
>> actually find the model that models the behavior of your physical setup.
>
> Yes, there is quite a bit I need to cover. I started out to put some stuff
> together yesterday, but I guess it will take me two or three weeks until
> i have something half way usable.
>
>> You need to have white and flicker noises, there is a few ways to get
>> the flicker coloring. I did some hacking of the setup, and ran tests
>> against Chuck Greenhalls original BASIC code.
>
> 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.

Correction: The generalized method was Barnes&Jarvis (NBS TN604), where 
Greenhall presented a paper on init and then Barnes&Greenhall did an 
aggregated article at PTTI 19, with a correction in PTTI 24.

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

>> Similar enough things have been tried when simulating the jitter and
>> wander in the G.823-825 specs.
>
> Thanks, i will have a look at those.

ITU-T G.810-813 is also kind of interesting, with ITU-T G.810 in 
particular. There is a correction for G.810, as I reported a typo in one 
of the formulas. ITU-T G.701 can be also interesting to read and 
contemplate over alongside G.810.

>> An aspect you need to include is the filtering properties of the EFC
>> input, it acts like a low-pass filter, and the Q of the resonator is
>> another catch-point.
>
> The low pass filter is easy to implement, and yes, this will be one
> of the first things i need to implement. One of our guesses is, that
> this low pass filtering helps us getting the high performance we saw.

I think you should try that first, in a fairly linear model. It should 
help explain the locking at least, which is a good start.

> 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 wonder how complex model you need to build before you have catched the
>> characteristics you are after.
>
> 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.

>
>> 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 
which was very annoying as it was only as the phase coasted outside of 
the dead-band that a correction to go back occurred. The pulses you 
mentioned sounds like quite similar. For higher frequencies, they will 
be uncorrected, so only at about the rate of the corrections will the 
oscillators cooperate and lower the performance, and only the ones being 
outside of the limits will experience this push inwards.

Something according to those lines might be where your systems behavior 
can be explained.

Gardner would be a good reference. He was not so keep on those 
phase-detectors.

I had to analyze one such design, ended ripping it out for a much 
simpler S-R FF setup which provided a continuous phase comparison with 
sufficiently resolution proportional phase-detection. The coasting up 
and down was annoying, as the correction bump caused too much jitter.

Cheers,
Magnus

> 	
>
> 			Attila Kinali
>
>
> [1] "Efficient Generation of f^a Noise Sequences for Pulsed Radar Simulation",
> by Brooker, Inggs, 2010
> http://dx.doi.org/10.1109/TAES.2010.5461653
>
> [2] http://rrsg.ee.uct.ac.za/fers/
>


More information about the time-nuts mailing list