[ntp:questions] serialPPS+gpsd+ntpd large offset & jitter

Rob nomail at example.com
Sat Oct 16 08:42:32 UTC 2010

M Z <mcrunch2 at yahoo.com> wrote:
> Hi. I have both usglobalsat MR350P and garmin 18xLVC connected to serial at both 
> 4800 and 9600.
> gpsd was 2.37 but is now 2.95. ntpd is 4.2.4p7, OS: SuSE 11.2 = 2.6.31. I have 
> used both
> serial ports. I set to low_latency as per instructions:
> http://www.lammertbies.nl/comm/info/GPS-time.html
> gpsd 2.37 did not communicate with ntp for the pps (ntpq -p 'when' column always 
> -). 2.95 seems to work ok. output looks good, xgps works (7 sats used), etc. 
> However, jitter seems large and offset, no matter how small to start (usually +- 
> 20.) always creeps up to about -300 to -500.

There is a problem within gpsd that can bite you with some receivers.
I originally wrote the code but I have not been paying attention lately
and it may be that some things have changed.

However the point is this: the PPS sent from gpsd to ntpd is sent via
the second SHM interface.  But via this interface to ntpd one cannot
really send PPS information, only absolute time can be sent.  But of
course PPS does not convey absolute time.

So the workaround I made in gpsd is to derive the absolute time from
the NMEA or whatever binary messages sent by the receiver (and conveyed
to ntpd via the first SHM interface).  To do this, the moment the PPS
line ticks has to be within a certain time from the moment the serial
message arrives, I think this was coded at about 400ms, or the PPS
pulse cannot be related to an absolute timestamp and it is rejected.

The problem is that some receivers send a serial message timestamp that
is way off the actual time, and the lock can never be achieved.
It is possible to increase the locking range (and I think the current
maintainers have done that already) but the risk is that the PPS
pulse is associated with the wrong serial message and the PPS clock
is off by one second.

More information about the questions mailing list