time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

Can the ADEV of a GPSDO output ever be lower than the minimum of the ADEV of the internal oscilator and the ADEV of the GPS PPS?

CA
Carsten Andrich
Mon, May 2, 2022 9:32 PM

Hi Bob, Markus,

although we do regularly rely on FS740s for synchronization of our
distributed RF measurements, I have to agree with Bob. While the
predictive filtering sounds great, I have reason to believe that it
actually is detrimental to the common view time transfer we use the
FS740 for.

I've attach results of a measurement similar to our paper I've cited
before. It visualizes the time difference between two FS740 spaced 1.25
km apart. Both FS740s' GNSS antennas have almost unobstructed view of
the hemisphere. The gray scatter plot is the current time error between
GNSS and internal timebase as logged by both FS740s. From the way I
understand the manual [1] this refers to the actual raw GNSS PPS. The
solid blue line is a low-pass filtered version of the gray scatter plot.

The orange scatter plot is the time difference of arrival (TDoA) of the
line of sight (LoS) path between an RF emitter and two RF receivers
synchronized to the FS740s' 10 MHz output. It's intermittent, as we only
use it for occasional calibration with a stationary emitter. Only these
calibration measurements with stationary emitter at guaranteed LoS
locations are shown. The TDoA is corrected for propagation delay. As you
can see, the raw TDoA estimations (orange) are subject to a ~5 ns
long-term "wiggle".

In post-processing, we use the low-pass filtered GNSS PPS time error
(blue line) to correct the wiggly raw TDoA, yielding the green scatter
plot. That brings the standard deviation down from 1.27 ns (orange) to
0.48 ns (green), presumably by fighting the state space filtering and
going for an old-fashioned low-pass filter on the jittery PPS.

Best regards,
Carsten

[1] https://www.thinksrs.com/downloads/pdfs/manuals/FS740m.pdf#page=53

On 02.05.22 14:06, Markus Kleinhenz via time-nuts wrote:

Hi Bob,

thanks for the heads-up. The only other source I had was a paper
claiming similar things, but they had only done so in simulations.
So I thought the manual of the FS740 would be the more trustworthy of
the two.

Greetings
Markus

Am 02.05.2022 um 13:38 schrieb Bob kb8tq:

Hi

If you have a FS740 and measure it’s performance …. you likely will
take anything the manual says a lot less seriously ….. Their ADEV
performance in the real world is a bit underwhelming.

Bob

On May 2, 2022, at 1:42 AM, Markus Kleinhenz via time-nuts time-nuts@lists.febo.com wrote:

Hi Erik,

I just found a hint that what you are seeing may be correct after all:

The Manual of the Stanford Research Systems FS740 says:

 /*Predictive Filtering*//
 //The superior short term stabilities of the OCXO and Rb timebases
 enable the usage of//
 //predictive filtering to improve the stability of the FS740 by up
 to 3 times over traditional//
 //methods. Predictive filtering uses state space methods to predict
 the phase of the local//
 //timebase relative to GNSS. The technique is quite similar to
 Kalman filtering. The//
 //benefit is that the FS740 can average the GNSS signal much more
 effectively, resulting//
 //in a significantly more stable signal with a much shorter time
 constant than would be//
 //possible with traditional filtering./

And has the ADEV Plots I attached. The GPS curve they printed is in the
realm of a sawtooth corrected M8T (<1e-12 @ tau=10ks) [See the Plot from
John Ackermanns Ublox evaluation]. But especially the Rb option seems to
surpass the reference in a parallel fashion.

My two cents on simulated 1PPS Signals:

One has to be careful when only using ADEV as the only characteristic
for modeling the 1PPS Signal as it combines White PM and Flicker PM in
one slope. So you may create an artificial signal which is pure WPN and
in turn is best predicted by something like the kalman filter.

Regards,

Markus

Am 29.04.2022 um 19:24 schrieb Erik Kaashoek:

Thanks for confirming something is still wrong. :-(
I've extended the simulation to contain a full Kalman filter working
with 2 state parameters: phase and frequency.
The biggest impact I can see is when increasing Kp above the optimal
value the PPS noise normally starts to impact the output phase and the
ADEV at tau 1 becomes worse
The Kalman filter seems to be able to filter the noise from the PPS
better so with equally high Kp the ADEV at tau =1 is about a factor 4
better
Unfortunately the high Kp of 0.1 is far from optimal and setting Kp to
0.01 gives overall a better performance and the Kalman filter no
longer seem to have a visible impact.
Octave code for the simulation and the used data files are attached.
Also 3 plots are attached showing optimal Kp, high Kp with no filter
and high Kp with Kalman filer
I'm still seeing some weird stuff in the ADEV plots.
Erik.

On 29-4-2022 16:53, André Balsa wrote:

Hi Erik,
Mathematically, no, a GPSDO cannot have a lower uncertainty (ADEV)
than the
minimum observable uncertainty (ADEV) of the combined oscillator
(disciplined clock) and PPS (disciplining clock) from the GPS receiver.
Unless there is some magic trick to remove the uncertainty in a clock
that
I am not aware of. ;)

On Thu, Apr 28, 2022 at 10:03 PM Erik Kaashoek erik@kaashoek.com
wrote:

I'm doing some simulations to understand the impact of a filter
between the
TIC measurement and the PI controller steering the Vtune of the OCXO.
With a well tuned PI controller without filter the best ADEV I can
get is
just above the minimum ADEV of an actual measured  OCXO and an actual
measured GPS PPS.
When I add an alpha-beta filter, similar to a first order Kalman filter
with a manually tuned Kalman gain, and using similar Kp, Ki, the
overall
performance does not change (much)
However with the filter its is possible to increase the Kp, Ki with a
factor 10 and when I use in the simulation instead of a measured PPS an
artificial PPS created from noise with the same ADEV as the GPS PP
but with
a very constant phase (different from the varying phase of a GPS
PPS)  the
ADEV of the GPSDO output in my simulation seems to drops below the
ADEV of
the PPS. Am I correct to assume this is a hint there is still something
wrong in the simulation or was my initial assumption about the possible
range of the GPSDO ADEV wrong?
Erik.

<FS740_ADEV.PNG><UBLOX_QERR_ADEV.PNG>_______________________________________________


time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.

--
M.Sc. Carsten Andrich

Technische Universität Ilmenau
Fachgebiet Elektronische Messtechnik und Signalverarbeitung (EMS)
Helmholtzplatz 2
98693 Ilmenau
T +49 3677 69-4269

Hi Bob, Markus, although we do regularly rely on FS740s for synchronization of our distributed RF measurements, I have to agree with Bob. While the predictive filtering sounds great, I have reason to believe that it actually is detrimental to the common view time transfer we use the FS740 for. I've attach results of a measurement similar to our paper I've cited before. It visualizes the time difference between two FS740 spaced 1.25 km apart. Both FS740s' GNSS antennas have almost unobstructed view of the hemisphere. The gray scatter plot is the current time error between GNSS and internal timebase as logged by both FS740s. From the way I understand the manual [1] this refers to the actual raw GNSS PPS. The solid blue line is a low-pass filtered version of the gray scatter plot. The orange scatter plot is the time difference of arrival (TDoA) of the line of sight (LoS) path between an RF emitter and two RF receivers synchronized to the FS740s' 10 MHz output. It's intermittent, as we only use it for occasional calibration with a stationary emitter. Only these calibration measurements with stationary emitter at guaranteed LoS locations are shown. The TDoA is corrected for propagation delay. As you can see, the raw TDoA estimations (orange) are subject to a ~5 ns long-term "wiggle". In post-processing, we use the low-pass filtered GNSS PPS time error (blue line) to correct the wiggly raw TDoA, yielding the green scatter plot. That brings the standard deviation down from 1.27 ns (orange) to 0.48 ns (green), presumably by fighting the state space filtering and going for an old-fashioned low-pass filter on the jittery PPS. Best regards, Carsten [1] https://www.thinksrs.com/downloads/pdfs/manuals/FS740m.pdf#page=53 On 02.05.22 14:06, Markus Kleinhenz via time-nuts wrote: > Hi Bob, > > thanks for the heads-up. The only other source I had was a paper > claiming similar things, but they had only done so in simulations. > So I thought the manual of the FS740 would be the more trustworthy of > the two. > > Greetings > Markus > > Am 02.05.2022 um 13:38 schrieb Bob kb8tq: >> Hi >> >> If you have a FS740 and measure it’s performance …. you likely will >> take anything the manual says a lot less seriously ….. Their ADEV >> performance in the real world is a bit underwhelming. >> >> Bob >> >>> On May 2, 2022, at 1:42 AM, Markus Kleinhenz via time-nuts <time-nuts@lists.febo.com> wrote: >>> >>> Hi Erik, >>> >>> I just found a hint that what you are seeing may be correct after all: >>> >>> The Manual of the Stanford Research Systems FS740 says: >>> >>> /*Predictive Filtering*// >>> //The superior short term stabilities of the OCXO and Rb timebases >>> enable the usage of// >>> //predictive filtering to improve the stability of the FS740 by up >>> to 3 times over traditional// >>> //methods. Predictive filtering uses state space methods to predict >>> the phase of the local// >>> //timebase relative to GNSS. The technique is quite similar to >>> Kalman filtering. The// >>> //benefit is that the FS740 can average the GNSS signal much more >>> effectively, resulting// >>> //in a significantly more stable signal with a much shorter time >>> constant than would be// >>> //possible with traditional filtering./ >>> >>> And has the ADEV Plots I attached. The GPS curve they printed is in the >>> realm of a sawtooth corrected M8T (<1e-12 @ tau=10ks) [See the Plot from >>> John Ackermanns Ublox evaluation]. But especially the Rb option seems to >>> surpass the reference in a parallel fashion. >>> >>> My two cents on simulated 1PPS Signals: >>> >>> One has to be careful when only using ADEV as the only characteristic >>> for modeling the 1PPS Signal as it combines White PM and Flicker PM in >>> one slope. So you may create an artificial signal which is pure WPN and >>> in turn is best predicted by something like the kalman filter. >>> >>> Regards, >>> >>> Markus >>> >>> Am 29.04.2022 um 19:24 schrieb Erik Kaashoek: >>>> Thanks for confirming something is still wrong. :-( >>>> I've extended the simulation to contain a full Kalman filter working >>>> with 2 state parameters: phase and frequency. >>>> The biggest impact I can see is when increasing Kp above the optimal >>>> value the PPS noise normally starts to impact the output phase and the >>>> ADEV at tau 1 becomes worse >>>> The Kalman filter seems to be able to filter the noise from the PPS >>>> better so with equally high Kp the ADEV at tau =1 is about a factor 4 >>>> better >>>> Unfortunately the high Kp of 0.1 is far from optimal and setting Kp to >>>> 0.01 gives overall a better performance and the Kalman filter no >>>> longer seem to have a visible impact. >>>> Octave code for the simulation and the used data files are attached. >>>> Also 3 plots are attached showing optimal Kp, high Kp with no filter >>>> and high Kp with Kalman filer >>>> I'm still seeing some weird stuff in the ADEV plots. >>>> Erik. >>>> >>>> On 29-4-2022 16:53, André Balsa wrote: >>>>> Hi Erik, >>>>> Mathematically, no, a GPSDO cannot have a lower uncertainty (ADEV) >>>>> than the >>>>> minimum observable uncertainty (ADEV) of the combined oscillator >>>>> (disciplined clock) and PPS (disciplining clock) from the GPS receiver. >>>>> Unless there is some magic trick to remove the uncertainty in a clock >>>>> that >>>>> I am not aware of. ;) >>>>> >>>>> On Thu, Apr 28, 2022 at 10:03 PM Erik Kaashoek <erik@kaashoek.com> >>>>> wrote: >>>>> >>>>>> I'm doing some simulations to understand the impact of a filter >>>>>> between the >>>>>> TIC measurement and the PI controller steering the Vtune of the OCXO. >>>>>> With a well tuned PI controller without filter the best ADEV I can >>>>>> get is >>>>>> just above the minimum ADEV of an actual measured OCXO and an actual >>>>>> measured GPS PPS. >>>>>> When I add an alpha-beta filter, similar to a first order Kalman filter >>>>>> with a manually tuned Kalman gain, and using similar Kp, Ki, the >>>>>> overall >>>>>> performance does not change (much) >>>>>> However with the filter its is possible to increase the Kp, Ki with a >>>>>> factor 10 and when I use in the simulation instead of a measured PPS an >>>>>> artificial PPS created from noise with the same ADEV as the GPS PP >>>>>> but with >>>>>> a very constant phase (different from the varying phase of a GPS >>>>>> PPS) the >>>>>> ADEV of the GPSDO output in my simulation seems to drops below the >>>>>> ADEV of >>>>>> the PPS. Am I correct to assume this is a hint there is still something >>>>>> wrong in the simulation or was my initial assumption about the possible >>>>>> range of the GPSDO ADEV wrong? >>>>>> Erik. >>>>>> >>> <FS740_ADEV.PNG><UBLOX_QERR_ADEV.PNG>_______________________________________________ > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com > To unsubscribe, go to and follow the instructions there. -- M.Sc. Carsten Andrich Technische Universität Ilmenau Fachgebiet Elektronische Messtechnik und Signalverarbeitung (EMS) Helmholtzplatz 2 98693 Ilmenau T +49 3677 69-4269
EK
Erik Kaashoek
Thu, May 5, 2022 6:39 AM

André

I've completed a comparison between simulation and measurement.
In the simulation [1] you see the GPSDO ADEV pushed below the OCXO and
PPS ADEV around the intersection of the PPS ADEV with the OCXO ADEV.
In an actual measurement [2] with identical controller and controller
parameters I see the same.
So there is no need to worry and the behavior is understood
Erik

[1] http://athome.kaashoek.com/time-nuts/GPSDO_simulation.JPG
[2]http://athome.kaashoek.com/time-nuts/GPSDO_measurement.JPG

On 30-4-2022 5:41, André Balsa wrote:

Hi Eric,
I am probably missing something, but I don't see anything wrong with the
ADEV plots, to me they make sense and look exactly as expected: with an
optimal Kp the GPSDO's ADEV combines the OCXO ADEV with the PPS ADEV at
around the point where these curves intersect which is indeed an optimal
behavior. And with non-optimal Kp values this is not achieved. In other
words, exactly what can be expected.

What am I missing?

On Fri, Apr 29, 2022 at 11:43 PM Erik Kaashoek erik@kaashoek.com wrote:

Thanks for confirming something is still wrong. :-(
I've extended the simulation to contain a full Kalman filter working
with 2 state parameters: phase and frequency.
The biggest impact I can see is when increasing Kp above the optimal
value the PPS noise normally starts to impact the output phase and the
ADEV at tau 1 becomes worse
The Kalman filter seems to be able to filter the noise from the PPS
better so with equally high Kp the ADEV at tau =1 is about a factor 4
better
Unfortunately the high Kp of 0.1 is far from optimal and setting Kp to
0.01 gives overall a better performance and the Kalman filter no longer
seem to have a visible impact.
Octave code for the simulation and the used data files are attached.
Also 3 plots are attached showing optimal Kp, high Kp with no filter and
high Kp with Kalman filer
I'm still seeing some weird stuff in the ADEV plots.
Erik.

On 29-4-2022 16:53, André Balsa wrote:

Hi Erik,
Mathematically, no, a GPSDO cannot have a lower uncertainty (ADEV) than

the

minimum observable uncertainty (ADEV) of the combined oscillator
(disciplined clock) and PPS (disciplining clock) from the GPS receiver.
Unless there is some magic trick to remove the uncertainty in a clock

that

I am not aware of. ;)

On Thu, Apr 28, 2022 at 10:03 PM Erik Kaashoek erik@kaashoek.com

wrote:

I'm doing some simulations to understand the impact of a filter between

the

TIC measurement and the PI controller steering the Vtune of the OCXO.
With a well tuned PI controller without filter the best ADEV I can get

is

just above the minimum ADEV of an actual measured  OCXO and an actual
measured GPS PPS.
When I add an alpha-beta filter, similar to a first order Kalman filter
with a manually tuned Kalman gain, and using similar Kp, Ki, the overall
performance does not change (much)
However with the filter its is possible to increase the Kp, Ki with a
factor 10 and when I use in the simulation instead of a measured PPS an
artificial PPS created from noise with the same ADEV as the GPS PP but

with

a very constant phase (different from the varying phase of a GPS PPS)

the

ADEV of the GPSDO output in my simulation seems to drops below the ADEV

of

the PPS. Am I correct to assume this is a hint there is still something
wrong in the simulation or was my initial assumption about the possible
range of the GPSDO ADEV wrong?
Erik.


time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe

send

an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.


time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe

To unsubscribe, go to and follow the instructions there.


time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send
an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.


time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.

André I've completed a comparison between simulation and measurement. In the simulation [1] you see the GPSDO ADEV pushed below the OCXO and PPS ADEV around the intersection of the PPS ADEV with the OCXO ADEV. In an actual measurement [2] with identical controller and controller parameters I see the same. So there is no need to worry and the behavior is understood Erik [1] http://athome.kaashoek.com/time-nuts/GPSDO_simulation.JPG [2]http://athome.kaashoek.com/time-nuts/GPSDO_measurement.JPG On 30-4-2022 5:41, André Balsa wrote: > Hi Eric, > I am probably missing something, but I don't see anything wrong with the > ADEV plots, to me they make sense and look exactly as expected: with an > optimal Kp the GPSDO's ADEV combines the OCXO ADEV with the PPS ADEV at > around the point where these curves intersect which is indeed an optimal > behavior. And with non-optimal Kp values this is not achieved. In other > words, exactly what can be expected. > > What am I missing? > > On Fri, Apr 29, 2022 at 11:43 PM Erik Kaashoek <erik@kaashoek.com> wrote: > >> Thanks for confirming something is still wrong. :-( >> I've extended the simulation to contain a full Kalman filter working >> with 2 state parameters: phase and frequency. >> The biggest impact I can see is when increasing Kp above the optimal >> value the PPS noise normally starts to impact the output phase and the >> ADEV at tau 1 becomes worse >> The Kalman filter seems to be able to filter the noise from the PPS >> better so with equally high Kp the ADEV at tau =1 is about a factor 4 >> better >> Unfortunately the high Kp of 0.1 is far from optimal and setting Kp to >> 0.01 gives overall a better performance and the Kalman filter no longer >> seem to have a visible impact. >> Octave code for the simulation and the used data files are attached. >> Also 3 plots are attached showing optimal Kp, high Kp with no filter and >> high Kp with Kalman filer >> I'm still seeing some weird stuff in the ADEV plots. >> Erik. >> >> On 29-4-2022 16:53, André Balsa wrote: >>> Hi Erik, >>> Mathematically, no, a GPSDO cannot have a lower uncertainty (ADEV) than >> the >>> minimum observable uncertainty (ADEV) of the combined oscillator >>> (disciplined clock) and PPS (disciplining clock) from the GPS receiver. >>> Unless there is some magic trick to remove the uncertainty in a clock >> that >>> I am not aware of. ;) >>> >>> On Thu, Apr 28, 2022 at 10:03 PM Erik Kaashoek <erik@kaashoek.com> >> wrote: >>>> I'm doing some simulations to understand the impact of a filter between >> the >>>> TIC measurement and the PI controller steering the Vtune of the OCXO. >>>> With a well tuned PI controller without filter the best ADEV I can get >> is >>>> just above the minimum ADEV of an actual measured OCXO and an actual >>>> measured GPS PPS. >>>> When I add an alpha-beta filter, similar to a first order Kalman filter >>>> with a manually tuned Kalman gain, and using similar Kp, Ki, the overall >>>> performance does not change (much) >>>> However with the filter its is possible to increase the Kp, Ki with a >>>> factor 10 and when I use in the simulation instead of a measured PPS an >>>> artificial PPS created from noise with the same ADEV as the GPS PP but >> with >>>> a very constant phase (different from the varying phase of a GPS PPS) >> the >>>> ADEV of the GPSDO output in my simulation seems to drops below the ADEV >> of >>>> the PPS. Am I correct to assume this is a hint there is still something >>>> wrong in the simulation or was my initial assumption about the possible >>>> range of the GPSDO ADEV wrong? >>>> Erik. >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe >> send >>>> an email to time-nuts-leave@lists.febo.com >>>> To unsubscribe, go to and follow the instructions there. >>>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe >> send an email to time-nuts-leave@lists.febo.com >>> To unsubscribe, go to and follow the instructions there. >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send >> an email to time-nuts-leave@lists.febo.com >> To unsubscribe, go to and follow the instructions there. > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com > To unsubscribe, go to and follow the instructions there.
AK
Attila Kinali
Mon, May 9, 2022 9:05 PM

On Fri, 29 Apr 2022 16:53:58 +0200
André Balsa andrebalsa@gmail.com wrote:

Mathematically, no, a GPSDO cannot have a lower uncertainty (ADEV) than the
minimum observable uncertainty (ADEV) of the combined oscillator
(disciplined clock) and PPS (disciplining clock) from the GPS receiver.
Unless there is some magic trick to remove the uncertainty in a clock that
I am not aware of. ;)

This is not quite true.

Keep in mind that the *DEV metrics all implicitly assume that the noise
is Gauss distributed and has a PSD of the form of 1/f^a, a ∊ [0,4]
and a high-frequency cut-off. The moment you leave this relatively
restrictive class of functions you have to validate that the *DEV metric
you are using is still producing what you think it does. One common function
for which we have done this are quadratic functions (with noise), also
known as "linear frequency drift". But we have done so for a scant few
other functions.

If you have read my mail a few days ago, then you might have noticed that
few oscillators we have actually fit into this class. And the "worse" they
are, the less they fit. An OCXO can have sudden phase and frequency jumps.
Not to mention its temperature dependency which will lead to some phase
function which looks noise like, even slightly self-similar (another
characteristic of 1/f^a noise), but actually isn't. There is some periodic
behaviour in it, at different repetition rates, together with linear,
quadratic and cubic components. Go to a TCXO or even a simple XO and
things get even worse.

I can't go into the mathematical details as I don't have nearly enough
knowledge about the nitty gritty stuff of *DEV. But we have people here
who know way more than I do, who could chip in.

As for the case at hand. There has been a plot of the TCXO's free running
behaviour earlier. In which one could see that the TCXO had some quite
distinct frequency steps, presumably from the temperature compensation.
Between these the phase was pretty stable. Which means the ADEV gets
detoriated by the frequency steps and doesn't see these "flat" portions
inbetween, not to mention it breaks with the assumption which ADEV is
built upon. Now, if the control loop hits a sweet spot where the loop
compensates these frequency steps quickly but without degrading the
"flat" portions inbetween, then the ADEV of the combined TCXO + PPS + control loop
could indeed be lower than the individual components. But without a closer
look at what happens to the phase, it is hard to tell whether this is a
genuine effect of the control loop, an artifact of the simulation or simply
a bug somewhere.

		Attila Kinali

PS: Please, for the sake of all that is ticking, whenever you post an *DEV plot,
add error bars. *DEV are statistical figures. And like all statistical figures
they have an uncertainty. Without the error bars it is hard to judge whether the
values are statistically significant or just some randomly thrown dice because
of not enough data.

--
In science if you know what you are doing you should not be doing it.
In engineering if you do not know what you are doing you should not be doing it.
-- Richard W. Hamming, The Art of Doing Science and Engineering

On Fri, 29 Apr 2022 16:53:58 +0200 André Balsa <andrebalsa@gmail.com> wrote: > Mathematically, no, a GPSDO cannot have a lower uncertainty (ADEV) than the > minimum observable uncertainty (ADEV) of the combined oscillator > (disciplined clock) and PPS (disciplining clock) from the GPS receiver. > Unless there is some magic trick to remove the uncertainty in a clock that > I am not aware of. ;) This is not quite true. Keep in mind that the *DEV metrics all implicitly assume that the noise is Gauss distributed and has a PSD of the form of 1/f^a, a ∊ [0,4] and a high-frequency cut-off. The moment you leave this relatively restrictive class of functions you have to validate that the *DEV metric you are using is still producing what you think it does. One common function for which we have done this are quadratic functions (with noise), also known as "linear frequency drift". But we have done so for a scant few other functions. If you have read my mail a few days ago, then you might have noticed that few oscillators we have actually fit into this class. And the "worse" they are, the less they fit. An OCXO can have sudden phase and frequency jumps. Not to mention its temperature dependency which will lead to some phase function which looks noise like, even slightly self-similar (another characteristic of 1/f^a noise), but actually isn't. There is some periodic behaviour in it, at different repetition rates, together with linear, quadratic and cubic components. Go to a TCXO or even a simple XO and things get even worse. I can't go into the mathematical details as I don't have nearly enough knowledge about the nitty gritty stuff of *DEV. But we have people here who know way more than I do, who could chip in. As for the case at hand. There has been a plot of the TCXO's free running behaviour earlier. In which one could see that the TCXO had some quite distinct frequency steps, presumably from the temperature compensation. Between these the phase was pretty stable. Which means the ADEV gets detoriated by the frequency steps and doesn't see these "flat" portions inbetween, not to mention it breaks with the assumption which ADEV is built upon. Now, if the control loop hits a sweet spot where the loop compensates these frequency steps quickly but without degrading the "flat" portions inbetween, then the ADEV of the combined TCXO + PPS + control loop could indeed be lower than the individual components. But without a closer look at what happens to the phase, it is hard to tell whether this is a genuine effect of the control loop, an artifact of the simulation or simply a bug somewhere. Attila Kinali PS: Please, for the sake of all that is ticking, whenever you post an *DEV plot, add error bars. *DEV are statistical figures. And like all statistical figures they have an uncertainty. Without the error bars it is hard to judge whether the values are statistically significant or just some randomly thrown dice because of not enough data. -- In science if you know what you are doing you should not be doing it. In engineering if you do not know what you are doing you should not be doing it. -- Richard W. Hamming, The Art of Doing Science and Engineering
EK
Erik Kaashoek
Tue, May 10, 2022 10:49 AM

Error bars like this?
Erik.

On 9-5-2022 23:05, Attila Kinali wrote:

On Fri, 29 Apr 2022 16:53:58 +0200
André Balsa andrebalsa@gmail.com wrote:

Mathematically, no, a GPSDO cannot have a lower uncertainty (ADEV) than the
minimum observable uncertainty (ADEV) of the combined oscillator
(disciplined clock) and PPS (disciplining clock) from the GPS receiver.
Unless there is some magic trick to remove the uncertainty in a clock that
I am not aware of. ;)

This is not quite true.

Keep in mind that the *DEV metrics all implicitly assume that the noise
is Gauss distributed and has a PSD of the form of 1/f^a, a ∊ [0,4]
and a high-frequency cut-off. The moment you leave this relatively
restrictive class of functions you have to validate that the *DEV metric
you are using is still producing what you think it does. One common function
for which we have done this are quadratic functions (with noise), also
known as "linear frequency drift". But we have done so for a scant few
other functions.

If you have read my mail a few days ago, then you might have noticed that
few oscillators we have actually fit into this class. And the "worse" they
are, the less they fit. An OCXO can have sudden phase and frequency jumps.
Not to mention its temperature dependency which will lead to some phase
function which looks noise like, even slightly self-similar (another
characteristic of 1/f^a noise), but actually isn't. There is some periodic
behaviour in it, at different repetition rates, together with linear,
quadratic and cubic components. Go to a TCXO or even a simple XO and
things get even worse.

I can't go into the mathematical details as I don't have nearly enough
knowledge about the nitty gritty stuff of *DEV. But we have people here
who know way more than I do, who could chip in.

As for the case at hand. There has been a plot of the TCXO's free running
behaviour earlier. In which one could see that the TCXO had some quite
distinct frequency steps, presumably from the temperature compensation.
Between these the phase was pretty stable. Which means the ADEV gets
detoriated by the frequency steps and doesn't see these "flat" portions
inbetween, not to mention it breaks with the assumption which ADEV is
built upon. Now, if the control loop hits a sweet spot where the loop
compensates these frequency steps quickly but without degrading the
"flat" portions inbetween, then the ADEV of the combined TCXO + PPS + control loop
could indeed be lower than the individual components. But without a closer
look at what happens to the phase, it is hard to tell whether this is a
genuine effect of the control loop, an artifact of the simulation or simply
a bug somewhere.

		Attila Kinali

PS: Please, for the sake of all that is ticking, whenever you post an *DEV plot,
add error bars. *DEV are statistical figures. And like all statistical figures
they have an uncertainty. Without the error bars it is hard to judge whether the
values are statistically significant or just some randomly thrown dice because
of not enough data.

Error bars like this? Erik. On 9-5-2022 23:05, Attila Kinali wrote: > On Fri, 29 Apr 2022 16:53:58 +0200 > André Balsa <andrebalsa@gmail.com> wrote: > >> Mathematically, no, a GPSDO cannot have a lower uncertainty (ADEV) than the >> minimum observable uncertainty (ADEV) of the combined oscillator >> (disciplined clock) and PPS (disciplining clock) from the GPS receiver. >> Unless there is some magic trick to remove the uncertainty in a clock that >> I am not aware of. ;) > This is not quite true. > > Keep in mind that the *DEV metrics all implicitly assume that the noise > is Gauss distributed and has a PSD of the form of 1/f^a, a ∊ [0,4] > and a high-frequency cut-off. The moment you leave this relatively > restrictive class of functions you have to validate that the *DEV metric > you are using is still producing what you think it does. One common function > for which we have done this are quadratic functions (with noise), also > known as "linear frequency drift". But we have done so for a scant few > other functions. > > If you have read my mail a few days ago, then you might have noticed that > few oscillators we have actually fit into this class. And the "worse" they > are, the less they fit. An OCXO can have sudden phase and frequency jumps. > Not to mention its temperature dependency which will lead to some phase > function which looks noise like, even slightly self-similar (another > characteristic of 1/f^a noise), but actually isn't. There is some periodic > behaviour in it, at different repetition rates, together with linear, > quadratic and cubic components. Go to a TCXO or even a simple XO and > things get even worse. > > I can't go into the mathematical details as I don't have nearly enough > knowledge about the nitty gritty stuff of *DEV. But we have people here > who know way more than I do, who could chip in. > > As for the case at hand. There has been a plot of the TCXO's free running > behaviour earlier. In which one could see that the TCXO had some quite > distinct frequency steps, presumably from the temperature compensation. > Between these the phase was pretty stable. Which means the ADEV gets > detoriated by the frequency steps and doesn't see these "flat" portions > inbetween, not to mention it breaks with the assumption which ADEV is > built upon. Now, if the control loop hits a sweet spot where the loop > compensates these frequency steps quickly but without degrading the > "flat" portions inbetween, then the ADEV of the combined TCXO + PPS + control loop > could indeed be lower than the individual components. But without a closer > look at what happens to the phase, it is hard to tell whether this is a > genuine effect of the control loop, an artifact of the simulation or simply > a bug somewhere. > > Attila Kinali > > > PS: Please, for the sake of all that is ticking, whenever you post an *DEV plot, > add error bars. *DEV are statistical figures. And like all statistical figures > they have an uncertainty. Without the error bars it is hard to judge whether the > values are statistically significant or just some randomly thrown dice because > of not enough data. >
AK
Attila Kinali
Tue, May 10, 2022 11:42 AM

On Tue, 10 May 2022 12:49:27 +0200
Erik Kaashoek erik@kaashoek.com wrote:

Error bars like this?

Exactly...

And what you see is, that beyond ~300s the difference is not statistically
significant anymore and beyond 700s the curves are indistinguishable.

I'm a bit surprised that a TCXO (with control loop) is good enough for 100s.
Even if the difference to the PPS is only a factor of 1.6.
That's a quite decent oscillator.

			Attila Kinali

--
In science if you know what you are doing you should not be doing it.
In engineering if you do not know what you are doing you should not be doing it.
-- Richard W. Hamming, The Art of Doing Science and Engineering

On Tue, 10 May 2022 12:49:27 +0200 Erik Kaashoek <erik@kaashoek.com> wrote: > Error bars like this? Exactly... And what you see is, that beyond ~300s the difference is not statistically significant anymore and beyond 700s the curves are indistinguishable. I'm a bit surprised that a TCXO (with control loop) is good enough for 100s. Even if the difference to the PPS is only a factor of 1.6. That's a quite decent oscillator. Attila Kinali -- In science if you know what you are doing you should not be doing it. In engineering if you do not know what you are doing you should not be doing it. -- Richard W. Hamming, The Art of Doing Science and Engineering
BK
Bob kb8tq
Tue, May 10, 2022 1:41 PM

HI

On May 10, 2022, at 5:42 AM, Attila Kinali attila@kinali.ch wrote:

On Tue, 10 May 2022 12:49:27 +0200
Erik Kaashoek erik@kaashoek.com wrote:

Error bars like this?

Exactly...

And what you see is, that beyond ~300s the difference is not statistically
significant anymore and beyond 700s the curves are indistinguishable.

I'm a bit surprised that a TCXO (with control loop) is good enough for 100s.
Even if the difference to the PPS is only a factor of 1.6.
That's a quite decent oscillator.

or it’s in a very unusual temperature environment ….

Bob

			Attila Kinali

--
In science if you know what you are doing you should not be doing it.
In engineering if you do not know what you are doing you should not be doing it.
-- Richard W. Hamming, The Art of Doing Science and Engineering


time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.

HI > On May 10, 2022, at 5:42 AM, Attila Kinali <attila@kinali.ch> wrote: > > On Tue, 10 May 2022 12:49:27 +0200 > Erik Kaashoek <erik@kaashoek.com> wrote: > >> Error bars like this? > > Exactly... > > And what you see is, that beyond ~300s the difference is not statistically > significant anymore and beyond 700s the curves are indistinguishable. > > I'm a bit surprised that a TCXO (with control loop) is good enough for 100s. > Even if the difference to the PPS is only a factor of 1.6. > That's a quite decent oscillator. or it’s in a *very* unusual temperature environment …. Bob > > Attila Kinali > -- > In science if you know what you are doing you should not be doing it. > In engineering if you do not know what you are doing you should not be doing it. > -- Richard W. Hamming, The Art of Doing Science and Engineering > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com > To unsubscribe, go to and follow the instructions there.
EK
Erik Kaashoek
Tue, May 10, 2022 2:39 PM

Open PCB on a bench covered with a towel
In attached frequency plot you can see in green the typical random jumps
it is making and in blue the typical remaining frequency "noise" when
disciplined by the PPS
The statistics say below 1e-10 but the maximum frequency deviation is
about +/- 5e-10

Erik.

On 10-5-2022 15:41, Bob kb8tq wrote:

or it’s in avery  unusual temperature environment ….

Bob

Open PCB on a bench covered with a towel In attached frequency plot you can see in green the typical random jumps it is making and in blue the typical remaining frequency "noise" when disciplined by the PPS The statistics say below 1e-10 but the maximum frequency deviation is about +/- 5e-10 Erik. On 10-5-2022 15:41, Bob kb8tq wrote: > or it’s in a*very* unusual temperature environment …. > > Bob
EK
Erik Kaashoek
Tue, May 10, 2022 2:40 PM

Open PCB on a bench covered with a towel
In attached frequency plot you can see in green the typical random jumps
it is making and in blue the typical remaining frequency "noise" when
disciplined by the PPS
The statistics say below 1e-10 but the maximum frequency deviation is
about +/- 5e-10

Erik.

On 10-5-2022 15:41, Bob kb8tq wrote:

or it’s in avery  unusual temperature environment ….

Bob

Open PCB on a bench covered with a towel In attached frequency plot you can see in green the typical random jumps it is making and in blue the typical remaining frequency "noise" when disciplined by the PPS The statistics say below 1e-10 but the maximum frequency deviation is about +/- 5e-10 Erik. On 10-5-2022 15:41, Bob kb8tq wrote: > or it’s in a*very* unusual temperature environment …. > > Bob
MD
Magnus Danielson
Wed, May 11, 2022 11:11 PM

Hi,

On 2022-05-09 15:05, Attila Kinali wrote:

On Fri, 29 Apr 2022 16:53:58 +0200
André Balsa andrebalsa@gmail.com wrote:

Mathematically, no, a GPSDO cannot have a lower uncertainty (ADEV) than the
minimum observable uncertainty (ADEV) of the combined oscillator
(disciplined clock) and PPS (disciplining clock) from the GPS receiver.
Unless there is some magic trick to remove the uncertainty in a clock that
I am not aware of. ;)

This is not quite true.

Keep in mind that the *DEV metrics all implicitly assume that the noise
is Gauss distributed and has a PSD of the form of 1/f^a, a ∊ [0,4]
and a high-frequency cut-off. The moment you leave this relatively
restrictive class of functions you have to validate that the *DEV metric
you are using is still producing what you think it does. One common function
for which we have done this are quadratic functions (with noise), also
known as "linear frequency drift". But we have done so for a scant few
other functions.

If you have read my mail a few days ago, then you might have noticed that
few oscillators we have actually fit into this class. And the "worse" they
are, the less they fit. An OCXO can have sudden phase and frequency jumps.
Not to mention its temperature dependency which will lead to some phase
function which looks noise like, even slightly self-similar (another
characteristic of 1/f^a noise), but actually isn't. There is some periodic
behaviour in it, at different repetition rates, together with linear,
quadratic and cubic components. Go to a TCXO or even a simple XO and
things get even worse.

I can't go into the mathematical details as I don't have nearly enough
knowledge about the nitty gritty stuff of *DEV. But we have people here
who know way more than I do, who could chip in.

OK, so I'll give it a shot. This works better on whiteboard.

ADEV and friends is not the most direct approach when discussing locked
oscillators, you need to understand it in terms of phase-noise and then
you can map that to ADEV and friends.

As you build a PLL, you will low-pass filter the reference with the loop
bandwidth, and you will highpass the noise of the steered oscillator. A
PLL will have the unfortunate property of jitter peaking, so you will
have gain in excess of 1 at the PLL resonance frequency. This
jitter-peaking will occurr for both the reference noise and the
oscillator noise, and it will then add up together. You can approximate
what this will do, but the ADEV and friends will see the energy added
both from both reference and oscillator, as well as the colouring of the
jitter peaking. The disturbance of the peak at the PLL natural/resonance
frequency will for the ADEV be quite similar to adding a sine frequency
of the same frequency as the PLL natural frequency, and thus causing the
ADEV and friends to see an additional peaks on top of the underllying
noise slopes.

Trouble is, at the cut-over frequency you will get a slight peaking
however you go, and your ADEV will suffer accordingly. What you can do
is to keep the damping factor high, and thus jitter peaking low. That helps.

You never "win" this game, you only limit your losses.

As for the case at hand. There has been a plot of the TCXO's free running
behaviour earlier. In which one could see that the TCXO had some quite
distinct frequency steps, presumably from the temperature compensation.
Between these the phase was pretty stable. Which means the ADEV gets
detoriated by the frequency steps and doesn't see these "flat" portions
inbetween, not to mention it breaks with the assumption which ADEV is
built upon. Now, if the control loop hits a sweet spot where the loop
compensates these frequency steps quickly but without degrading the
"flat" portions inbetween, then the ADEV of the combined TCXO + PPS + control loop
could indeed be lower than the individual components. But without a closer
look at what happens to the phase, it is hard to tell whether this is a
genuine effect of the control loop, an artifact of the simulation or simply
a bug somewhere.

A step in phase or frequency will "kill" your ADEV plot. You learn to
set things up to avoid outliners when using TimeLab. The raised floor
from it will take a long time to average out.

		Attila Kinali

PS: Please, for the sake of all that is ticking, whenever you post an *DEV plot,
add error bars. *DEV are statistical figures. And like all statistical figures
they have an uncertainty. Without the error bars it is hard to judge whether the
values are statistically significant or just some randomly thrown dice because
of not enough data.

+1: This is in line with what IEEE Std 1139 recommendations. Actually,
there is more things to include, including bandwidth, number of samples,
any removal of linear drift etc.

Cheers,
Magnus

Hi, On 2022-05-09 15:05, Attila Kinali wrote: > On Fri, 29 Apr 2022 16:53:58 +0200 > André Balsa <andrebalsa@gmail.com> wrote: > >> Mathematically, no, a GPSDO cannot have a lower uncertainty (ADEV) than the >> minimum observable uncertainty (ADEV) of the combined oscillator >> (disciplined clock) and PPS (disciplining clock) from the GPS receiver. >> Unless there is some magic trick to remove the uncertainty in a clock that >> I am not aware of. ;) > This is not quite true. > > Keep in mind that the *DEV metrics all implicitly assume that the noise > is Gauss distributed and has a PSD of the form of 1/f^a, a ∊ [0,4] > and a high-frequency cut-off. The moment you leave this relatively > restrictive class of functions you have to validate that the *DEV metric > you are using is still producing what you think it does. One common function > for which we have done this are quadratic functions (with noise), also > known as "linear frequency drift". But we have done so for a scant few > other functions. > > If you have read my mail a few days ago, then you might have noticed that > few oscillators we have actually fit into this class. And the "worse" they > are, the less they fit. An OCXO can have sudden phase and frequency jumps. > Not to mention its temperature dependency which will lead to some phase > function which looks noise like, even slightly self-similar (another > characteristic of 1/f^a noise), but actually isn't. There is some periodic > behaviour in it, at different repetition rates, together with linear, > quadratic and cubic components. Go to a TCXO or even a simple XO and > things get even worse. > > I can't go into the mathematical details as I don't have nearly enough > knowledge about the nitty gritty stuff of *DEV. But we have people here > who know way more than I do, who could chip in. OK, so I'll give it a shot. This works better on whiteboard. ADEV and friends is not the most direct approach when discussing locked oscillators, you need to understand it in terms of phase-noise and then you can map that to ADEV and friends. As you build a PLL, you will low-pass filter the reference with the loop bandwidth, and you will highpass the noise of the steered oscillator. A PLL will have the unfortunate property of jitter peaking, so you will have gain in excess of 1 at the PLL resonance frequency. This jitter-peaking will occurr for both the reference noise and the oscillator noise, and it will then add up together. You can approximate what this will do, but the ADEV and friends will see the energy added both from both reference and oscillator, as well as the colouring of the jitter peaking. The disturbance of the peak at the PLL natural/resonance frequency will for the ADEV be quite similar to adding a sine frequency of the same frequency as the PLL natural frequency, and thus causing the ADEV and friends to see an additional peaks on top of the underllying noise slopes. Trouble is, at the cut-over frequency you will get a slight peaking however you go, and your ADEV will suffer accordingly. What you can do is to keep the damping factor high, and thus jitter peaking low. That helps. You never "win" this game, you only limit your losses. > > As for the case at hand. There has been a plot of the TCXO's free running > behaviour earlier. In which one could see that the TCXO had some quite > distinct frequency steps, presumably from the temperature compensation. > Between these the phase was pretty stable. Which means the ADEV gets > detoriated by the frequency steps and doesn't see these "flat" portions > inbetween, not to mention it breaks with the assumption which ADEV is > built upon. Now, if the control loop hits a sweet spot where the loop > compensates these frequency steps quickly but without degrading the > "flat" portions inbetween, then the ADEV of the combined TCXO + PPS + control loop > could indeed be lower than the individual components. But without a closer > look at what happens to the phase, it is hard to tell whether this is a > genuine effect of the control loop, an artifact of the simulation or simply > a bug somewhere. A step in phase or frequency will "kill" your ADEV plot. You learn to set things up to avoid outliners when using TimeLab. The raised floor from it will take a long time to average out. > > Attila Kinali > > > PS: Please, for the sake of all that is ticking, whenever you post an *DEV plot, > add error bars. *DEV are statistical figures. And like all statistical figures > they have an uncertainty. Without the error bars it is hard to judge whether the > values are statistically significant or just some randomly thrown dice because > of not enough data. +1: This is in line with what IEEE Std 1139 recommendations. Actually, there is more things to include, including bandwidth, number of samples, any removal of linear drift etc. Cheers, Magnus