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.
OpenPPC? It’s OpenPPS (Pulse Per Second) – Come on HAD, you can do better. At least look at the stuff that’s linked before writing the article and pressing “submit”
they had pay per click on the brain
“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:
https://www.quora.com/unanswered/What-is-the-most-cost-effective-accurate-GPSDO-open-source-way-or-project
https://www.quora.com/unanswered/What-is-the-most-cost-effective-accurate-GPS-disciplined-clock-synchronization-circuit
https://www.quora.com/What-is-the-most-precision-hacked-together-electronics-test-equipment-youve-made
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.
There are timing systems *far* in excess of GPS timing that do not involve the inherent risks of an RF-based signal. CERN open sourced https://white-rabbit.web.cern.ch/ a while back and there are several integrators that are bringing this to market.
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.
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.
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:
http://www.eevblog.com/forum/testgear/bg7tbl-gpsdo-master-reference/
The firmware has long since been fixed, but the buggy version is compared here:
http://www.ke5fx.com/gpscomp.htm
Note, there are about a dozen versions around, and not all are created equal… ;-)
hams use gps as a frequency standard, this is using it as a time standard.
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.
See also https://hackaday.io/project/18501-gps-clock
Mine has 100 ms of granularity and is accurate to around 200 µs.
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.
Digital cellular base stations have evolved a few times over in the last 15 years. Just about the only HAM usable component on these base stations that can be liberated from the scrap heap are the GPS disciplined clocks or variations thereof. You have to have a keen eye on ebay to find them when they pop up.
http://www.realhamradio.com/GPS_Frequency_Standard.htm
http://www.prc68.com/I/Z3805A.html
I think that using neo m8n, configuring the LED to 10 MHZ, using a tcxo at 10 MHZ or even better a rubidium clock in phase lock would be much better
see https://www.youtube.com/watch?v=cMpLNeHIAeU
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.
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.
Y’all can complain about a typo all you want; the thought of an Open Pulsed Plasma Cannon gives me goosebumps!
Opensourced Photon pulse cannon? Heck yeah! Make that a gamma please!
http://www.xdatabase.de/x3-reunion/en/goods.Gamma+Photon+Pulse+Cannon.group2.good21.html
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.
Another good related project: https://mitxela.com/projects/precision_clock_mk_iii