As a community of mostly engineering-minded folks, I hope we can take this as a warning to not make our mission-critical systems depend on inputs that are merely convenient side-effects of third-party systems provided free of charge and without obligation. I mean, it doesn't matter how many people post comments here saying things like "50 Hz AC is more accurate than quartz crystal for timekeeping", the fact is that no external agency can take over the action of your quartz crystal and force your clocks to slow down or speed up, whether intentional or not, as an effect of their political actions.
If you want a free source of mostly-reliable oscillations, and it doesn't have any real impact if it falls out of sync, sure go ahead and use something like this. But in the case of time, if you want to sync a clock in Western Europe with something that is free and non-internet based, you're much better off using DCF77 [0], which is specifically designed to synchronize time and comes with specific uptime and quality promises. Still ultimately susceptible to political actions, of course, in extreme cases, but at least you know its primary purpose is to transmit time information, and it is in the control of only one (relatively) stable government as opposed to being subject to the unpredictable changes brought about by interactions between multiple interconnected systems.
DFC77 doesn't solve the same problem as using AC as an oscillator, of course, since you still need an oscillator to keep your clock going during the downtimes that are permitted to the radio signal.
>depend on inputs that are merely convenient side-effects of third-party systems provided free of charge and without obligation.
I would disagree. You don't get it for free, you pay for that. The Grid frequency is regulated and the powergrid providers have, IIRC, even legal obligations on how far they are allowed to deviate the time.
Using AC as clock signal is good enough if being wrong by a few minutes is not mission critical. If you absolutely do need accurate time use DCF77 or GPS.
> As a community of mostly engineering-minded folks, I hope we can take this as a warning to not make our mission-critical systems depend on inputs that are merely convenient side-effects of third-party systems provided free of charge and without obligation.
That is not entirely true. The TSO is committed to keeping the average frequency of the power grid at 50Hz and has always communicated that. It tries to keep grid time within 20 seconds of UTC, and has historically achieved this. So it is reasonable to use the grid as a time source where high accuracy is not required. The current situation is highly irregular. Using the grid frequency for time keeping is a secondary function of the electricity grid, but it is not merely an unintended side-effect.
I agree with the rest of your points about using a different time source where high accuracy is required.
Good point about this service, I almost forgot that it still exists (although reception is somewhat spotty indoors).
The basic advice is sane ("do not rely on side effects"), yet "third-party systems provided free of charge and without obligation" sounds exactly like that, except now it's putting all your eggs in a basket that's controlled by one entity (be it DCF77, or the GPS temporal component). I would think that the AC-as-a-clock is usually chosen for convenience rather than high reliability - "the juice is needed anyway, why bother with an extra receiver?" - and if you actually need to tell the time, checking multiple independent sources would be encouraged :)
DCF77 surely cannot be that bad indoors on the Continent?
When living at what was then often quoted as the extreme fringe of the coverage area - Trondheim, Norway, on 63,5 degrees of latitude - I had reliable coverage as long as the clocks were kept in window sills (hence, effectively outdoors)
However, just moving down to my current home (on 62 degrees, or -roughly speaking- 11% closer to the transmitter site), I now have reliable coverage everywhere (granted, in a wooden house - but the DCF77 alarm clock in the basement synchs every hour, too)
Citizen, the Japanese watches maker, offered a passive (without batteries) "enhancer" for their AT series, IIRC was a ferrite block where to put the watch, I think I've seen a photo.
Or one can use a PC to transmit the DCF77 signal locally (it could be illegal) to a clock using a pair of headphones, I've seen at least a couple of examples but never tried them.
More importantly, you would need to know how the antenna is oriented within the enclosure of your clock. I'm pretty sure that that wasn't mentioned in the manual of the one I bought.
Beats me - I'm within reasonable driving distance to the antenna (one border away), yet clocks fail to acquire signal unless outdoors/directly at a window. Just a bad coverage area, I guess.
This is completely outside of my area of expertise, but doesn't the radio signal strength decrease exponentially? So that last 11% could be a big deal?
Line-of-sight attenuation of an EM wave in the empty space is quadratical, whilst - for example - attenuation of an electrical signal in a wire is exponential.
Another advantage of DCF77 and similar is that they also broadcast the current time, while the 50Hz or 60Hz AC is just a frequency. If you have only a frequency, you have to set the initial time manually every time you lose power.
DCF77 also tells you what time it is, AC can only keep whatever time's been set in sync. The equivalent would be to include a 50-cent crystal oscillator instead.
On a only barely related note, I've been playing with the idea of implementing a NTP synced clock on an ESP8266. It'd wake up, join wifi and sync NTP every few hours, then keep time on its internal crystal in between. It should be a good deal cheaper, work anywhere in the world, and have better indoor coverage (I have a DCF77 clock in an interior bathroom in London, and it never syncs. Kind-of defeats the purpose that I have to move it to a south-facing room for the day to get it to sync).
You could try a USB SATA drive with a FAT16 filesystem containing "/wifipass.txt". USB-1.0 low speed is 1.5Mb/s and while I can't find documentation on ESP8266's GPIO switch speed, it's CPU is 40MHz, so bitbanging should be feasible.
I was thinking about this in terms of building a product.
Even with that, a clock generally runs for months, even years, on a single battery. Not exactly phone territory, but might be feasible on the ESP8266, depending on how the oscillator behaves in deep sleep mode.
There are many dedicated real time clock chips, pre-designed for backup time-keeping and low power usage. Interfacing with one is going to be way faster/easier/better than trying to roll your own on a general purpose microcontroller, IMO.
TI's bq32000 is $0.55@1K, is 3.3V for easy interface to the ESP, and takes just over 1 microamp in backup power mode. That's just one that I quickly poked at.
(Side note: at this point, I'd think I'd want to be using an ESP32 in any new designs.)
It was mostly used in the common radio alarm clocks, the ones with a 4digit red 7 segment display that were all based on an IC from the 70s that handles everything (minus the radio which is a completely indipendent module).
GPS is also an extremely accurate source of time, although since it's on a much shorter wavelength your reciever needs a clear view of the sky and is much more complicated.
If you want a free source of mostly-reliable oscillations, and it doesn't have any real impact if it falls out of sync, sure go ahead and use something like this. But in the case of time, if you want to sync a clock in Western Europe with something that is free and non-internet based, you're much better off using DCF77 [0], which is specifically designed to synchronize time and comes with specific uptime and quality promises. Still ultimately susceptible to political actions, of course, in extreme cases, but at least you know its primary purpose is to transmit time information, and it is in the control of only one (relatively) stable government as opposed to being subject to the unpredictable changes brought about by interactions between multiple interconnected systems.
DFC77 doesn't solve the same problem as using AC as an oscillator, of course, since you still need an oscillator to keep your clock going during the downtimes that are permitted to the radio signal.
[0] https://en.wikipedia.org/wiki/DCF77