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
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
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.
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
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.
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
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.
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 avery unusual temperature environment ….
Bob
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