The Raspberry Pi is an extremely versatile little computer, but even its most ardent fans would acknowledge that there are some areas in which its hardware is slightly lacking. One of these is in the field of timing, the little board has no real-time clock. Users must rely on the on-board crystal oscillator, which is good enough as a microprocessor clock but subject to the vagaries of temperature as it is, not so much as a long-term timepiece.
[Manawyrm] has tackled this problem in a rather unusual way, by dispensing entirely with the crystal oscillator on an older Pi model and instead using a clock derived from a GPS source. The source she’s used is a Leo Bodnar mini precision GPS reference clock, which includes a low-jitter synthesiser that can be set to the Pi’s 19.2 MHz required clock. Unexpectedly this also required a simple LC low-pass filter which was made on a sheet of PCB material, because the Pi at first appeared to be picking up a harmonic frequency. The Pi now has a clock that’s sufficiently stable for tasks such as WSPR transmission without constant referral to NTP or other timing sources to keep it on-track.
It’s a short write-up, but it brings with it a further link to a discussion of different time synchronisation techniques on a Pi including using a kernel module to synchronise with the more common GPS-derived 1PPS signal. We’ve not seen anyone else do this particular mod to a Pi before, but conversely we’ve seen a Pi provide an RF time reference to something else.
If you’re connected to the internet is this really a problem? https://www.google.com/search?q=ntp+in+linux&rlz=1C1SQJL_enUS775US775&oq=NTP+IN+LINUX&aqs=chrome.0.0l6.6730j0j8&sourceid=chrome&ie=UTF-8
Here are some servers NTP https://tf.nist.gov/tf-cgi/servers.cgi
Far better to use the pool.ntp.org system if your needs don’t go beyond stratum 2, which for the vast majority of people is entirely adequate.
As far as whether there’s a ‘problem’ being solved, in many cases, it’s more a matter of ‘fun’. I run a small cluster of Raspberry pi ntp servers, it’s a lot of tinkering and adjusting and tweaking, and highly enjoyable :)
https://ntpsec.anastrophe.com if you want to poke around. And be sure and follow the link near the bottom to Royce Williams’s NTP site – chock full of info…
The alternative is to read a serial NMEA message from a GPS device. The standard NTP code can be configured to read this data as long as you have a suitable serial cable
Serial NMEA without PPS is not a whole lot better than searching google for ‘what time is it’.
The setup I’m running is accurate into the nanosecond realm (all other things being equal, and they never are).
If you want to get really accurate (to 10ns ) in your local environment, you can achieve this without soldering by PTP using this gadget: https://github.com/InnoRoute/RealtimeHAT
The linked article talks about type 28 and type 22 NTP servers, but not the simpler type 20, probably because it is not as good.
But I would have setup a cheap stratum 1 NTP source using a really cheap (under $5) GPS module that provides a serial connection (e.g. Interface: RS232 TTL ; Power: 3-5v ; Baudrate default:9600bps) but totally ignoring any 1 pps signal.
A Type 20 NTP server – Generic NMEA GPS Receiver (NMEA)
( ref: https://www.eecis.udel.edu/~mills/ntp/html/refclock.html )
After the hardware is powered from the Pi and serial lines wired (vcc,rx,tx,gnd)
Provided the module is power from 3.3v then 3.3v TTL logic levels should be on the serial pins, which would be compatible with the GPIO UART on the Pi.
It just requires one soft link to from the RPi serial device to /dev/gpsu
And then one additional line in the ntp.conf file to configure the new time source (server 127.127.20.1 mode 18 prefer fudge stratum 1).
NTP does all the jitter and drift calculations, it may not be as good as the Leo Bodnar based solution, but it is a lot cheaper, and a lot less effort.
Type 20 can be a really good option for many needs and does work particularly well on a Pi.
For a less integrated or temp setup, there are many USB GPS modules out there for cheap and capable of NMEA.
I ended up with a GPS-360, I think it was packed with MS Streetmaps back in the day, and with usb serial on a pi, ended up with only 3-5 ms of jitter, which was far less than over the network.
Type 20 will get you within a second or less (assuming the GPS receiver sends the NMEA data consistently at the same offset from the second boundary) but it’s still not that great if accuracy is important. The PPS signal makes a substantial difference (e.g. +/- 2us vs +/- 100-400ms in my testing) and a PPS-capable receiver isn’t that expensive.
That said, neither method will work as an actual CPU clock like the setup described in the article. That’s pretty slick.
You should be able to do far better than a second, and of course you can add a RTC to the GPIO pins if necessary. If you want greater accuracy then you could try PTP
NTP is one of those old insecure protocols from the Internet’s early days that is rapidly becoming blocked on public networks because of abuse by hackers.
That’s not really true. That is, it’s false that it’s ‘rapidly becoming blocked on public networks’. NTP is ubiquitous, and is a _required_ part of the internet’s infrastructure. Yes, the legacy NTP code has had countless security vulnerabilities in the 35 years or so that it’s been in use, some of them exploited to near catastrophic effect; however, the code has improved over the years, and the fork NTPsec is thus far an excellent alternative. As well, work is moving forward quickly on establishing NTS as the successor to NTP. But that is a long, long, long way off in reaching the ubiquity of NTP. _Private_ networks can happily block inbound NTP if they have their own timesource on their network. The rest of the world needs free access to it…
But wait there is more: http://raspberrypi.tomasgreno.cz/ntp-client-and-server.html
If the hardware is deployed in the middle of nowhere, for better WSPR reception, it may not have a network connection.
Use GPS?
Yes, but the GPSDO has it’s own oscillator that is kept accurate by GPS. GPS alone would drift between each 1 second update.
Ahem.
Quoting the blurb:
“[Tobias Mädel] has tackled this problem […] by […] using a clock derived from a GPS source. The source he’s used is a Leo Bodnar mini precision GPS reference clock, which includes a low-jitter synthesiser […]”
So he /is/ using GPS. On top of that, he is explaining to us what it takes to use GPS as a clock source, namely some kind of PLL wizardry, implemented here as a low-jitter synthesizer.
TCXOs are pretty cheap now; a recent search showed lots of them below $5 on Digikey & Mouser. Several were listed as 500ppb. To make it more of a hack, go with a VCTCXO, and use PWM to manipulate the control voltage. Calibration every month or two from NTP or GPS should be enough to maintain 50-100ppb.
TCXOs are power hungry; for a portable application, this could be a NO GO.
In those cases, a GPS signal can be used to resynchronize a RTC from time to time, and remain idle in-between.
Advantages: no need of an internet access, and can be powered by a portable source ==> can be used out there in the wild
Certainly not the author’s use case because he is using the GPS as a replacement for the main CPU oscillator (with some required PLL scaling). So the device has to run all the time. It is *not* used to synchronize only an RTC!
A quick check on Digikey found some 19.2 MHz (I think that’s the right frequency for the Pi) TCXOs that required about 3mW.
The module that he’s using looks like a GPS-disciplined VCTCXO in a box. I think he’s already there.
Are all the GPS sources out there good for timing? e.g. Glonass,Galileo, etc.
Yes. To provide accurate navigational information they must all provide precise time.
That said, not all of them provide the *same* time standards. For example, GPS provides “GPS Time” which is the same as UTC + a leap second offset (which is sent along with the GPS time signal). GLONASS time is UTC, and includes leap seconds. Galileo time is the same as GPS time. Beidou time is UTC, like Glonass.
All of the various systems also have their own published tolerances (e.g. Beidou says it’s +/- 100ns, while GLONASS is +/- 1ms. Each of them also define their time relative to a certain standard, such as the US Naval Observatory realization of UTC for GPS, the Russian realization of UTC for GLONASS, etc. These realizations often differ in a dynamic way based on how the relevant time standards drift and are corrected by their operators.
In short, if you’re looking for timing precision within a second, all are perfectly suitable. Same for time within a millisecond. If you’re trying to get into higher precision stuff, like micro or nanosecond precision for interferometry or other advanced purposes, mixing and matching different satellite networks is probably a bad idea.
This also assumes that a particular system is stable and error-free. GPS generally does well, is actively monitored, and they have uplink stations around the world to communicate with the satellites at any time. GLONASS may be somewhat less so (see https://www.gpsworld.com/glonass-gone-then-back/ , where a bad data upload to the satellites caused GLONASS to be offline for 11 hours since all their uplinks are in the Northern Hemisphere). No guarantees, of course.
Not the first time something like this has been done. Good to see history repeating itself, and to see others learning about fun weekend projects!
See: https://www.tapr.org/~n8ur/Clock-Block_Manual.pdf
That said, this is something that I’ve considered doing on a data logging computer that runs 24-7, for years on end for an application I have (Logging GPSDO data, oddly enough!)
Fun to see others are doing the same thing!
we’ve all done the strat-1 ntp thing with pps gps rx’s.
now, lets start talking PTP (1588). have not seen a lot of DIYs for that and its about time (lol)
Hi, an alternative approach is locking on to a radio station with an atomic reference.
Then its just a matter of an accurate oscillator with a PWM based drift compensator, the radio
disciplines the oscillator so if it drops out the variation should be fairly good in the short term.
I have a 10 MHz crystal here pulled from some antique or other, which would be an ideal base
for a double oven OCXO and can also use very accurate semiconductor varicaps for the compensator
network that lack the drift found on many cheap capacitors.
The method is to put the oscillator in a small can and raise its temperature to say 62C until frequency is 10*8 Hz and put this insulated can into another can which is also held at a slightly higher temperature.
The voltage applied to the oscillator is also referenced at 5.0000V and JFET is inside the same can.
For added effectiveness use an optical transmitter such as an IR VCSEL so the circuit is completely isolated.
Hello, I would like to replace xo on some raspberry pi zero w (19.2mhz) with tcxo or gps. Can you provide à link to explain where we must soldering the tcxo or gps output, gnd and give the voltage level and wave form needed?
I see that is some xtal_N and xtal_P.
Many Thanks in advance.
For information, it’s for use as a DDS on a direct convertion TRX like pixie.
:-)