The advantage of a radio-controlled clock that receives the time signal from WWVB is that you never have to set it again. Whether it’s a little digital job on your desk, or some big analog wall clock that’s hard to access, they’ll all adjust themselves as necessary to keep perfect time. But what if the receiver conks out on you?
Well, you’d still have a clock. But you’d have to set it manually like some kind of Neanderthal. That wasn’t acceptable to [jim11662418], so after he yanked the misbehaving WWVB receiver from his clock, he decided to replace it with an ESP8266 that could connect to the Internet and get the current time via Network Time Protocol (NTP).
This modification was made all the easier by the fact that the WWVB receiver was its own PCB, connected to the clock’s main board by three wires: one for the clock signal, another that gets pulled low when the clock wants to turn on the receiver (usually these clocks only update themselves once a day), and of course, ground. It was simply a matter of connecting the ESP8266 dev board up to the two digital lines and writing some code that would mimic the responses from the original receiver.
If you take a look through the provided source code, a comment explains that the WWVB signal is recreated based on the official documentation from the National Institute of Standards and Technology (NIST) website. There are functions in the code to bang out the 500 ms “one” and 200 ms “zero” bits, and once the microcontroller has picked up the correct time from the Internet, they’re called in quick succession to build the appropriate time signal. As such, this code should work on any clock that has an external WWVB receiver like this, but as always, your mileage may vary.
This is a very clean hack, but if you wanted to pull off something similar without having to gut all the clocks in your house, we’ve seen a WWVB simulator that can broadcast an NTP-backed time signal to anything listening nearby.
It’s better than even odds that the 60 kHz receiver is functioning just fine, and that it is just swamped by rising ambient noise floor from more and more bad switching power supplies in the vicinity.
Would be interesting to see what the noise floor looked like. But most SDR receivers wont go that low. I was wondering if it might be and old capacitor going bad and losing the 60kHz tuning so it couldnt lock onto the signal anymore.
There are up converters you can build or buy to listen to LF on an SDR. You can also try using a sound card and pre amp, but many sound cards will be low pass filtered and unusable at 60kHz.
The tuning capacitor will likely be ceramic or film. It would be unusual for one to fail in that sort of application.
Or it got knocked and the coil moved a little along the ferrite.
Or it’s at a slightly wrong angle.
Or someone put a frame up behind it!
If surprises me that they work at all frankly!
WWV can be challenging to receive in some places. NTP is definitely a better option in most cases.
Maybe for much of the planet. However, half of my house can’t reach a NTP server (network-free zones). But most places in my house CAN hear WWVB (not surprisingly, exactly the places that aren’t infested with computers and networking hardware). Not saying it’s better, just more available.
I have a 25 years old radio controlled battery powered alarm clock, and it has survived being thrown full force into a door. They are more robust than they get credit for. Switching power supplies, especially the cheap chinese ones can obliterate the whole shortwave band along with the time signals on LF. Been there, done that. LED lights and lighstrips also produce copious amounts of noise more than capable of blocking time signals.
If you want to do this without requiring an internet connection, you can setup your own NTP server on your LAN using a GPS module as the clock source.
Better yet, attach the GPS module to the ESP and have it act as a NTP server for the rest of the house from the wall clock.
If the connection had been as straight forward as this was, I’d have done this with a bunch of LED clocks that were getting their time sync from the 2G cell network…until they weren’t.
Couldn’t even just leave them alone because they started setting themselves to random garbage times.
I got lucky and was able to blindly disconnect (desolder) half of the module to disable it. Removing the module completely made the clocks not work at all.
Interestingly, I’ve only had to set the time on one of the 10 or so units since the modification about a year ago. Dodged a bullet there.
I’m very interested in this project – I have a Lacrosse WS-8007U Radio controlled clock, but since I use it in the basement, it doesn’t get synced to WWVB. I opened it up tonight and found two glop-top chips on the circuit board and noticed only a few circuit traces between them. Sure enough, I was able to see the very slow square waves that appear to be the time code! I’ll be looking into this in more detail to see if I can get your code working on an ESP8266.
There are android apps you can use to sync the radio clock with, in your case the Junghans MEGA app should be able to generate the signal needed since the junghans mega series watches receive the WWVB time signal. Just follow the instructions in the app. Alternatively, the DCF77 emulator app might also work, in case the clock is multifrequency capable.
Few, if any, WWVB clocks actually adjust their running rate the way a properly configured NTP-using clock would. Mostly, they just jam the time to the value they receive in the middle of the night.
Adjusting the clock frequency is much more complex and nightly updates are the norm because you would need to check different WWV frequencies during the day depending on HF propagation. NTP or cellular could be done much more often. If it is just a human readable device not supplying clocking to other devices it doesn’t need to be subsecond accurate.
the timing error between the DCF77 device i use and my computer what is NTP synced is so small its irrelevant even if the DCF77 hasnt gotten a sync in 3 days. Longest time without sync was a week and then the error was just humanly noticeable, in the order of .2 .3 seconds. Computers are a whole different level of drift, +- 0.7 seconds a day when running seems to be the norm.
Since the time update only needs to be done once a day (or less) , I’m wondering if the ESP8266 could be put into a sleep mode and only wake up when necessary, get the NTP time, send it to the clock and then go back to sleep. This would allow the project to remain battery operated.
Sure, you could power it off completely if you wanted to but the timer circuitry would require some intelligence and have power consumption as well. A simple idea that comes to mind would be to power the esp off the leftmost one digit so the esp would only be on from 10:00 to 12:59 six hours a day, a 75% reduction.
I was thinking about using the /PON signal that the clock uses to turn on the existing radio receiver chip. My initial testing on the Lacrosse clock showed that the clock chip sets that signal low once a day at midnight for a few minutes (10?) listens for good data and then turns the radio off. That would be a perfect candidate for waking up the ESP8266, connect to WiFi, get the NTP data, send it to the clock chip, then go back to sleep. If that’s still too much drain on the battery, it could update only once a week. When it wakes up, check a counter and go back to sleep immediately if it the counter has not reached ‘7’ (or whatever increment is preferred).
This is an excellent idea. I’ve re-worked my project so that the ESP8266 goes into deep sleep and wakes up only when the clock controller turns on the radio at 1AM looking for the signal from WWVB. THe ESP8266 updates the clock and then goes back to deep sleep. I’ve replaced the power hungry NodeMCU development board with a more frugal ESP-01. The whole thing is running from the clock’s 2 AA batteries rather than being powered from USB as originally. We’ll see how long the batteries last.
Sounds in the same vein an ESP8266 hack that I did a few years back.
My factory has an very tightly firewalled automation network – so tight that there was no NTP traffic passed. And because everything was running on a virtual machine, it was nearly impossible to keep system clocks in sync – we’re talking minutes of error.
I turned an ESP8266 into a GPS emulator. “But the ESP8266 doesn’t have GPS!” you shout. What it does have is a Wifi module. A Wifi module that can connect to the factory’s guest network, make a simple web request to the IP address of google.com, and read the timestamp from the header every hour or so. Good enough to get me to the nearest second. Then the ESP8266’s USB serial port becomes an NMEA serial output from a GPS. The USB serial port on the VM host gets connected to the VM of the domain controller. And voila.