GPSDO time constant
Here are ADEV plots and interesting results from a recent
experiment on varying the time-constant of a GPSDO:
http://www.leapsecond.com/pages/tbolt-tc/
There was a thread recently where Warren suggested that the
loop time constant (TC) of GPSDO was less than ideal. He is
correct. There are a couple of reasons for this, if I may guess.
-
Some GPSDO, like the surplus SmartClock designs from HP,
were designed to meet spec even when S/A was still in effect.
With the much greater wander in civilian GPS timing during
those years, the TC needed to be less than what you can get
away with today. -
If you are a manufacturer and have a GPSDO spec to meet,
you need to make sure the TC is valid for all OCXO that you ship,
not just the average one. The way to do this is to be conservative
and to ship the units with a TC that is short enough that even the
parts on the lower end of the bell curve still meet your spec.
The other alternative is to individually measure (days, weeks?)
every OCXO and individually burn a default TC into each unit
shipped.
-
Most commercial GPSDO need to work over a fairly wide
temperature range. This might require a tighter TC. If the user
has a more controlled environment they can probably tolerate a
longer TC that what the manufacturer dare ship as a default. -
A GPSDO should still work reliably in the face of phase or
frequency jumps in the OCXO. Although the timing of these is
not predictable, their typical magnitude is probably something
that the designer can learn. The TC needs to be short enough
so that the GPSDO gracefully handles these jumps. If one is
too aggressive the GPSDO will wander out of spec instead of
more closely tracking GPS. -
I'm not sure it's possible to optimize for both time stability
and frequency stability at the same time. A long TC will help
avoid too sudden frequency changes in the GPSDO; a short
TC will help the 1pps stay close to UTC. I suppose a GPSDO
might be optimized more for one application than the other;
this would affect the choice of default TC. -
Most OCXO demonstrate much better drift rates after they
have been in operation for weeks or months. The drift rate has
a some impact on the choice of TC. It's probably not a good
business model to ship a GPSDO with a TC optimized for how
the unit might eventually run a year from now. It has to work
out of the box. So this cause the default TC to be set shorter
than ideal. -
There may also be a SV, sky-view, or latitude dependence.
Someone enjoying all 32 SV today, with a clear 360 degree
view of the sky at mid-latitude will probably enjoy slightly better
performance than someone a few years ago when there were
less operational SV in orbit, or with mountain, forest, building
obstructions, or at extreme latitudes. If you have much better
than average reception you could probably move the TC out
further.
So for these reasons (more like guesses), it would not surprise
me if most GPSDO have the TC set on the low side. Let me
know if you have additional info on this topic.
The good news is that if you, the time-nut, have the gear and
the time to measure the stability of the OCXO in your GPSDO,
and know your environment well, then you can probably safely
lengthen the TC and achieve much better mid-term stability out
of your GPSDO as shown in the plot above.
/tvb
Thanks Tom,
that answered questions I had been wondering about for some time.
I think that was one of the best posts that I have read.
It also reinforces my plans to build a passive temperature control
for my TB,
putting it in an insulated aluminium box with a tiny cooling fan
regulating its self-
heating temperature to about 40C.
great post!
Neville Michie
On 08/01/2009, at 7:02 PM, Tom Van Baak wrote:
Here are ADEV plots and interesting results from a recent
experiment on varying the time-constant of a GPSDO:
http://www.leapsecond.com/pages/tbolt-tc/
/tvb
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/
time-nuts
and follow the instructions there.
In message B6F04190894A41EEAAE0305A898A548E@pc52, "Tom Van Baak" writes:
Here are ADEV plots and interesting results from a recent
experiment on varying the time-constant of a GPSDO:
Tom, part of the reason for the sub-optimally short default time
constant is to be able to cope with worst-case specs of the
oscillator.
Even though they are pretty good, shifts in voltage, temperature
and orientation does affect them.
A very good example of this effect is the NTPD PLL, which
uncritically belives otherwise unplausible good news, and
lengthens the poll-period to 20 minutes and then refuses
to accept that it did it wrong, until i thas seen three
or four (= one hour) samples saying so, after which it
breaks lock and starts over.
In a lab setting, it makes sense to increase over the default
time-constant, just remember that it impacts your loops ability
to cope with for instance a 2g turnover.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Tom Van Baak skrev:
Here are ADEV plots and interesting results from a recent
experiment on varying the time-constant of a GPSDO:
http://www.leapsecond.com/pages/tbolt-tc/
There was a thread recently where Warren suggested that the
loop time constant (TC) of GPSDO was less than ideal. He is
correct. There are a couple of reasons for this, if I may guess.
I particular liked that you tweaked the damping constant. If it is not
scaled off the normal charts (it doesn't look like it) I think it is
rather low damping factor and this infact does not supprise me at least
to produce a definitive bump. Keeping it at 1.2 is still not "critically
damped" but rather under-damped.
I would love to see a few variants of measure at say tau = 100s but for
various damping coefficients. By the looks of it, the bump can be
attributed almost completely to resonance in the PLL loop, which is
certainly not what we would like to see... adding to the noise response.
-
Some GPSDO, like the surplus SmartClock designs from HP,
were designed to meet spec even when S/A was still in effect.
With the much greater wander in civilian GPS timing during
those years, the TC needed to be less than what you can get
away with today. -
If you are a manufacturer and have a GPSDO spec to meet,
you need to make sure the TC is valid for all OCXO that you ship,
not just the average one. The way to do this is to be conservative
and to ship the units with a TC that is short enough that even the
parts on the lower end of the bell curve still meet your spec.
The other alternative is to individually measure (days, weeks?)
every OCXO and individually burn a default TC into each unit
shipped.
With the end result being that noise specs would still vary between
units. Also, if one unit was good at fab and gets pounded during
shipping doesn't help either.
-
Most commercial GPSDO need to work over a fairly wide
temperature range. This might require a tighter TC. If the user
has a more controlled environment they can probably tolerate a
longer TC that what the manufacturer dare ship as a default. -
A GPSDO should still work reliably in the face of phase or
frequency jumps in the OCXO. Although the timing of these is
not predictable, their typical magnitude is probably something
that the designer can learn. The TC needs to be short enough
so that the GPSDO gracefully handles these jumps. If one is
too aggressive the GPSDO will wander out of spec instead of
more closely tracking GPS.
All these 4 points really argue against the principle of choosing one TC
to fit them all. Using suitable heuristics to adapt TC to conditions and
recent history runtime will provide a much more dynamic fashion in which
units would adapt to their performance and their environment.
- I'm not sure it's possible to optimize for both time stability
and frequency stability at the same time. A long TC will help
avoid too sudden frequency changes in the GPSDO; a short
TC will help the 1pps stay close to UTC. I suppose a GPSDO
might be optimized more for one application than the other;
this would affect the choice of default TC.
Actually no, not really.
If we remove the issues of hanging bridge, which the ThunderBolt
effectively has since it steers it's timing clock, then another reason
for shifting PPS is due to changing symmetry and when removing or adding
a satellite from the chosen constellation (by tracking set or TRAIM
selective set) the apparent receiver time will jump. In the meanwhile it
may glide as the symmetry changes. Multipath can also aid in shifting
position. So a shorter time constant does not render a closer rendition
of UTC but rather a quicker follow of apparent time position of the
receiver, which isn't quite the same thing. Thus, a longer time
constants acts like an averaging of apparent time position.
Another factor which plauges most single frequency receivers is that
they can't correct for actual ionospheric delay. They run according to a
parameterized model. There is a deviation between the actual and
apparent delay and it is changing over time.
Thus, using Rubidium or Caesium to steer local clock will allow for even
greater time constants and thus greater averaging potential, as 1000 s
is still kind of "short".
The conclusion is that the GPS receivers we use have many inherrent
non-static error sources
-
Most OCXO demonstrate much better drift rates after they
have been in operation for weeks or months. The drift rate has
a some impact on the choice of TC. It's probably not a good
business model to ship a GPSDO with a TC optimized for how
the unit might eventually run a year from now. It has to work
out of the box. So this cause the default TC to be set shorter
than ideal. -
There may also be a SV, sky-view, or latitude dependence.
Someone enjoying all 32 SV today, with a clear 360 degree
view of the sky at mid-latitude will probably enjoy slightly better
performance than someone a few years ago when there were
less operational SV in orbit, or with mountain, forest, building
obstructions, or at extreme latitudes. If you have much better
than average reception you could probably move the TC out
further.
These two points again suggests a more dynamic approach to setting time
constant.
There is some old papers discussing straight PLL loops vs. Kalman filter
and Kalman filter (if done properly) will adapt dynamically and they
showed (to some degree) that the Kalman filter approach outperformed the
straight PLL approach.
So for these reasons (more like guesses), it would not surprise
me if most GPSDO have the TC set on the low side. Let me
know if you have additional info on this topic.
In general I think you are right. There are many reasons why they go on
the low side.
The good news is that if you, the time-nut, have the gear and
the time to measure the stability of the OCXO in your GPSDO,
and know your environment well, then you can probably safely
lengthen the TC and achieve much better mid-term stability out
of your GPSDO as shown in the plot above.
Agreed. But also recall that long-term effects like frequency drift is
pretty easy to measure with a GPS. It would not take too much research
to figure out some suitable drift-TC relationship such that you could
either just look the charts to find a good match or even apply them in
real time steering.
For ThunderBolt owners it is pretty straightforward to adjust the TC and
damping, which is very nice. Use this oppertunity!
Cheers,
Magnus
Poul-Henning Kamp skrev:
In message B6F04190894A41EEAAE0305A898A548E@pc52, "Tom Van Baak" writes:
Here are ADEV plots and interesting results from a recent
experiment on varying the time-constant of a GPSDO:
Tom, part of the reason for the sub-optimally short default time
constant is to be able to cope with worst-case specs of the
oscillator.
Even though they are pretty good, shifts in voltage, temperature
and orientation does affect them.
A very good example of this effect is the NTPD PLL, which
uncritically belives otherwise unplausible good news, and
lengthens the poll-period to 20 minutes and then refuses
to accept that it did it wrong, until i thas seen three
or four (= one hour) samples saying so, after which it
breaks lock and starts over.
Isn't this more due to surrounding (obviously flawed) heuristics rather
than the PLL?
Interesting never the less.
In a lab setting, it makes sense to increase over the default
time-constant, just remember that it impacts your loops ability
to cope with for instance a 2g turnover.
Most labs would have issues with a 2g turnover. :)
Flipping oscillators that runs is evil and should be avoided at all
times. Should be in the rulebook for time-nuts.
Cheers,
Magnus
Hej Magnus
Magnus Danielson wrote:
Tom Van Baak skrev:
Here are ADEV plots and interesting results from a recent
experiment on varying the time-constant of a GPSDO:
http://www.leapsecond.com/pages/tbolt-tc/
There was a thread recently where Warren suggested that the
loop time constant (TC) of GPSDO was less than ideal. He is
correct. There are a couple of reasons for this, if I may guess.
I particular liked that you tweaked the damping constant. If it is not
scaled off the normal charts (it doesn't look like it) I think it is
rather low damping factor and this infact does not supprise me at least
to produce a definitive bump. Keeping it at 1.2 is still not "critically
damped" but rather under-damped.
I would love to see a few variants of measure at say tau = 100s but for
various damping coefficients. By the looks of it, the bump can be
attributed almost completely to resonance in the PLL loop, which is
certainly not what we would like to see... adding to the noise response.
-
Some GPSDO, like the surplus SmartClock designs from HP,
were designed to meet spec even when S/A was still in effect.
With the much greater wander in civilian GPS timing during
those years, the TC needed to be less than what you can get
away with today. -
If you are a manufacturer and have a GPSDO spec to meet,
you need to make sure the TC is valid for all OCXO that you ship,
not just the average one. The way to do this is to be conservative
and to ship the units with a TC that is short enough that even the
parts on the lower end of the bell curve still meet your spec.
The other alternative is to individually measure (days, weeks?)
every OCXO and individually burn a default TC into each unit
shipped.
With the end result being that noise specs would still vary between
units. Also, if one unit was good at fab and gets pounded during
shipping doesn't help either.
-
Most commercial GPSDO need to work over a fairly wide
temperature range. This might require a tighter TC. If the user
has a more controlled environment they can probably tolerate a
longer TC that what the manufacturer dare ship as a default. -
A GPSDO should still work reliably in the face of phase or
frequency jumps in the OCXO. Although the timing of these is
not predictable, their typical magnitude is probably something
that the designer can learn. The TC needs to be short enough
so that the GPSDO gracefully handles these jumps. If one is
too aggressive the GPSDO will wander out of spec instead of
more closely tracking GPS.
All these 4 points really argue against the principle of choosing one TC
to fit them all. Using suitable heuristics to adapt TC to conditions and
recent history runtime will provide a much more dynamic fashion in which
units would adapt to their performance and their environment.
- I'm not sure it's possible to optimize for both time stability
and frequency stability at the same time. A long TC will help
avoid too sudden frequency changes in the GPSDO; a short
TC will help the 1pps stay close to UTC. I suppose a GPSDO
might be optimized more for one application than the other;
this would affect the choice of default TC.
Actually no, not really.
If we remove the issues of hanging bridge, which the ThunderBolt
effectively has since it steers it's timing clock, then another reason
for shifting PPS is due to changing symmetry and when removing or adding
a satellite from the chosen constellation (by tracking set or TRAIM
selective set) the apparent receiver time will jump. In the meanwhile it
may glide as the symmetry changes. Multipath can also aid in shifting
position. So a shorter time constant does not render a closer rendition
of UTC but rather a quicker follow of apparent time position of the
receiver, which isn't quite the same thing. Thus, a longer time
constants acts like an averaging of apparent time position.
Another factor which plauges most single frequency receivers is that
they can't correct for actual ionospheric delay. They run according to a
parameterized model. There is a deviation between the actual and
apparent delay and it is changing over time.
Thus, using Rubidium or Caesium to steer local clock will allow for even
greater time constants and thus greater averaging potential, as 1000 s
is still kind of "short".
The conclusion is that the GPS receivers we use have many inherrent
non-static error sources
-
Most OCXO demonstrate much better drift rates after they
have been in operation for weeks or months. The drift rate has
a some impact on the choice of TC. It's probably not a good
business model to ship a GPSDO with a TC optimized for how
the unit might eventually run a year from now. It has to work
out of the box. So this cause the default TC to be set shorter
than ideal. -
There may also be a SV, sky-view, or latitude dependence.
Someone enjoying all 32 SV today, with a clear 360 degree
view of the sky at mid-latitude will probably enjoy slightly better
performance than someone a few years ago when there were
less operational SV in orbit, or with mountain, forest, building
obstructions, or at extreme latitudes. If you have much better
than average reception you could probably move the TC out
further.
These two points again suggests a more dynamic approach to setting time
constant.
There is some old papers discussing straight PLL loops vs. Kalman filter
and Kalman filter (if done properly) will adapt dynamically and they
showed (to some degree) that the Kalman filter approach outperformed the
straight PLL approach.
So for these reasons (more like guesses), it would not surprise
me if most GPSDO have the TC set on the low side. Let me
know if you have additional info on this topic.
In general I think you are right. There are many reasons why they go on
the low side.
The good news is that if you, the time-nut, have the gear and
the time to measure the stability of the OCXO in your GPSDO,
and know your environment well, then you can probably safely
lengthen the TC and achieve much better mid-term stability out
of your GPSDO as shown in the plot above.
Agreed. But also recall that long-term effects like frequency drift is
pretty easy to measure with a GPS. It would not take too much research
to figure out some suitable drift-TC relationship such that you could
either just look the charts to find a good match or even apply them in
real time steering.
For ThunderBolt owners it is pretty straightforward to adjust the TC and
damping, which is very nice. Use this oppertunity!
How exactly can one measure the resultant performance or even select the
optimum time constant and damping factor if one doesn't have a quieter
reference?
Can one really resort to some sort of N cornered hat?
Cheers,
Magnus
Bruce
Hej Bruce,
The good news is that if you, the time-nut, have the gear and
the time to measure the stability of the OCXO in your GPSDO,
and know your environment well, then you can probably safely
lengthen the TC and achieve much better mid-term stability out
of your GPSDO as shown in the plot above.
Agreed. But also recall that long-term effects like frequency drift is
pretty easy to measure with a GPS. It would not take too much research
to figure out some suitable drift-TC relationship such that you could
either just look the charts to find a good match or even apply them in
real time steering.
For ThunderBolt owners it is pretty straightforward to adjust the TC and
damping, which is very nice. Use this oppertunity!
How exactly can one measure the resultant performance or even select the
optimum time constant and damping factor if one doesn't have a quieter
reference?
Can one really resort to some sort of N cornered hat?
If time constants is allowed to be limited by frequency drift
(regardless of its source) then you can use a long term drift estimate
to control the time constant of the control loop. Essentially being an
adaptive filter.
It is still a gross oversimplification, but may still be a handy one.
Cheers,
Magnus
In message 4965DECE.3060004@xtra.co.nz, Bruce Griffiths writes:
Hej Magnus
Magnus Danielson wrote:
How exactly can one measure the resultant performance or even select the
optimum time constant and damping factor if one doesn't have a quieter
reference?
Can one really resort to some sort of N cornered hat?
I experimented with that, and you can actually get pretty far with
simpler standalone means such as periodograms of zero crossings.
My theory behind this is that the noise (of all kinds) is basically
gaussian or other symmetric distributions.
Consequently, the offset between your oscillator and the reference
should also have a symmetric distribution of sign, subject to well
known random "paradoxes" like the fact that repeatedly rolling 6
with dice doesn't prove you cheat, you might just be very very
lucky.
I have not fully developed this lead, and would welcome others
to experiement and improve on it, it takes more patience and
stability than my lap can muster when it must also work for my
salary.
The way I autotune the timeconstant of the PLL in NTPns is based
on this lack of zero-crossings of the offset from the reference input:
The first sign that a PLL has been torqued to hard is that the
reference input is not able to steer the oscillator adequately and
you can detect this very early, by monitoring how long runs you have
where the offset from the reference stays the same sign: the runs
on one side will get longer and more frequent than on the other
side.
You can also tell that the timeconstant is too short, because
the runs are not long enough, indicating that the PLL follows
the reference signal more aggresively than it need.
Look in the main/pllmath.c file of NTPns to see my current
implementation. (http://phk.freebsd.dk/phkrel/).
One of my NTP servers use the same GPS PPS to steer the PRS10 Rb
and for the NTP data feed, so the NTPns should obviously end up
with a zero frequency error, since the PRS10 takes care of that.
Consequently the PLL keeps stretching the timeconstant of the
software PLL, until it had identified a 2e-18 rounding error
in the frequency estimation code in the kernel.
The third order code on the other hand, does not seem to do me
much good yet, but maybe I simply don't have good enough kit for
that to be dominant.
The experiements I would propose requires that you can get hold
of the reference/oscillator difference signal somehow, and
then what you want to do is simply record runs of these values
for various timeconstants and damping factors.
The run them through a statistical package, or possibly even
the DIEHARD tests, and see how different timeconstants score,
the ones where the offset looks most random are optimal.
Have fun :-)
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
In message 4965DC62.9070205@rubidium.dyndns.org, Magnus Danielson writes:
In a lab setting, it makes sense to increase over the default
time-constant, just remember that it impacts your loops ability
to cope with for instance a 2g turnover.
Most labs would have issues with a 2g turnover. :)
Flipping oscillators that runs is evil and should be avoided at all
times. Should be in the rulebook for time-nuts.
Correct, but it is perfectly normal behaviour for telecom techs
who remodel installations while running, so the products must
cope with it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Poul-Henning Kamp skrev:
In message 4965DC62.9070205@rubidium.dyndns.org, Magnus Danielson writes:
In a lab setting, it makes sense to increase over the default
time-constant, just remember that it impacts your loops ability
to cope with for instance a 2g turnover.
Most labs would have issues with a 2g turnover. :)
Flipping oscillators that runs is evil and should be avoided at all
times. Should be in the rulebook for time-nuts.
Correct, but it is perfectly normal behaviour for telecom techs
who remodel installations while running, so the products must
cope with it.
True. Very true. The only thing which to some degree prohibits that is
to make them monolithic. You are not entierly safe even with monolithic
racks. Ericsson created a rack system in which the bottom of the rack
was actually forming a closed container with the floor. Hook up
compressed air to the nossle and the rack was floating, and hand-pushing
the rack into position was no trouble, pull the plugg and it would sit
tight on the floor again. That way they could shift in their racks while
running, making cut-over time go down to zero.
Cheers,
Magnus