[time-nuts] GPSDO time constant
bruce.griffiths at xtra.co.nz
Thu Jan 8 06:09:02 EST 2009
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:
>> 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
> 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
> 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!
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
Can one really resort to some sort of N cornered hat?
More information about the time-nuts