[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