[time-nuts] GPS module recommendation for Pi timing

ASSI Stromeko at nexgo.de
Sun Mar 15 13:06:26 UTC 2020 

Brian Lloyd wrote:
> I have an application where I need to synchronize the internal TOD RTC in a
> raspberry pi and need to pick a GPS module. We are building our own
> hardware but still using the Pi so interconnection will be via GPIO/serial.
> We won't try to use USB.

There is no internal RTC inside the Pi by the usual definition of that term.  
Timekeeping on the original Pi1 is performed by a free running counter on the 
VC4 side of the SoC that nominally ticks at 1MHz and is pretty slow to read 
(IIRC via the mailbox interface) from the ARM side.  The newer models instead 
use an ARM architecture counter that directly gets the 19.2MHz system clock 
and can be read directly.

The crystal on the rasPi is not too bad, but of course it predominantly needs 
to be cheap and small, so don't expect wonders.  Initial drift is pretty high, 
but that seems to stabilize after a few months.  The turnover point is around 
60°C, so it works a lot better in moderately tempered environments than it 
would be in cold ones and it also doesn't like fast temperature transients or 
intermittent operation.  Its temperature is pretty close to the CPU temp (how 
close depends on CPU load) and you could feed-forward CPU temperature to 
frequency correction for a modest improvement in performance.

> This is not an NTP application. These units will be in the field and will
> most likely not have Internet access. I need their clocks to be pretty
> close. I am shooting for 1ms ... if possible.

What happens when you miss that mark and how much of the time do you expect to 
stay inside that limit?  99.99% and no longer than 1 minute outside at a 
stretch?  Better than that?  Better in what specific way (shorter excursions 
or fewer)?  That's exactly the sort of question that quickly adds a few 
decimal places before the comma on the price tag of a frequency source…

You will have excursions larger than 1ms unless you build in some sort of 
redundancy and it's pretty hard to know beforehand how often that will happen.  
If you can network to at least 5 other systems with low latency then NTP will 
allow you to limit those excursions to ~3ms as long as not more than two 
clocks go insane at the same time and in the same direction.

Without external NTP servers (preferrably on the same network if you want to 
keep within 1ms) there is no way of knowing if your GPS has had a hiccup, so 
you'd need at least one other source of time to have a chance detecting that.  
So it would be preferrable to add a good RTC like the DS3231 (beware, most of 
these need modifications).  The bonus with the DS3231 is that you can get both 
a 32kHz and a 1PPS from it.  The latter can be used to tune the aging constant 
in the module, but you must not have the Linux kernel run in "11 minute mode" 
or have a second RTC that takes these periodic updates instead.  There are 
plenty of Pi hats that combine a simple RTC and a GPS from the usual sources.

> The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
> more reasonable. OTOH I realize there are limits to how tightly I can
> control the Pi's RTC and will run into diminishing returns, so even the M8T
> might be overkill.

The only advantage of a timing module is that they can continue to lock with 
fewer satellites in view and usually have better holdover, but the pre-
requisite is that the antenna position is known and does not change (so no 
mobile applications).  Mobile applications would be well served by RTK 
modules, however that only really works in realtime if you can network them.

For cheap and cheerful, I have had good experience with the NavSpark mini 
modules (6pc @ $36 plus the antenna makes it $15-$20 per piece…).  However, 
these do not have battery backup, so if the power goes away it takes a while 
to re-aquire the GPS signal.  As for the antenna, providing a good and large 
enough ground plane goes a long way at having good reception and stable PPS.

The all-around best solution probably would be to just chuck the crystal off 
the board and feed in a stable 19.2MHz, but that adds the cost of an OCXO / 
GPSDO that fullfills your requirements plus the board modification.

> Has anyone here figured out what the reasonable limit is for timing on a
> Pi, and what makes sense for a timing module for an application like this?

My only non-self-ovenized Pi (a 1B+) keeps within ±100µs vs. the other systems 
on the same LAN segment via NTP.  I only monitor the GPS PPS via USB on this 
system (which has high jitter ±0.5ms due to the USB frame timing) there 
because the one usable PPS GPIO is tied up with the DCF77 receiver.   The 
later Pi models are much better at processing multiple PPS and it's become 
easier to configure more than one pps-gpio device with the current kernels, so 
that should be an upper boundary as long as your PPS is stable.

PPS should always be done via GPIO on the Pi, it's hands down the most 
accurate way of disciplining the clock.  Serial on the Pi does not have the 
modem control lines that you'd use for PPS and USB serial (which you said you 
don't want to use) gets you into ±100µs jitter territory (that's with an FTDI 
USB2 highspeed interface set up for low latency, some other USB interfaces are 
much worse than that).

I'm attaching a few plots from my systems so you can get an idea of what sort 
of performance you can expect.  The data covers the previous 29 weeks.  Except 
for the rasPi1 they are all self-ovenized and they are all networked to each 
other via NTP over a switch, but except the rasPi1 they are normally 
synchronized to a GPS via  PPS-GPIO.  They all run at fixed frequency and are 
fixed to 100MBit/s ethernet speed where applicable.

The two peer stats plots for rpi2 and rpi4 show the GPS as black triangles 
overlaid on top of the network peers.  You see that rpi2 has much noisier 
reception vs rpi4 (the large excursions are mostly due to updates and the 
associated reboots, I didn't clean them from the data).  You will also see 
that the other systems will excurse from their baseline performance once in a 
while (some of that gets filtered out by NTP if short enough, so that 
impression is a bit on the optimistic side).

The ppm stats show how NTP had to steer the frequency offset in order to stay 
on time.  For rpi1 that is in (normally fairly stable) ambient, the other two 
systems are self-ovenized by loading their CPU, packed into semi-isolated 
containers (euphemism for cardboard box and some bubblewrap or more corrugated 
cardboard).  Linear frequency drift for these is below 1ppb/day since they are 
all running for over a year or more.  At the beginning of the plot for rpi3 
the system was run at elevated temperature but without the temperature control 
loop active, so you can see the daily variation clearly, as well as the 
improvement with temperature control.  All my rasPi behave pretty similarly 
and the residual frequency variation is on the order of ±10ppb over the short 
range (say a week, which is my usual monitoring interval).  The last plot is 
for a TinkerBoard which has an about 5× better crystal (also the temperature 
measurement is not as noisy as on the rasPi which helps with the control loop 
precision).  Comparing the last two plots you might notice that the large 
scale drift seems pretty well correlated even though these are otherwise quite 
different systems, which is intriguing since it holds true across all systems.  
I have no idea yet what causes that is, I plan to add a combined temperature, 
pressure and humidity sensor to the logging to see if it's environmental.  If 
it correlates to something measurable, I would probably be able to stabilise 
by another factor of 5, roughly.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NTP_peer_stats_rpi2.png
Type: image/png
Size: 215713 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20200315/18912668/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NTP_peer_stats_rpi4.png
Type: image/png
Size: 107273 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20200315/18912668/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NTP_ppm_stats_rpi1.png
Type: image/png
Size: 165589 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20200315/18912668/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NTP_ppm_stats_rpi3.png
Type: image/png
Size: 163881 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20200315/18912668/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NTP_ppm_stats_tb2.png
Type: image/png
Size: 155053 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20200315/18912668/attachment-0004.png>

More information about the Time-nuts_lists.febo.com mailing list