We have no idea if the background story is true or not, but we’re not going to let something like “truth” get in the way of a good story. The way [Kwan3217] tells it, first there were hours on sundials. Then when these were divided into sixty minute sections, they were called “minutes”. “Seconds” comes from a second division by sixty, into “second minutes”. The “third” division into sixty would give a time unit that lasts a sixtieth of a second.
[Kwan3217] built a clock that displays these third minutes. Weighing in at just a tiny bit over 16.6666 milliseconds each, the thirds’ hand is going to be spinning pretty fast, so he used LEDs. And if you’re going to display thirds, you’ve got to get them right, so he backs the clock up with GPS. There’s a full video playlist about it, and phenomenal detail in the project logs.
We really liked the implementation of the state machine that reads the GPS strings. [Kwan3217] leans heavily on a crash state that waits for the next dollar sign — marking the beginning of a GPS NMEA data block. Almost all of his functions that parse the GPS data stream know what kind of data they’re expecting next, and if they don’t get it, they crash out. So while it probably doesn’t really matter if his wall clock misses a GPS message, at least it’ll get back in line with the exact time soon after. Check the code out if you find yourself parsing GPS strings.
And did we mention the circular traces on the PCB? Or the lightpipes?
We’ve run a lot of posts about clocks, and none of them have displayed the thirds. With a GPS-disciplined microcontroller, getting even single milliseconds spot on is no problem. The issue is displaying them. So it’s no surprise that a lot of folks go the opposite direction, telling the time either approximately like the word clocks, artistically like this Berlin set-theory clock, or inscrutably like all the resistor-color clocks or bizarro binary clocks out there.