Re: [time-nuts] Framework for simulation of oscillators

[Magnus Danielson]

Hi Tom,

On 03/28/2016 04:25 AM, Tom Van Baak wrote:

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

Attila Kinali


I've collected a day of TimeLab/TimePod data at tau 0.001 which is 86'400'000 
datapoints. Should be no problem.

Note Stable32 has a user-configurable limit (Conf -> Data -> 
Max_Data_File_Size). Or you can decimate during reading.

My command line tools have no sample limit (well, just malloc() limited) and 
can be orders of magnitude faster than Stable32 or Timelab since they are batch 
and not GUI.

But this begs the question -- what are you doing with 10M datapoints? Once you 
get beyond a couple of decades of data it's often better to compute statistics 
in segments and display all the segments of the whole as a time series.

So, for example, don't compute a single stddev or ADEV number from the entire 10M data 
set. While this gives an apparently "more precise" measurement due to sampling, 
it will also hide key factors like trends, periodicity, spectral components, outliers, 
and glitches.


Agree. You need to use a better tool for those systematics than ADEV is. 
MDEV and PDEV is even better at filtering out noise and give power 
estimates, which smoothes out it more, which thus just makes it harder 
to discover. The dynamic ADEV can help a litte.


It is the diversity of plots, ADEV, FFT and phase-/frequency-plots 
(residue plots of some suitable matching model) which can help to unveil 
behaviors of interest.


Swapping between MDEV and TDEV can at some times be illustrative.

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.

Re: [time-nuts] Framework for simulation of oscillators

[John Miles]

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

Attila, wasn't this related to an invalid ':' character in the filename coming 
through from VirtualBox?  Or is this issue different from the one we discussed 
in email last month?

-- john, KE5FX
Miles Design LLC

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

Re: [time-nuts] Framework for simulation of oscillators

[Bob Camp]

Hi


> On Mar 27, 2016, at 9:23 PM, John Miles  wrote:
> 
>> BTW: I discovered that Timelab stops processing after 10'000'000 datapoints,
>> which is kind inconvenient when doing a long term measurment...
> 
> It had better not! :)  Any steps to reproduce?
> 


It’s never stopped here …. I routinely run over 10M points.

Bob

> -- john, KE5FX
> Miles Design LLC
> 
> ___
> 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.

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

Re: [time-nuts] Framework for simulation of oscillators

[Magnus Danielson]

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  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
___
time-nuts mailing list -- time-nuts@febo.com
To 

Re: [time-nuts] Framework for simulation of oscillators

[Bruce Griffiths]

I regularly acquire and process over 4x that number using a Timepod.
Bruce
 

On Monday, 28 March 2016 3:02 PM, John Miles  wrote:
 

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

It had better not! :)  Any steps to reproduce?

-- john, KE5FX
Miles Design LLC

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


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

Re: [time-nuts] Framework for simulation of oscillators

[Tom Van Baak]

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

I've collected a day of TimeLab/TimePod data at tau 0.001 which is 86'400'000 
datapoints. Should be no problem.

Note Stable32 has a user-configurable limit (Conf -> Data -> 
Max_Data_File_Size). Or you can decimate during reading.

My command line tools have no sample limit (well, just malloc() limited) and 
can be orders of magnitude faster than Stable32 or Timelab since they are batch 
and not GUI.

But this begs the question -- what are you doing with 10M datapoints? Once you 
get beyond a couple of decades of data it's often better to compute statistics 
in segments and display all the segments of the whole as a time series.

So, for example, don't compute a single stddev or ADEV number from the entire 
10M data set. While this gives an apparently "more precise" measurement due to 
sampling, it will also hide key factors like trends, periodicity, spectral 
components, outliers, and glitches.

I'm not sure if you got your answer on synthetic data, but Stable32 has a data 
noise generator, where you get to specify alpha from -2 to +2. I created 1M 
samples of each of the 5 noise types and use those cached files as a noise 
reference.

See also the 5 noise types in high-res here:

http://www.leapsecond.com/pages/allan/Exploring_Allan_Deviation_v2.pdf
http://www.leapsecond.com/pages/allan/

/tvb
___
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.

Re: [time-nuts] Framework for simulation of oscillators

[John Miles]

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

It had better not! :)  Any steps to reproduce?

-- john, KE5FX
Miles Design LLC

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

Re: [time-nuts] Framework for simulation of oscillators

[Attila Kinali]

N'abend Magnus,

On Tue, 22 Mar 2016 01:11:41 +0100
Magnus Danielson  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.
 
> >> 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.

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

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


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

Attila Kinali


-- 
Reading can seriously damage your ignorance.
-- unknown
___
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.

Re: [time-nuts] Framework for simulation of oscillators

[Magnus Danielson]

Hi,

On 03/21/2016 10:52 PM, Attila Kinali wrote:

Good evening

On Sun, 20 Mar 2016 22:33:15 +0100
Magnus Danielson  wrote:


As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they
will not give very detailed information, but hints. The flicker noise
model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large
Sample Simulation of Flicker Noise".


So far I have seen three approaches to 1/f^a simulation:
* filter in the time domain
* filter in the frequency domain
* simulate a random process with the right properties

Barnes[1], Park[2] on which Brooker[3]
is based on fall into the first category.
Kasdin[4] and Ashby[5] falls into category two (Kasdin also gives a nice
overview of the problem space and the solutions applied there).
 From the third category, i've sofar only read Milotti[6].



Chuck Greenhall have a nice overview of methods for flicker noise, and 
goes in to some depth on it.



If this simulation approach is sufficient for either of your efforts, or
not, depends on what you try to capture. For instance, the oscillators
performance have been idealized in assuming fully linear EFC, fully
linear integrator of the crystal, assuming noise profile etc. This may
or may not be sufficient. Inherent lowpass filtering may be important or
not.


The modeling of the EFC and temperature dependence is orthogonal to the
noise modeling, AFAIK. And if I understand the physical properties of
a crystal, resp. the oscillator correctly, they can be modeled completely
independent without degrading the accuracy. Of course, noise on the EFC
signal will have an influence on the crystal noise, and this noise can
be of 1/f^a type itself as well.


Depending on the tau of interest, temperature variations may or may not 
affect your plots.


Noise on EFC will be filtered, and then integrated.

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.

Re: [time-nuts] Framework for simulation of oscillators

[Magnus Danielson]

On 03/21/2016 11:14 PM, Attila Kinali wrote:

Good nat!

On Sun, 20 Mar 2016 23:52:22 +0100
Magnus Danielson  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


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

Re: [time-nuts] Framework for simulation of oscillators

[Attila Kinali]

Good evening

On Sun, 20 Mar 2016 22:33:15 +0100
Magnus Danielson  wrote:

> As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they 
> will not give very detailed information, but hints. The flicker noise 
> model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large 
> Sample Simulation of Flicker Noise". 

So far I have seen three approaches to 1/f^a simulation:
* filter in the time domain
* filter in the frequency domain
* simulate a random process with the right properties

Barnes[1], Park[2] on which Brooker[3]
is based on fall into the first category.
Kasdin[4] and Ashby[5] falls into category two (Kasdin also gives a nice
overview of the problem space and the solutions applied there).
>From the third category, i've sofar only read Milotti[6].

 
> If this simulation approach is sufficient for either of your efforts, or 
> not, depends on what you try to capture. For instance, the oscillators 
> performance have been idealized in assuming fully linear EFC, fully 
> linear integrator of the crystal, assuming noise profile etc. This may 
> or may not be sufficient. Inherent lowpass filtering may be important or 
> not.

The modeling of the EFC and temperature dependence is orthogonal to the
noise modeling, AFAIK. And if I understand the physical properties of
a crystal, resp. the oscillator correctly, they can be modeled completely
independent without degrading the accuracy. Of course, noise on the EFC
signal will have an influence on the crystal noise, and this noise can
be of 1/f^a type itself as well.
 
Attila Kinali


[1] "Large Sample Simulation of Flicker Noise", by Barnes and Greenhall, 1987
http://www.dtic.mil/dtic/tr/fulltext/u2/a495531.pdf
And its correction:
http://tycho.usno.navy.mil/ptti/1992papers/Vol%2024_44.pdf

[2] "Efficient Modeling of 1/f^2 Noise Using Multirate Process",
by Park, Muhammad, Roy, 2006
http://dx.doi.org/10.1109/TCAD.2005.855953

[3]"Efficient Generation of f^a Noise Sequences for Pulsed Radar Simulation",
by Brooker, Inggs, 2010
http://dx.doi.org/10.1109/TAES.2010.5461653 

[4] "Discrete Simulation of Colored Noise and Stochastic Processes and 1/f^a
Power Law Noise Generation", by Kasdin, 1995
http://www.umbc.edu/photonics/Menyuk/Phase-Noise/kasdin_ProcIEEE_950501n.pdf

[5] "Probability Distributions and Confidence Intervals for Simulated
Power Law Noise", by Neil Ashby, 2015
http://dx.doi.org/10.1109/TUFFC.2013.006167 (open access)

[6] "Exact numerical simulation of power-law noises", by Milotti, 2005
http://dx.doi.org/10.1103/PhysRevE.72.056701


-- 
Reading can seriously damage your ignorance.
-- unknown
___
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.

Re: [time-nuts] Framework for simulation of oscillators

[Magnus Danielson]

Hi Ulrich,

Interesting article. Did you see Craig Nelsons article on building a 
mixer out of 2NA transistors?


Cheers,
Magnus

On 03/21/2016 12:45 AM, ka2...@aol.com wrote:

http://joerg-berkner.de/Fachartikel/pdf/2000_AKB_Berkner_1f_noise.pdf
In a message dated 3/20/2016 5:33:21 P.M. Eastern Daylight Time,
mag...@rubidium.se writes:

Ulrich and Attila,

As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they
will not give very detailed information, but hints. The flicker noise
model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large
Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up
correction. Further, they model the amount of noise and add into the
loop in place of the oscillator, which then has a normal PI-loop.
Such a
simulation can be done fairly efficiently considering that the
oscillator and loop is very simple linear models of phase, not too
different to what I proposed. For the stuff that Attila needs to
simulate, some additional thought needs to go into how to simulate the
effect he is seeing, but a fairly simple approach should be interesting
to try out initially.

The Barnes flicker generator builds on a filter-bank where
the
poles and nulls is placed such that they approximate the flicker noise
slope of 1/tau. This is a generalized variant of Jim Barnes PhD work
where he had fixed relations and where Chuck Greenhall have contributed
significantly by providing means to setup the state of the filter such
that the filter will act as a filter in equilibrium from start, rather
than taking much time to converge, something which may introduce a bias
into the measurement results. I have re-implemented their BASIC-code
into C and run Chuck's original code along-side to verify (just to find
where I did my mistake in converting it).

If this simulation approach is sufficient for either of your
efforts, or
not, depends on what you try to capture. For instance, the oscillators
performance have been idealized in assuming fully linear EFC, fully
linear integrator of the crystal, assuming noise profile etc. This may
or may not be sufficient. Inherent lowpass filtering may be
important or
not.

I've done PLL simulations many times, in fixed integer, in floating
point and in VHDL. It's always a challenge to model it right to the
needs.

Let me also have reader of this thread reminded of TvB's simulator
for a
GPSDO, which is interesting as it adds real GPS PPS data and real open
loop oscillator data with a simple PLL oscillator core you can then
tweak. Great fun in all it's simplicity and nice way to do reality
check. I've done similar things with about the same code amount that
have proved very useful.

However, recall that whenever you make a model, you do it with
assumptions for your particular problem, so some stuff will be left out
and some will be particular to your problem. One guys model may be crap
to another ones problem. There is a few tricks to be learned and a few
things to recall to include.

Cheers,
Magnus

On 03/20/2016 09:19 PM, ka2...@aol.com wrote:
 > I am interested in this topic too, thanks, Ulrich
 > In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight Time,
 > mag...@rubidium.dyndns.org writes:
 >
 >Attila,
 >
 > On 03/17/2016 10:56 AM, Attila Kinali wrote:
 >  > Moin,
 > >
 >  > Measurement we recently did showed some quite unexpected
behaviour
 >  > and I am trying to figure out where this comes from. For this
 > > I would like to simulate our system, which consists of multiple
 >  > crystal oscillators that are coupled in a non-linear way
(kind of
 >  > a vector-PLL with a step transfer function) with a "loop
bandwidth"
 >   > of a few 10kHz.
 >  >
 > > My goal is to simulate the noise properties of the crystal
 > oscillators
 > > both short term (in the 10us range) and long term (several 1000
 > seconds)
 >  > in a way that models reality closely (ie short term
instability
 >is uncorrelated
 >  > while long term instability is correlated through
temp/humidity/...)
 >   >
 >  > As I am pretty sure not the first one to attempt something
like this,
 >  > I would like to ask whether someone has already some software
 >framework
 >  > around for this kind of simulation?
 >  >
 > > 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.
 >
 

Re: [time-nuts] Framework for simulation of oscillators

[KA2WEU--- via time-nuts]

http://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=2270=etd
 
 
 
 
 
 
 
In a message dated 3/20/2016 5:33:21 P.M. Eastern Daylight Time,  
mag...@rubidium.se writes:

Ulrich  and Attila,

As you read the appendixes of ITU-T Rec. G.823, G.824 and  G.825 they 
will not give very detailed information, but hints. The flicker  noise 
model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article  "Large 
Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up  
correction. Further, they model the amount of noise and add into the  
loop in place of the oscillator, which then has a normal PI-loop. Such a  
simulation can be done fairly efficiently considering that the  
oscillator and loop is very simple linear models of phase, not too  
different to what I proposed. For the stuff that Attila needs to  
simulate, some additional thought needs to go into how to simulate the  
effect he is seeing, but a fairly simple approach should be interesting  
to try out initially.

The Barnes flicker generator  builds on a filter-bank where the 
poles and nulls is placed such that they  approximate the flicker noise 
slope of 1/tau. This is a generalized  variant of Jim Barnes PhD work 
where he had fixed relations and where  Chuck Greenhall have contributed 
significantly by providing means to setup  the state of the filter such 
that the filter will act as a filter in  equilibrium from start, rather 
than taking much time to converge,  something which may introduce a bias 
into the measurement results. I have  re-implemented their BASIC-code 
into C and run Chuck's original code  along-side to verify (just to find 
where I did my mistake in converting  it).

If this simulation approach is sufficient for either of your  efforts, or 
not, depends on what you try to capture. For instance, the  oscillators 
performance have been idealized in assuming fully linear EFC,  fully 
linear integrator of the crystal, assuming noise profile etc. This  may 
or may not be sufficient. Inherent lowpass filtering may be important  or 
not.

I've done PLL simulations many times, in fixed integer, in  floating 
point and in VHDL. It's always a challenge to model it right to  the needs.

Let me also have reader of this thread reminded of TvB's  simulator for a 
GPSDO, which is interesting as it adds real GPS PPS data  and real open 
loop oscillator data with a simple PLL oscillator core you  can then 
tweak. Great fun in all it's simplicity and nice way to do  reality 
check. I've done similar things with about the same code amount  that 
have proved very useful.

However, recall that whenever you  make a model, you do it with 
assumptions for your particular problem, so  some stuff will be left out 
and some will be particular to your problem.  One guys model may be crap 
to another ones problem. There is a few tricks  to be learned and a few 
things to recall to  include.

Cheers,
Magnus

On 03/20/2016 09:19 PM,  ka2...@aol.com wrote:
> I am interested in this topic too, thanks,  Ulrich
> In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight  Time,
> mag...@rubidium.dyndns.org writes:
>
>   Attila,
>
> On 03/17/2016 10:56  AM, Attila Kinali wrote:
>  > Moin,
>   >
>  > Measurement we recently  did showed some quite unexpected behaviour
>  >  and I am trying to figure out where this comes from. For this
>   > I would like to simulate our system, which consists of  multiple
>  > crystal oscillators that are coupled  in a non-linear way (kind of
>  > a vector-PLL  with a step transfer function) with a "loop 
bandwidth"
> > of a few 10kHz.
>  >
>   > My goal is to simulate the noise properties of the  crystal
> oscillators
>   > both short term (in the 10us range) and long term (several  1000
> seconds)
>  > in a  way that models reality closely (ie short term instability
>   is uncorrelated
>  > while long term  instability is correlated through 
temp/humidity/...)
> >
>  > As I am pretty sure not the first  one to attempt something like 
this,
>  > I would  like to ask whether someone has already some software
>   framework
>  > around for this kind  of simulation?
>  >
>   > 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.
>
> 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.
>
> 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  

Re: [time-nuts] Framework for simulation of oscillators

[KA2WEU--- via time-nuts]

http://joerg-berkner.de/Fachartikel/pdf/2000_AKB_Berkner_1f_noise.pdf
 
 
 
 
 
 
 
 
In a message dated 3/20/2016 5:33:21 P.M. Eastern Daylight Time,  
mag...@rubidium.se writes:

Ulrich  and Attila,

As you read the appendixes of ITU-T Rec. G.823, G.824 and  G.825 they 
will not give very detailed information, but hints. The flicker  noise 
model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article  "Large 
Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up  
correction. Further, they model the amount of noise and add into the  
loop in place of the oscillator, which then has a normal PI-loop. Such a  
simulation can be done fairly efficiently considering that the  
oscillator and loop is very simple linear models of phase, not too  
different to what I proposed. For the stuff that Attila needs to  
simulate, some additional thought needs to go into how to simulate the  
effect he is seeing, but a fairly simple approach should be interesting  
to try out initially.

The Barnes flicker generator  builds on a filter-bank where the 
poles and nulls is placed such that they  approximate the flicker noise 
slope of 1/tau. This is a generalized  variant of Jim Barnes PhD work 
where he had fixed relations and where  Chuck Greenhall have contributed 
significantly by providing means to setup  the state of the filter such 
that the filter will act as a filter in  equilibrium from start, rather 
than taking much time to converge,  something which may introduce a bias 
into the measurement results. I have  re-implemented their BASIC-code 
into C and run Chuck's original code  along-side to verify (just to find 
where I did my mistake in converting  it).

If this simulation approach is sufficient for either of your  efforts, or 
not, depends on what you try to capture. For instance, the  oscillators 
performance have been idealized in assuming fully linear EFC,  fully 
linear integrator of the crystal, assuming noise profile etc. This  may 
or may not be sufficient. Inherent lowpass filtering may be important  or 
not.

I've done PLL simulations many times, in fixed integer, in  floating 
point and in VHDL. It's always a challenge to model it right to  the needs.

Let me also have reader of this thread reminded of TvB's  simulator for a 
GPSDO, which is interesting as it adds real GPS PPS data  and real open 
loop oscillator data with a simple PLL oscillator core you  can then 
tweak. Great fun in all it's simplicity and nice way to do  reality 
check. I've done similar things with about the same code amount  that 
have proved very useful.

However, recall that whenever you  make a model, you do it with 
assumptions for your particular problem, so  some stuff will be left out 
and some will be particular to your problem.  One guys model may be crap 
to another ones problem. There is a few tricks  to be learned and a few 
things to recall to  include.

Cheers,
Magnus

On 03/20/2016 09:19 PM,  ka2...@aol.com wrote:
> I am interested in this topic too, thanks,  Ulrich
> In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight  Time,
> mag...@rubidium.dyndns.org writes:
>
>   Attila,
>
> On 03/17/2016 10:56  AM, Attila Kinali wrote:
>  > Moin,
>   >
>  > Measurement we recently  did showed some quite unexpected behaviour
>  >  and I am trying to figure out where this comes from. For this
>   > I would like to simulate our system, which consists of  multiple
>  > crystal oscillators that are coupled  in a non-linear way (kind of
>  > a vector-PLL  with a step transfer function) with a "loop 
bandwidth"
> > of a few 10kHz.
>  >
>   > My goal is to simulate the noise properties of the  crystal
> oscillators
>   > both short term (in the 10us range) and long term (several  1000
> seconds)
>  > in a  way that models reality closely (ie short term instability
>   is uncorrelated
>  > while long term  instability is correlated through 
temp/humidity/...)
> >
>  > As I am pretty sure not the first  one to attempt something like 
this,
>  > I would  like to ask whether someone has already some software
>   framework
>  > around for this kind  of simulation?
>  >
>   > 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.
>
> 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.
>
> 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  

Re: [time-nuts] Framework for simulation of oscillators

[Magnus Danielson]

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


Correction: The generalized method was Barnes (NBS TN604), where 
Greenhall presented a paper on init and then Barnes 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 

Re: [time-nuts] Framework for simulation of oscillators

[Attila Kinali]

God kväll Magnus,

On Sun, 20 Mar 2016 20:43:00 +0100
Magnus Danielson  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)

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

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


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


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



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/

-- 
Reading can seriously damage your ignorance.
-- unknown
___
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.

Re: [time-nuts] Framework for simulation of oscillators

[KA2WEU--- via time-nuts]

Thanks, Ulrich
 
 
In a message dated 3/20/2016 5:33:21 P.M. Eastern Daylight Time,  
mag...@rubidium.se writes:

Ulrich  and Attila,

As you read the appendixes of ITU-T Rec. G.823, G.824 and  G.825 they 
will not give very detailed information, but hints. The flicker  noise 
model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article  "Large 
Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up  
correction. Further, they model the amount of noise and add into the  
loop in place of the oscillator, which then has a normal PI-loop. Such a  
simulation can be done fairly efficiently considering that the  
oscillator and loop is very simple linear models of phase, not too  
different to what I proposed. For the stuff that Attila needs to  
simulate, some additional thought needs to go into how to simulate the  
effect he is seeing, but a fairly simple approach should be interesting  
to try out initially.

The Barnes flicker generator  builds on a filter-bank where the 
poles and nulls is placed such that they  approximate the flicker noise 
slope of 1/tau. This is a generalized  variant of Jim Barnes PhD work 
where he had fixed relations and where  Chuck Greenhall have contributed 
significantly by providing means to setup  the state of the filter such 
that the filter will act as a filter in  equilibrium from start, rather 
than taking much time to converge,  something which may introduce a bias 
into the measurement results. I have  re-implemented their BASIC-code 
into C and run Chuck's original code  along-side to verify (just to find 
where I did my mistake in converting  it).

If this simulation approach is sufficient for either of your  efforts, or 
not, depends on what you try to capture. For instance, the  oscillators 
performance have been idealized in assuming fully linear EFC,  fully 
linear integrator of the crystal, assuming noise profile etc. This  may 
or may not be sufficient. Inherent lowpass filtering may be important  or 
not.

I've done PLL simulations many times, in fixed integer, in  floating 
point and in VHDL. It's always a challenge to model it right to  the needs.

Let me also have reader of this thread reminded of TvB's  simulator for a 
GPSDO, which is interesting as it adds real GPS PPS data  and real open 
loop oscillator data with a simple PLL oscillator core you  can then 
tweak. Great fun in all it's simplicity and nice way to do  reality 
check. I've done similar things with about the same code amount  that 
have proved very useful.

However, recall that whenever you  make a model, you do it with 
assumptions for your particular problem, so  some stuff will be left out 
and some will be particular to your problem.  One guys model may be crap 
to another ones problem. There is a few tricks  to be learned and a few 
things to recall to  include.

Cheers,
Magnus

On 03/20/2016 09:19 PM,  ka2...@aol.com wrote:
> I am interested in this topic too, thanks,  Ulrich
> In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight  Time,
> mag...@rubidium.dyndns.org writes:
>
>   Attila,
>
> On 03/17/2016 10:56  AM, Attila Kinali wrote:
>  > Moin,
>   >
>  > Measurement we recently  did showed some quite unexpected behaviour
>  >  and I am trying to figure out where this comes from. For this
>   > I would like to simulate our system, which consists of  multiple
>  > crystal oscillators that are coupled  in a non-linear way (kind of
>  > a vector-PLL  with a step transfer function) with a "loop 
bandwidth"
> > of a few 10kHz.
>  >
>   > My goal is to simulate the noise properties of the  crystal
> oscillators
>   > both short term (in the 10us range) and long term (several  1000
> seconds)
>  > in a  way that models reality closely (ie short term instability
>   is uncorrelated
>  > while long term  instability is correlated through 
temp/humidity/...)
> >
>  > As I am pretty sure not the first  one to attempt something like 
this,
>  > I would  like to ask whether someone has already some software
>   framework
>  > around for this kind  of simulation?
>  >
>   > 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.
>
> 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.
>
> 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.
>
> Similar enough things have been  tried when 

Re: [time-nuts] Framework for simulation of oscillators

[Magnus Danielson]

Ulrich and Attila,

As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they 
will not give very detailed information, but hints. The flicker noise 
model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large 
Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up 
correction. Further, they model the amount of noise and add into the 
loop in place of the oscillator, which then has a normal PI-loop. Such a 
simulation can be done fairly efficiently considering that the 
oscillator and loop is very simple linear models of phase, not too 
different to what I proposed. For the stuff that Attila needs to 
simulate, some additional thought needs to go into how to simulate the 
effect he is seeing, but a fairly simple approach should be interesting 
to try out initially.


The Barnes flicker generator builds on a filter-bank where the 
poles and nulls is placed such that they approximate the flicker noise 
slope of 1/tau. This is a generalized variant of Jim Barnes PhD work 
where he had fixed relations and where Chuck Greenhall have contributed 
significantly by providing means to setup the state of the filter such 
that the filter will act as a filter in equilibrium from start, rather 
than taking much time to converge, something which may introduce a bias 
into the measurement results. I have re-implemented their BASIC-code 
into C and run Chuck's original code along-side to verify (just to find 
where I did my mistake in converting it).


If this simulation approach is sufficient for either of your efforts, or 
not, depends on what you try to capture. For instance, the oscillators 
performance have been idealized in assuming fully linear EFC, fully 
linear integrator of the crystal, assuming noise profile etc. This may 
or may not be sufficient. Inherent lowpass filtering may be important or 
not.


I've done PLL simulations many times, in fixed integer, in floating 
point and in VHDL. It's always a challenge to model it right to the needs.


Let me also have reader of this thread reminded of TvB's simulator for a 
GPSDO, which is interesting as it adds real GPS PPS data and real open 
loop oscillator data with a simple PLL oscillator core you can then 
tweak. Great fun in all it's simplicity and nice way to do reality 
check. I've done similar things with about the same code amount that 
have proved very useful.


However, recall that whenever you make a model, you do it with 
assumptions for your particular problem, so some stuff will be left out 
and some will be particular to your problem. One guys model may be crap 
to another ones problem. There is a few tricks to be learned and a few 
things to recall to include.


Cheers,
Magnus

On 03/20/2016 09:19 PM, ka2...@aol.com wrote:

I am interested in this topic too, thanks, Ulrich
In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight Time,
mag...@rubidium.dyndns.org writes:

Attila,

On 03/17/2016 10:56 AM, Attila Kinali wrote:
 > Moin,
 >
 > Measurement we recently did showed some quite unexpected behaviour
 > and I am trying to figure out where this comes from. For this
 > I would like to simulate our system, which consists of multiple
 > crystal oscillators that are coupled in a non-linear way (kind of
 > a vector-PLL with a step transfer function) with a "loop bandwidth"
 > of a few 10kHz.
 >
 > My goal is to simulate the noise properties of the crystal
oscillators
 > both short term (in the 10us range) and long term (several 1000
seconds)
 > in a way that models reality closely (ie short term instability
is uncorrelated
 > while long term instability is correlated through temp/humidity/...)
 >
 > As I am pretty sure not the first one to attempt something like this,
 > I would like to ask whether someone has already some software
framework
 > around for this kind of simulation?
 >
 > 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.

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.

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.

Similar enough things have been tried when simulating the jitter and
wander in the G.823-825 specs.

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.

I wonder how 

Re: [time-nuts] Framework for simulation of oscillators

[KA2WEU--- via time-nuts]

 
I am interested in this topic too, thanks, Ulrich 

 
 
In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight Time,  
mag...@rubidium.dyndns.org writes:

Attila,

On 03/17/2016 10:56 AM, Attila Kinali wrote:
>  Moin,
>
> Measurement we recently did showed some quite unexpected  behaviour
> and I am trying to figure out where this comes from. For  this
> I would like to simulate our system, which consists of  multiple
> crystal oscillators that are coupled in a non-linear way  (kind of
> a vector-PLL with a step transfer function) with a "loop  bandwidth"
> of a few 10kHz.
>
> My goal is to simulate the  noise properties of the crystal oscillators
> both short term (in the  10us range) and long term (several 1000 seconds)
> in a way that models  reality closely (ie short term instability is 
uncorrelated
> while long  term instability is correlated through temp/humidity/...)
>
> As I  am pretty sure not the first one to attempt something like this,
> I  would like to ask whether someone has already some software framework
>  around for this kind of simulation?
>
> 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.

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.

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.

Similar enough  things have been tried when simulating the jitter and 
wander in the  G.823-825 specs.

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.

I wonder how complex model  you need to build before you have catched the 
characteristics you are  after.

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.

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.

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

Re: [time-nuts] Framework for simulation of oscillators

[Magnus Danielson]

Attila,

On 03/17/2016 10:56 AM, Attila Kinali wrote:

Moin,

Measurement we recently did showed some quite unexpected behaviour
and I am trying to figure out where this comes from. For this
I would like to simulate our system, which consists of multiple
crystal oscillators that are coupled in a non-linear way (kind of
a vector-PLL with a step transfer function) with a "loop bandwidth"
of a few 10kHz.

My goal is to simulate the noise properties of the crystal oscillators
both short term (in the 10us range) and long term (several 1000 seconds)
in a way that models reality closely (ie short term instability is uncorrelated
while long term instability is correlated through temp/humidity/...)

As I am pretty sure not the first one to attempt something like this,
I would like to ask whether someone has already some software framework
around for this kind of simulation?

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.


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.


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.


Similar enough things have been tried when simulating the jitter and 
wander in the G.823-825 specs.


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.


I wonder how complex model you need to build before you have catched the 
characteristics you are after.


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.


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.

[time-nuts] Framework for simulation of oscillators

[Attila Kinali]

Moin,

Measurement we recently did showed some quite unexpected behaviour
and I am trying to figure out where this comes from. For this
I would like to simulate our system, which consists of multiple
crystal oscillators that are coupled in a non-linear way (kind of
a vector-PLL with a step transfer function) with a "loop bandwidth"
of a few 10kHz.

My goal is to simulate the noise properties of the crystal oscillators
both short term (in the 10us range) and long term (several 1000 seconds)
in a way that models reality closely (ie short term instability is uncorrelated
while long term instability is correlated through temp/humidity/...)

As I am pretty sure not the first one to attempt something like this,
I would like to ask whether someone has already some software framework
around for this kind of simulation?

If not, does someone have pointers how to write realistic oscillator models
for this kind of short and long term simulation?


Attila Kinali

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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.

Re: [time-nuts] Framework for simulation of oscillators

[Attila Kinali]

On Thu, 17 Mar 2016 06:20:00 -0700
jimlux  wrote:

> On 3/17/16 2:56 AM, Attila Kinali wrote:
> 
> >
> > As I am pretty sure not the first one to attempt something like this,
> > I would like to ask whether someone has already some software framework
> > around for this kind of simulation?
> >
> > If not, does someone have pointers how to write realistic oscillator models
> > for this kind of short and long term simulation?
> 
> what do you want the output of the model to be?  Samples of the sine 
> wave, time of each cycle, frequency at discrete intervals?

I think the best thing would be to ouptut when each node sends a pulse.
Which happens every n'th clock cycle of the oscillator and are in our
current implementation 50us apart (aka 20kHz). The pulses from all nodes
are closely synchronized (sub ns phase difference). I think for all practical
purposes, we can replace the "high" frequency crystal oscillator by a
"low" frequency one (at the rate of these pulses) that then drives the
algorithm of the nodes (aka the PLL)

I don't really care what happens between these pulses, as we currently cannot
measure it. At a later stage of the project we might be able to do so,
but for the moment,  it's ok if we can correctly describe the behaviour
at tau's between 50us and <10ks.


Attila Kinali

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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.

Re: [time-nuts] Framework for simulation of oscillators

[jimlux]

On 3/17/16 2:56 AM, Attila Kinali wrote:



As I am pretty sure not the first one to attempt something like this,
I would like to ask whether someone has already some software framework
around for this kind of simulation?

If not, does someone have pointers how to write realistic oscillator models
for this kind of short and long term simulation?



what do you want the output of the model to be?  Samples of the sine 
wave, time of each cycle, frequency at discrete intervals?


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