Choosing an NTP driver NMEA Driver (20) vs SHM plus PPS (28 & 22)

Hi,

Most people here seem to run Shared Memory driver and PPS Driver (28 and 22).

I am trying to use the NMEA (20) driver only. And struggling.

So, I guess I should come over and join everybody else on the GPSd and PPS combo.

Before I do, can I ask:

  • Is anybody successfully using the NMEA Generic Driver? IF so which mode?
  • For those using SHM & PPS, apart from benefts of measuring and logging GPS data without stopping ntp, what are the other benefits of using this combo?

I prefer the concept of the driver 20 as its simple to configure and involves a bunch less software.

Best,

Alex

If you don’t want to run GPSd, you can use both 20 and 22 drivers; using driver 20 to receive above-second time data and driver 22 to determine the edge of seconds. Relying on driver 20 only means that you must calculate and compensate the time1 offset yourselves.

Personally I used GPSD and type 28 :grinning:, but the ntp docs say for type 20:

If the Operating System supports PPSAPI (RFC 2783), fudge flag1 1 enables its use.

flag1 0 | 1

Disable PPS signal processing if 0 (default); enable PPS signal processing if 1.

flag2 0 | 1

If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the falling edge if 1.

flag3 0 | 1

If PPS signal processing is enabled, use the ntpd clock discipline if 0 (default); use the kernel discipline if 1.

I realize I’m 4 years late to this convo, but I hope I can at least provide some information that can help others.

According to the NTP docs in regards to the Generic NMEA 20 driver:
https://www.ntp.org/documentation/drivers/driver20/

The 20 driver is specifically looking for GPS sentences from

/dev/gpsu

It’s also looking for a PPS signal specifically from

/dev/gpsppsu

In both cases, u = a number usually starting from 0 for each GPS/PPS signal that is available.

So you need to make sure that the GPS serial output is available @ /dev/gpsu, and the PPS is @ /dev/gpsppsu. This can be done via symlinks. In my case, once I identified what the OS had named the original serial port and PPS port to, I simply symlinked them to what the ntpd 20 driver is expecting.

For the serial port on my setup:
ln -s /dev/ttyAMA0 /dev/gps0

And for the PPS port:
ln -s /dev/pps0 /dev/gpspps0

I then entered in the /etc/ntp.conf file:

server 127.127.20.0 prefer mode 24
fudge 127.127.20.0 flag1 1

The first line is set to server and prefer as this is the time being received that you want to use with your ntpd server. The 2nd line uses fudge as this indicates it’s the PPS signal to use to correct when the actual GPS time in the first line started, it’s not a time source, its a correction source.

127.127.20.u indicates to use the local system ntpd 20 driver to read and process the GPS sentence(s), and the local system PPS signal. The u is whatever you had set the /dev/gps vales to. So in my case, since I used /dev/gps0 and /dev/gpspps0, then I end up with 127.127.20.0.

The “mode 24” on the first line was set in my case because I wanted to ensure the serial port was being accessed @ 9600bps, and that $GPZDA sentences was being processed for the time as I had configured my GPS receiver to only output those sentences. 9600bps = mode 16, $GPZDA = mode 8, add those decimal values together and you get mode 24. Hopefully this example allows you to understand how the ntpd 20 driver interprets the mode switch, as it took me some time to figure that out the chart.

The “flag1 1” on the second line is needed for the serial GPS to be diciplined to an accurate time. Without it, ntpd doesn’t know when the second in the first line actually started and would tend to ignore it in favor of another source, even with the prefer switch having been added to the first line.

It’s actually turning on PPS support built into the NMEA driver, so the driver accesses /dev/ppsX via the PPSAPI, much as the ATOM driver 127.127.22.X does, but without having separate associations in the peers billboard (ntpq -p).

My trials and tribulations with the 20 and 22 driver don’t coincide with what the docs say. When I was first trying the 20 driver for both the GPS and PPS, I didn’t have the flag1 1 set and ntpd would always end up using a WAN source for time instead of the local GPS, as well as the local GPS constantly being way off from other sources. Enabling the flag1 1 initially didn’t work either, because at the time I didn’t have the /dev/pps0 symlinked to what the driver 20 is expecting/looking for. Setting up the symlink & flag1 1 finally got everything working correctly with ntpd locked to the local GPS/PPS, with the offset and jitter usually being the single digit 0.00x ms range on the local machine.

Similarly, from what I remember I couldn’t get the 22 driver to work in conjunction with GPS time properly, no matter what I tried. I always had problems with it even with SHM drivers, and the offset/jitter was way higher when it did work. I’m sure I probably had some setting wrong, or a missing flag not set, but that’s my experience with it.