Here's what worked for me:
Start with a pi3 and raspbian stretch. Add a GPS with TTL-level PPS and 9600 baud NMEA outputs.
Hook up you GPS: GND and +3.3V or +5V (according to the specifiics of your GPS) to any matching pin, the GPS's TX output to the Pi's RX input on pin 10 of the header, and the GPS's PPS output to the Pi's pin 12. (You can hook up your GPS's RX input to the Pi's TX output on pin 8 if you like, but I don't think this is necessary)
Using raspi-config, disable the serial console and enable the serial port hardware.
Manually edit /boot/config.txt to add: dtoverlay=pps-gpio — If you have to (or prefer to) use a different pin for pps, you can apparently specify it as dtoverlay=pps-gpio,gpiopin=##, where ## is the internal numbering of the GPIO pins, not the number on the 40-pin header.
Manually edit /etc/modules and add a line that reads pps-gpio — According to some sources, this step is not necessary.
Install ntpd with apt-get.
Delete all the content in /etc/dhcp/dhclient-exit-hooks.d/ntp, leaving an empty file.
Remove the file /run/ntp.conf.dhcp if it exists.
Edit /etc/udev/rules.d/99-com.rules. On each of the two lines that ends , SYMLINK+="serial%c", append , SYMLINK+="gps%c"
Create /etc/udev/rules.d/99-ppsd.rules with the content SUBSYSTEM=="pps", GROUP="dialout", MODE="0660", SYMLINK+="gpspps%n"
In /etc/ntp.conf, add a stanza to access the GPS:
# gps clock via serial /dev/gps0 and /dev/gpspps0 server 127.127.20.0 minpoll 3 maxpoll 3 mode 16 burst iburst prefer fudge 127.127.20.0 refid GPS time2 +.250 flag1 1(leave the "pool" line(s) or other ntp server lines; if your pi doesn't have a battery-backed RTC, you need a way to get the correct time initially, before a GPS fix may be available!)
"time2" doesn't seem critical with this setup, because the PPS time is preferred over the serial reception time. "minpoll", "maxpoll", "burst" and "iburst" may be superstitious and unnecessary.
Reboot now and have a look at `ntpq -c peers`. You should see something like this:
remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 1 8 377 0.000 -0.001 0.003 +ntp.u .GPS. 1 u 2 8 377 1.104 0.013 0.064
"GPS_NMEA" is selected as peer and is using PPS (this is what "o" in the first column means). delay, offset, and jitter should all be extremely small (Here, .001 is 1 microsecond). "ntp.u" is my other local stratum-1 NTP server. The "+" indicates it's in good agreement with the local GPS. If you use pool, you will see multiple lines here; some may have "+" and some may have "-".
If something's not working, you will get, " " (blank), "-" or "x" next to GPS_NMEA. If it's got "*" then NMEA is working but PPS isn't. Now you get to do things like debug whether the PPS signal is working properly according to ppstest, whether NMEA messages are actually coming in at 9600 baud, etc. Or you can follow one of those other guides. :wink:
Here's how the local time to GPS offset has looked over the last 10 hours or so — I find it awesome that my computer appears to be synchronized to GPS to within ±5 microseconds almost all of the time:
Entry first conceived on 6 June 2019, 12:19 UTC, last modified on 6 July 2019, 21:49 UTC