RPI + Adafruit GPS sanity check

[Gary E. Miller]

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.

Good.

> I have some questions though:

OK.
 
> 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
second.

> 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?

Yes.

> 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 --

Yup.

> 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.
> 
> 
> 
> 
> # GPS HARDWARE INITIALIZATION
> 
> 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 CALIBRATION
> 
> 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 10.8.0.10     iburst minpoll 4 maxpoll 4
> server 10.8.1.7      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
chimers.

RGDS
GARY
---------------------------------------------------------------------------
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>