What’s More Accurate Than A GPS Clock? The OpenPPS GPS Clock

Making a GPS clock is a relatively straightforward process on the face of it. Buy a GPS module for a few dollars, hook it up to a microcontroller board of your choice, pick the appropriate library and write a bit of code, et voila! A clock with time-wonk bragging rights!

Of course, your GPS clock will always tell the right time, but it won’t be really right. Your microcontroller will introduce all sorts of timing errors and jitter, so at best it’ll only be nearly right. [Rick MacDonald] has been striving to quantify and minimise these errors in his OpenPPS project, which aims to be as accurate a GPS time and frequency reference as possible.

In a very comprehensive multi-page write-up, he details his progression, through the GPS modules he used, his experience with timing jitter when he used an ESP32 alone to process their output, and then his experiments with an FPGA and then temperature-compensated oscillators. It moves from being a mere description of a GPS clock into a fascinating run-down of both GPS timing itself and the development pitfalls he encountered along the way. At the end of it all he has a GPS clock in a smart 3D-printed enclosure which he admits as yet doesn’t do anything more than tell the time, but as he points out it’s a clock with minimised jitter, delay, and drift, and it remains an ongoing project that will evolve into a full-blown time and frequency standard.

If your taste in GPS clocks is far more simple, there are plenty of projects showing how a more basic one can be produced.

19 thoughts on “What’s More Accurate Than A GPS Clock? The OpenPPS GPS Clock

      1. “OpenPPC?”

        PPC does seem eye catching, no? Plus, great re-enforcement of PPS which I remember when first seeing PPS was like… PPM??? What is PPS… oh crap… duh PPS (Pulse Per Second).

        “they had pay per click on the brain”

        That reminds me of these questions I had now having some answer potential:

        I didn’t even know there was a Precision Time Protocol (PTP), I’ll have to read into that and how that is based from a hardware and software or really… logic… perspective. I guess I last left off with Network Time Protocol (NTP) and hadn’t made the connection with Frequency and Time Standards.

    1. From a quick read this means you still need a master clock with GPS/atomic and also network equipment that supports at least PTP or rather the White Rabbit variant.

  1. Strange. Somebody try to invent wheel. HAMs are using GPSDO OCXO for years. Use MCU (tiny13,25 etc) to reprogram uBlox GPS PPS output to 2.5 MHz. Add 74HC393 counters (1 IC package) and one XOR (74HC86). VCO filter and GO! No ESPs and FPGAs involved. One evening project. Or use another alternative.

    1. I found the recent BG7TBL was several times more accurate than expected, but only the 10MHz compensated output. The digital PPS signal from those blox modules are nowhere near as stable.
      It takes time to warm up (about 15 minutes @lock to 12 hours @stable for my unit), and one should use a mechanically stable platform. Apparently, even changes in case orientation are detectable as shits in the reference compensation.

      GPSDO were the least expensive solution I found to get a limeSDR to act as a rather precise instrument. I am very happy with mine.

      eevblog thread on them:

      The firmware has long since been fixed, but the buggy version is compared here:

      Note, there are about a dozen versions around, and not all are created equal… ;-)

      1. Feed frequency into MCU counter (timer) and you will have time standard. Then MCU send response on every NTP request or do whatever it need to do with time. Why MCU? Because you have more control on code than in, for example, RPi_linux. RPi+linux also is doable. There are lot of interesting reading about clock stuff on ntp.org website.

  2. I think you’d get better/easier results by starting with a decent VCTCXO,and building a local clock, complete with full epoch output. Track it against GPS time, not by using the PPS (jitter problems), but rather by just reading the GPS epoch from time to time — doesn’t have to be at regular intervals even — and tweaking your local rate so they stay synchronized. The longer you let it run, the better it gets.

  3. I feel like the summary implies that a microcontroller cannot do this because of jitter, but it feels to me like that is specific to the microcontroller. I have only modest experience at this point, but I definitely wouldn’t consider ESP32 or ESP8266 for something super timing-sensitive like this. I think the FPGA is a reasonable direction, but it feels like you could probably be very successful with a simpler MCU polling a pin.

    1. For most timing applications any MCU with a hardware timer with capture function is sufficient. I have seen FPGAs used for this application, but then usually the whole GPS receiver is implemented in it.

  4. To get good GPS timing performance one of the most helpful things is a roof mounted antenna to avoid multipath problems. Also configure the receiver in stationary mode.

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.