Now that I have my WWVB simulator <https://sites.google.com/site/wayneholder/controlling-time-2> up and running it's allowed me to experiment with the BALDR Model B0114ST clock I own. I've always been curious to observe what happens when it detects and set the time but, typically, this usually happens in the early hours of the morning when propagation of the WWVB signal is better. But, with the simulator, I can observe the time change, over and over again whenever I want. And, since I coded a SYNC signal into the simulator that goes high for one second during the first second of each transmit frame, I can connect this to an LED to use a reference. So, I sent about doing some simple experiments.
First, I wanted to determine how many 1 minute frames of data it requires before the clock will sync up to the transmission. This was easy to test by pulling the battery out of the clock just after the Sync LED lights up and then putting it back in again in order to put the clock into a state where it was reset and looking for a signal. Then, just by watching the LED and the clock display I was able to watch as each frame was transmitted and determine that (at least with my BALDR B0114ST), it takes only two frames of data before the clock is able to sync. So, next, I decided to see if the clock would sync if I altered the simulator code to send a valid time, but the same exact time sent for each frame with no advancement of the minutes. As I had expected when I was first working on code for the simulator, the clock is never able to sync. So, I reasoned that, even though the time code format doesn't include any type of checksum, it probably uses the time difference between successive frames to determine when it has seen two valid frames of data. To test this theory, I changed the code to repeat the minutes value for both odd and even frames (ANDing minutes with 0xFE to send the sequence 0, 0, 2, 2, 4, 4, 6, 6, etc.) To my surprise, the clock was still able to sync to the correct time. However, on thinking about it a bit, I realized that the clock probably saw the repeated frame as an error, but then saw the next frame as valid time the fit with the sequence (for example 0, 0, 2 could be seen as 0, err, 1). And, given that the signal strength of WWVB is marginal in many areas, this improves the clock's ability to sync. Very clever. BTW, has anyone ever seen a WWVB-based clock that displays the year? I don't suppose it's needed, as most people are aware of what year it is, but I'm curious if any clocks that do show the year were ever built. _______________________________________________ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.