RPI + Adafruit GPS sanity check

Gary E. Miller gem at rellim.com
Thu May 16 18:42:25 UTC 2019

Yo Patrick!

On Thu, 16 May 2019 14:50:23 +0800
Patrick <201905-ntpsec at jslf.app> wrote:

> I used the following docs to setup an RPI 2B + Adafruit GPS HAT.
> Primarily following:
> 	https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/
> while using the following for sanity checks:
> 	https://www.morcant.com/blog/stratum-1-ntp-server/
> 	http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
> And it all appears to be working.


> I have some questions though:

> Is the caveat against NMEA refclock still valid?
> https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/#_why_gpsd

Depends on who you ask.  Obviously gpsd thinks they are better than 
NTP refclock 20.

> I tried both gpsd and refclock NMEA configs, and they both threw
> falsetickers, which I chalked up to my HAT's limited skyview.

No matter how good your skyview, the NMEA based time will be aweful.

> Since the PPS is /dev/pps0, gpsd can be dropped.

Not really.  PPS just tells you the top of the second, but not which

> Is there anything that should be done to prevent mishaps like the USNO
> has had over time?

Care to be more specific?

> It seems like there just needs to be a nagios check
> that runs against local time servers to make sure they have a large
> enough odd number of peers?

I moved from nagios to icinga, but not much you can do if all your
peers go crazy at once.  Like with smeared time...

> Does refclock NMEA time2 or refclock shm time1 calibration matter?


> Depending on skyview, the NMEA refclock may bounce around too much

It will do so even with a good skyview.

> and be declared a falseticker at times due to too large an offset --


> so with a limited skyview, it's better to think of the NMEA clock as
> a backup time source.

Yes.  Some add an offset so it will only get selected as a last resort.

> It seems that the more important source is the PPS which will
> discipline when the consensus second starts. PPS should always be
> flagged with a leading 'o' and its jitter should be less than 5
> microseconds.

Depends.  It is possible to get it under 1 micro second.  YMMV.

> P.S. Below are notes that others might find useful regarding HAT
> configuration and timeN calibration, along with the configs that
> were used.
> Configure the GPS to output NMEA MRC (has date + time) once per second
> https://www.gpsinformation.org/dale/nmea.htm
> https://cdn-shop.adafruit.com/datasheets/PMTK_A08.pdf
> N.B. GPS commands are check-summed as per the last page of the PMTK
> datasheet.
> python3
> def checksum(cmd):
>   ck, *cmd = [ ord(x) for x in cmd ]
>   for c in cmd:
>     ck ^= c
>   return hex(ck)[2:].upper()
> assert checksum("PMTK605") == '31'
> assert checksum("PMTK226,3,30") == '4'
> assert checksum("PMTK251,115200") == '1F'

Or just use gpsctl.

> GPS offsets can vary depending on skyview

Uh, no.

> ####### /etc/ntp.conf #######
> refclock pps         refid PPS ppspath /dev/pps0 minpoll 4 maxpoll 4

Play with other poll times.  

> prefer refclock nmea        refid GPS path /dev/ttyAMA0 baud 9600

absolutely NOT.

> # local servers
> server     iburst minpoll 4 maxpoll 4
> server      iburst minpoll 4 maxpoll 4

Maybe too short a poll interval on the net.

> server sg.pool.ntp.org iburst
> server jp.pool.ntp.org iburst
> server kr.pool.ntp.org iburst

Those pools are too far from each other.  Try to pick good and nearby

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/users/attachments/20190516/3b1f833f/attachment.bin>

More information about the users mailing list