How do you get the attention of thousands of Hackaday readers? Build a clock! There are just so many choices to agonize over. Do you go with a crystal as a clock source, a fancy oven controlled crystal oscillator, or just mains voltage? Should you even think about putting a GPS module in a clock? All these are very interesting questions that encourage discussion or learning, and that’s what Hackaday is all about. Clocks are cool, and the engineering behind them is even cooler.
For one of [Nick]’s Hackaday Prize entries, he’s building a minimalist GPS clock. First up, the centerpiece of every clock, the display. There are eight seven-segment displays, two each for the hours, minutes, and seconds, and a smaller digit for tenths of a second. These displays are controlled by an ATXmega32E5, an upgrade on an earlier version of this project that only used an ATtiny and a MAX6951 LED driver.
The GPS wizardry is where this project gets really cool. [Nick] is using a SkyTraq Venus838LPx-T (that’s also available on a breakout board on Tindie). This GPS chip has a handy edge mount SMA connector to receive the signals from a GPS satellite, and has a bidirectional UART to dump the NMEA time codes and a PPS output. By combining the timecode, PPS output, and playing around with the timers on the microcontroller, [Nick] has a fantastically accurate clock that also looks great.
Doesn’t that chipsets do 10Hz updates anyway?
Well, the Venus838LPx-T is the *timing* module variant, not the navigation module. And even the navigation module’s PPS output is 1 pulse per second.
Timing modules work a bit differently than navigation modules. Most of them will perform a position survey either at power-up or on-demand and will average those samples. Once the survey is complete, the module locks that position down and presumes it won’t change. Then it can solve the equations for time accuracy rather than position. This allows it to give much more accurate timing results when, for example, the constellation is reduced because of poor reception.
What about “RealLocalTime” by offsetting the global time by the geoposition info (360degrees = 24hrs, the rest is primary school maths).
That way you can get the clock to really show 12:00 at noon.
Explaining time starting with “real noon” at your position and why local time in every village had to be replaced with a centrally administered one because of trains… lot’s of stories for the scientists of tomorrow… ;-)
Someone once asked for firmware to make it into a GPS driven sidereal clock. The problem with that is that calculating sidereal time generally requires heavy duty floating point, which is asking too much of the AVRs I’m using.
That said, I do have a sidereal clock daemon for the Raspberry Pi clock, which is the same display hardware as the original version of this clock with the MAX6951 hooked instead to the SPI bus of a Raspberry Pi GPIO header.
I don’t know which Venus you are using, but some of them you can upload your code in them, then you have 64bit FP on a neon MCU.
That’s a little beyond my capabilities, at least at present.
If I were going to design a GPS Sidereal clock, I’d probably upgrade to an ARM Cortex Mx. I’ve been playing with the ATSAMx70 of late, but that one is way overkill. There’s probably something in the middle between that and the XMega_E. But, at least at the moment, the Pi Zero clock is a much easier way to make it happen.
if too much for avr, how about the blue pill? ;)
A friend of mine that used to run the observatory at Fernbank Science Center in Atlanta, GA had a digital clock with two 7 digit 7-segment displays, and displayed local and sidereal time down to tenths of seconds. It was a gift from a Ga Tech student, and it was done entirely in hardware (no microcontroller). This was back in the early 80’s. He’s since passed away, and I never knew what became of the clock.
That’s an impressive feat to do it in bare hardware.
I designed – but haven’t sat down and built it yet – a dual display system for my Pi Zero clock that could do local and sidereal time simultaneously. It’s just two of the display boards with one of them getting the SPI CE0 line and the other getting CE1 and you just run two daemons on the Pi.
Maybe I’ll sit down and do that today as a PoC.
Did you make any progress on your display?
Well, The HAD conference happened, and then Thanksgiving happened… I will do it at some point… promise.
2 x hours
2 x minutes
2 x seconds
1 x tenths
——–
7 x 7segments
There’s actually a “virtual” 8th digit that’s used to drive the AM, PM and colon LEDs, FWIW.
I get servers needing accurate time, but what is a human going to do with a clock accurate to a tenths of a second?
I’ll tell you the story.
When I was in college, I built a Heathkit GC-1000 clock. That’s a WWV/WWVH radio clock. It had a 10th digit too. I like the 10th digit, personally. There is a menu item in my clock to turn it off, however.
Anyway, I lost track of it a long time ago and Heathkit went by the wayside and life moved on. Then, recently, Heathkit was famously resurrected, and there was much hopefulness throughout the land. The ersatz Heathkit, unfortunately, has turned out to be a bit of a disappointment. Their third product was what they dubbed “The Most Reliable Clock.” $100ish would buy you a 60 Hz line driven clock in a wood and acrylic case.
I sort of said half out loud, “Shoot, for that kind of money, they could have made a GPS clock as a modernized take on the Most Accurate Clock.”
And I said to myself, “well, you don’t have to wait on THEM to do it…”
As for what the 10th digit buys you… well, you can use it for timestamping video or photographs. For me it’s just a conversation piece. Adding a 100th digit would just be useless from a human perspective, but claiming 200 µs accuracy with 1 second granularity just seemed (more) pointless. 0.1s granularity is splitting the difference.
I saw the GC-1000 lying idle in the garage a few days ago, so I plugged it in. I haven’t checked to see if it has sync’d or locked yet.
About 20 years ago, I printed out a list from USENET that mentioned 10 upgrades that Heathkit should have done to make the GC-1000 more reliable. I haven’t tried any of them…
…maybe this time…
You may need to do some recapping. There’s a Yahoo group for the GC1K out there a common failure mode is that 120 Hz leaks through the primary supply filter cap (because it’s dried up with age) and wrecks the 100 Hz decoding of the timecode.
You can work around that by feeding a nice, clean 12 volts DC into the 12v input jack instead. The filter cap’s lack of capacitance shouldn’t matter, and modern switching supplies will have ripple that’s much higher in frequency, so it likely won’t matter.
Thanks!
A one second tick, with a 6ns accuracy, can be easily used to discipline a local counter/oscillator so you can compute time to better than 1/1000,000 of a second. Counting in 1/100’s should be child’s play.
You could start with this: https://hackaday.io/project/6872-gps-disciplined-xcxo and divide it down as you suggest. I didn’t do that with this design because I wanted to balance accuracy against cost. A clock with 100 ms of granularity that’s a display for humans need not be accurate better even than a few parts per thousand, let alone per million, if it’s being disciplined constantly by GPS.
You don’t need to use any more hardware than is built into your micro controller (look up what you can do with the timers). Another way you can simplify things is to combine the microcontroller and the GPS together into a single unit. Take a look at the NavSpark for example, a $25 32 bit MCU based on the Venus 8 GPS chip and programmable from the Arduino IDE.
NTP source, and this is of course HaD where practically everyone has servers all over the house.
You could get the NMEA and PPS outputs from the on-board header and feed them into a Raspberry Pi if you wished.
screw ntp; go for ptp or sync-e (lol).
Watch this space: https://hackaday.io/project/27873-embedded-gps-ntp-server
Ask this guy: http://www.leapsecond.com/great2005/
Now to add a timezone/daylight savings map to this so it will know the time wherever it is.
That’s really, really hard for such a constrained platform. You do have your position, yes, but the map of timezone boundaries is a political one, and describing it in points and line segments is messy.
Adding more sets of DST rules to the firmware isn’t hard at all. There’s a set of (inline) methods that figure out for a given date whether DST is in effect or not in that jurisdiction, or if this is a transition day one way or the other. There’s a method in the code that will determine the date of the first Sunday of a given month. From there, figuring out the last Sunday or the second one or what not isn’t hard (and there are examples in the code to follow). Just make such a method for your country and then add it to the switch statement that picks which set to use. If there’s a hard part, it’s figuring out a two digit seven segment representation of the name of the rule set for the menu system (nZ, Au, Eu, uS…).
There’s a placeholder in the code for supporting half-hour timezones, but it’s not connected up mainly because I didn’t want to make the menu system even *more* complicated than it already is. But again – it’s open source, so there’s nothing stopping anyone from adding it.
Of course, tracking changes will likely require firmware updates. Just ask the folks who maintain the *nix TZ DB about that.
Speaking of complicated menu systems, for completeness, add Nepal (UTC+5:45) and the Chatham Islands (UTC+12:45) on top of the half-hour timezones.
Also, don’t forget Lord Howe Island, which has DST but only shifts by half an hour.