[ntp:questions] LOCL clock reachability not 377?

A C agcarver+ntp at acarver.net
Thu Jul 31 19:17:06 UTC 2014

On 2014-07-31 07:31, Martin Burnicki wrote:
> Miroslav Lichvar wrote:

> This sounds good. I think we'd have to distinguish some basic cases a
> few of which immediately come to my mind:
> 1) A refclock provides absolute time, status, and a PPS signal
> 1a) The refclock contains a good oscillator, so the PPS signal could be
> accepted for some time after the refclock started freewheeling.
> 1b) The refclock only has a simply xtal which starts drifting
> immediately when the refclock starts freewheeling.
> 2) A good PPS signal is available, but no absolute time (e.g. in case of
> a Rubidium)
> 2a) Some status information is available telling if the PPS signal is
> "good" or not
> 2b) No information on the PPS quality is available
> Case 1a) or 1b) is usually true for most GPS receivers.
> 1a) is for example the case for Meinberg GPS receivers, which have a
> good oscillator (TCXO or even OCXO) on board, but in contrast to the
> GPSDO mentioned by Rob, which doesn't provide absolute time, the
> Meinberg devices do.
> NTP's parse driver supports the concept of a "trust time" which means
> that *if* the time source has been synchronized and then starts
> freewheeling you can configure a time interval during which the parse
> driver doesn't tell ntpd that the refclock has started freewheeling, and
> thus the refclock plus associated PPS signal are still accepted for that
> interval. So only after the trust time has been expired the PPS signal
> is discarded.
> 1b) is the case for most cheap GPS receivers. If they loose the
> satellite signal they often start drifting quite a lot, in which case it
> could make sense to discard the PPS signal immediately.
> In terms of the trust time mentioned in 1a) this would mean the trust
> time is very short, or even 0.

Some of the cheap GPS receivers derive the PPS from the RF carrier sent
by the constellation.  The PPS output is available if the oscillator is
still receiving a synchronizing signal from the receiver even if the GPS
CPU itself has unlocked.  Unlocking is far more frequent than a total
loss of signal.

As an example, I have a GlobalSat receiver which uses the satellite
signal to control the oscillator separate from the time output.
Occasionally the lock is lost so the time output drifts or stops but the
receiver still sees RF energy from the satellites at the receiver input
which keeps the PPS under reasonable control (slight jitter of a up to a
few milliseconds but not bad).  If I could keep my system ticking with
the PPS input even though other clocks were dead I'd be ok.

More information about the questions mailing list