[time-nuts] GPSDO time constant

Magnus Danielson magnus at rubidium.dyndns.org
Thu Jan 8 05:51:50 EST 2009

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.

> 1) 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.
> 2) 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.

> 3) 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.
> 4) 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.

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

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

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!


More information about the time-nuts mailing list