[time-nuts] Framework for simulation of oscillators

Magnus Danielson magnus at rubidium.dyndns.org
Mon Mar 28 07:45:38 EDT 2016


Goddag Attila,

On 03/28/2016 01:48 AM, Attila Kinali wrote:
> N'abend Magnus,
>
> On Tue, 22 Mar 2016 01:11:41 +0100
> Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
>
>>> 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.
>
> Oops.. sorry about that.
> i.i.d = independent, identically distributed.
> I.e. the samples have all the same probability density function,
> which does not change over time and does not depend on any previous samples.

Indeed.

You can have noise which at first look seems Gaussian, but isn't, as 
there is systematics hidden within it. For proper estimations the 
systematics needs to be separated from the random noise and both 
estimated without the effect of the other, as they then can scale 
significantly different depending on what question you ask about the 
system. For communications I use a scale factor of 14 for the Bit Error 
Rate (BER) of 1E-12 (the value of 14 is an approximation, but since you 
need margin on it, it's fine to get the right proportions).

Another aspect is that noise which looks Gaussian at first look can hide 
other noises such as flicker etc. which only reveal itself for longer 
observations times.

As we deal with oscillators, we have three or four noise-forms to deal with.

>>>> 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.
>
> I think I get what are are hinting at, but I do not fully understand it.
> I guess we should discuss this next week in York.

It's a loop with an integrator in it. Signals inside the loop and 
signals outside (being introduced into the loop) the loop will have 
different filtering effects on them. No big magic, but it is easier to 
show with paper and pen.

Seems that my link to the Leeson paper got lost.

>>>> 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.
>
> We currently have a long term measurement running. And there are
> intermittent rises in "noise" of the node pair we are measuring.
> My assumption is that the order of the center frequencies of the
> oscillators changed, thus swapping two of the nodes in their pulse
> time order. When two nodes get close to eachother the algorithm
> switches between using nodes A & B and using nodes A & C. This can
> indeed be seen as a deadband behaviour.

Yes. I meant it as somewhat of an analogy. Notice how each of your nodes 
makes independent choices and how a shift in such a choice will 
indirectly affect the other nodes through how the node will steer it's 
own oscillator.

> I'll look further into that behavior as soon as we have some simulation
> system running and I see more than one node pair.

Can you record the TICs and the "selected TICs" (essentially 1 bit of if 
the TIC was selected or not in each min/max elimination round)?
That would suffice to analyze the systems internal dynamics. External 
TIC measurements is only to evaluate the variances for an external 
viewer (which the system itself isn't really able to fully value, as the 
common mode variations isn't observeable).

> BTW: I discovered that Timelab stops processing after 10'000'000 datapoints,
> which is kind inconvenient when doing a long term measurment...

I didn't know that. Good to know.

Cheers,
Magnus


More information about the time-nuts mailing list