[time-nuts] Framework for simulation of oscillators

[Attila Kinali]

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

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

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

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

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



			Attila Kinali

-- 
Reading can seriously damage your ignorance.
		-- unknown