[LinuxPPS] Why is my ATOM clock a falseticker?

[Cirilo Bernardo]

On 2/9/09, James Boddington <boddingt at internode.on.net> wrote:
> Paul Simons wrote:
[snip]
>
> I use the atom driver, isp's ntp server as the prefer peer and a few pool
>  servers for sanity checking. Did not have to modify the atom driver.
>
>  It looks like you only have 2 clocks defined. That is not a good number.
>
>  Ntp syncs to the TRUETIME and once that happens starts listening to PPS. The
>  reach for PPS won't increase until ntp is synced to the TRUETIME. When both are
>  going you have approx 493ms difference between the 2 sources. Which is ntp to
>  believe? It won't know and you end up with both being declared false tickers.
>  If you had a 3rd server defined then ntp would start getting an idea of which
>  was correct.
>
>  Can you add other servers for sanity checking?
>
>  Try fudge time1 for the TRUETIME to reduce the gap. If the 2 times are close
>  enough you might get lucky. If you are using nmea with it the time could still
>  jump enough you are back you to this point. From reading
>  comp.protocols.time.ntp I get the impression one of the tinker variables can be
>  used to increase the max difference between the prefer peer and the pps before
>  something is declared insane.
>
[snip]

Is the PPS synced to a reference atomic clock time standard (TIA, UTC,
GPS)?  If it is only a precise interval (as opposed to precise start
of a second) then things get tricky.

I was just looking through the TRUETIME clock code again.  With
special hardware (PCL720) some useful tricks are employed.  However,
you essentially have an independent PPS and time string.  If your PPS
is synced to a time standard, then your best option is to create a
hacked version of the TRUETIME code to make proper use of the PPS; in
such a case you will not need to specify a separate 'refclock' for the
PPS, just do as the NMEA refclock code and attempt to open a PPS
device.

- Cirilo