[ntp:questions] NTP, GPSD & PPS

juergen perlinger juergen.perlinger at t-online.de
Tue Dec 9 18:14:54 UTC 2014

On 12/09/2014 03:29 PM, Sander Smeenk wrote:
> Hi,
> I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0.
> The GPS provides a PPS signal via serial and i use gpsd to provide the
> NMEA sentences and pulse data in shared memory to NTP.
> This partly works. NTP syncs against the PPS signal but the NMEA signal
> is always marked as falseticker even though i managed to bring down the
> offset to -1.5ųsec average by fudging the time a bit. The NMEA signal
> offset fluctuates a lot. From ~ -65ųsec to ~ +75ųsec.
This is a known weakness of the GPS18x series. The puck tries to center
the serial output between the PPS pulses, and that's a pain in the back,
pardon my French. But to be fair, some SIRF based modules do it even worse.
> The GPS provides 9600bps serial comms. Would it help to speed this up to
> 19200bps? I've already disabled all NMEA sentence output for sentences that
> "aren't useful for timekeeping" but at this moment i have to use external
> clocks to sync against.
Changing the baud rate does not really help with that device. I have one
of my own, and I tried several speeds. Even reducing to a single
sentence (GPRMC, or PGRMF) does not provide stable timing. A stable
relation between PPS and serial data was obviously no design goal...

> Few questions:
> 1) Can i get a 'true PPS sync' with this setup?
> Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ?
> 2) What could i possibly do to get NTP to sync/accept the NMEA data,
> other than set it as a truechimer in the configuration?
Since you run ntp4.2.6 under Linux, I know only one solution from my own

Use the NMEA driver with its builtin PPS support instead of GPSD and the
two SHM clocks. Splitting the data into a PPS track and a NMEA track
does not work well: The two clock drivers do not know how to correlate
their data. Neither does the core of NTPD... If the full handling is
done by the NMEA driver, the serial data jitter can be ignored and you
get a good precision.

You need the PPS line discipline attached to your serial device (see
'ldattach PPS /dev/ttyS0'), and you need a symbolic link from
/dev/gpsppsX to /dev/gpsX.

(Note: with ntp4.2.7(!) and GPSD running, you could start GPSD on
/dev/gps0 and use the GPSD-NG (json) protocol driver (type 46). With a
recent version of GPSD you can let GPSD deal with the raw PPS and serial
data; NTPD uses the cooked results with nanosec resolution. Then the
driver can correlate serial and PPS data to compensate for the phase
jitter of the GPS18x.)


More information about the questions mailing list