Framework for simulation of oscillators
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
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?
On Thu, 17 Mar 2016 06:20:00 -0700
jimlux jimlux@earthlink.net 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
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
God kväll Magnus,
On Sun, 20 Mar 2016 20:43:00 +0100
Magnus Danielson magnus@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)
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
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@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
Good nat!
On Sun, 20 Mar 2016 23:52:22 +0100
Magnus Danielson magnus@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
On 03/21/2016 11:14 PM, Attila Kinali wrote:
Good nat!
On Sun, 20 Mar 2016 23:52:22 +0100
Magnus Danielson magnus@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
N'abend Magnus,
On Tue, 22 Mar 2016 01:11:41 +0100
Magnus Danielson magnus@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.
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
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
I regularly acquire and process over 4x that number using a Timepod.
Bruce
On Monday, 28 March 2016 3:02 PM, John Miles <john@miles.io> 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.
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
Moin,
On Sun, 27 Mar 2016 19:25:30 -0700
"Tom Van Baak" tvb@LeapSecond.com wrote:
BTW: I discovered that Timelab stops processing after 10'000'000 datapoints,
which is kind inconvenient when doing a long term measurment...
I've collected a day of TimeLab/TimePod data at tau 0.001 which is
86'400'000 datapoints. Should be no problem.
I guess it's a bug in the ASCII file import subsystem then..
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.
Yes. I didn't had the time to look closely at your tools and those
that John Ackermann wrote. This will probably happen after EFTF.
(Side note: the measurements discussed below are of a fault tolerant clock
synchronization system prototype, built using of the shelf FPGA boards.
Measuring the phase difference of two nodes of a system consisting of
four nodes)
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.
Currently, it's just data collection. Until now we have mostly run the
system for a couple of hours at a time. The longest measurements we have
done were just two days. So, we are now running a measurment that should
go for at least two weeks, to see if something funny happens.
The data collection is done using some small, hacked together c program
that interfaces with the E5810. I use Timelab to have a look at the
data once in a while to see if the data collection is still ok and whether
anything noteworthy is going on. This is especially important as the
measurements are done in Vienna (ie ~800km away) by a friend who,
unfortunately, is not an electrical engineer.
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've not really done any in depth analysis of the data yet. But so far
it seems like that the data set is very regular, safe for two things:
-
We get a couple of outliers of ~700ps (in average 2 a day) that result
from some issue within the DTS-2075. We have not seen these earlier, so
couldn't investigate them yet. What we see is, that the DTS-2075 reports
measurments of exactly 0 for a couple of 10ms (at one time even up to 100ms),
then the next measurement is in the range of 600-700ps. -
There are short periods (1-2h) of time when the "noise" increases by
a factor of 1.2-1.5. As I wrote in a previous mail, my guess is that we
get some interaction of the nodes when their oscillatof frequenies get
close to each other. Sofar this happend only three times.
Other than that, we have an almost textbook like behavior. The TDEV
decreases with tau^-0.5 up to 100s, from where it flattens out at 5e-13s
and then rises with bumps where one would expect them from temperature
variations. When using a stretch of measurment where 2) does not happen,
the TDEV goes even further down to ~2e-13s.
Just for fun, I also did a plot of sample/bin density of the phase differences
and got a very nice Gaussian bell. A fit of a real Gaus function, revealed
though, that the density distribution is ever so slightly slanted into the
positive direction.
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.
Thanks. We might use that as a reference.
I got a student who will implement a simulation framework (including the
noise generation) for me over spring/summer, with the goal of making
it public under GPL as license.
http://www.leapsecond.com/pages/allan/Exploring_Allan_Deviation_v2.pdf
http://www.leapsecond.com/pages/allan/
Oh.. nice! That's a good reference to have!
Attila Kinali
--
Reading can seriously damage your ignorance.
-- unknown
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@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
Hi
On Mar 27, 2016, at 9:23 PM, John Miles john@miles.io 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.
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
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