[time] Garmin GPS 18 5Hz usability

Rob Janssen rob
Sun Nov 19 10:01:05 UTC 2006

Arthur Konovalov wrote:
> I hope that problem solved now.
> Part of ntp's refclock_nmea.c file:
> #ifdef HAVE_PPSAPI
>     /*
>      * If the PPSAPI is working, rather use its timestamps.
>      * assume that the PPS occurs on the second so blow any msec
>      */
>     if (nmea_pps(up, &rd_tmp) == 1) {
>         pp->lastrec = up->tstamp = rd_tmp;
>         pp->nsec = 0;
>     }
> #endif /* HAVE_PPSAPI */
> In case of 5Hz PPS we need millisecons part, commented out row:
>        pp->nsec = 0;
When I understand correctly what this code does, making this patch will
completely kill the synchronization by PPS.   Probably it will look as 
if you have
good sync but in reality there is none.

The point of code like the above (and also in gpsd) is: the moment the PPS
pulse comes in, the code assumes we are on the seconds-mark.  So it creates
a timestamp of the nearest second: the current time with the usec or nsec
field zeroed, and lets the clock sync to that.

When you have 5Hz ticks, the situation is a little more complicated: you
have to determine the nearest 200ms-mark and sync to that.  So the nsec
value has to be set to any of 5 values.
However, I would feel uneasy with doing only that, because you have
only about 100ms of room to play with.  Getting it wrong may sync you
to the wrong 200ms mark (and your clock is 200ms off).  So you need to
use the information from the timestamps in the messages, or at least use
a couple of external reference clocks to make sure you are always within 


More information about the pool mailing list