On 03/21/2016 11:14 PM, Attila Kinali wrote:
Good nat!
On Sun, 20 Mar 2016 23:52:22 +0100
Magnus Danielson <mag...@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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
