Raspberry Pi GPS Stratum 1 NTP server

Back to overview

The cheapest and simplest way to make a highly accurate time server for your network or the global NTP pool


worsthorse wrote 05/31/2018 at 16:38 point

well, yes and no.  jitter is definitely an issue but the big problem appears to be in the offset between the PPS signal and NMEA stream. to test this i configured ntp to use a stratum 2 WAN server and ran it for about twelve hours. the PPS server was stable as a pps.peer and the WAN server as a sys.peer.  the GPSD server was "falsetick" within thirty minutes. i took the average offset between the PPS and GPSD server over that twelve hours, set "time1" to that value (600ms), set GPSD to "prefer" and rebooted.  the system has been running for about four hours without a problem.  i need to let it run for a day or two to see if it is stable.

now i need to go off and figure out what a "trust yourself" pseudo peer is...

  Are you sure? yes | no

Nick Sayer wrote 05/31/2018 at 16:41 point

Yup. As you noted, you can tune the offset of the NMEA sentences with the 'fudge' line. time1 is the offset. I find that the jitter is still sometimes bad enough that ntpd distrusts it, but that will vary depending on your receiver.

The "trust yourself" peer is Use the fudge line to set its stratum to 10.

  Are you sure? yes | no

worsthorse wrote 05/31/2018 at 18:19 point

thanks for the info. i am pretty sure i wouldn't try this with a ten buck gps dongle.  i wonder if asking the gps device to only spit out the NMEA sentence with time information would improve the situation?  more research!

  Are you sure? yes | no

Nick Sayer wrote 05/31/2018 at 18:23 point

I've found that the price point of the receiver isn't necessarily predictive of the quality of the NMEA sentence timing. I think it's just something the makers don't care about. For other than timing modules, their excuse is that navigational sentences are what matters anyway. And for timing, their excuse is that you're supposed to use PPS if you care that much.

  Are you sure? yes | no

worsthorse wrote 05/31/2018 at 01:54 point

I've set one up using a combination of these instructions and a lot of man page reading (to understand why you do what you do).  NTPD goes through a cycle of accepting as a PPS peer and as the primary reference, works for ten minutes or so and then both are marked with "x" (checked using ntpq -p) which means "Out of tolerance, do not use (discarded by intersection algorithm)". 

Here's the ntpq output "before" and "after"

oPPS(0)          .PPS.            0 l    1   64    1    0.000  166.863   0.002
*SHM(0)          .GPSD.           3 l    4   16   17    0.000   73.027  23.226

xPPS(0)          .PPS.            0 l   10   64  377    0.000   -0.261   7.270
xSHM(0)          .GPSD.           3 l    9   16  377    0.000  -137.35  48.432

Any ideas why? Thanks!

  Are you sure? yes | no

Nick Sayer wrote 05/31/2018 at 02:24 point

The NMEA sentence timing isn’t stable enough for ntpd. And if you have no other reference at all, it will not trust a PPS source. For best results add an Internet host as a secondary reference for situations like this, or - worst case - add a “trust yourself” pseudo peer to disallow the stratum rising beyond, say, 10. With that, your PPS will remain trusted, which is enough to score. 

  Are you sure? yes | no