Accurate Time On Your Pi, The Extreme Way

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.

27 thoughts on “Accurate Time On Your Pi, The Extreme Way

    1. Far better to use the 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 :) 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…

        1. 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).

  1. 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: )

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

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

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

      1. 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…

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

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

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

    1. 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 , 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.

  4. 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!


    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!

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

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

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.