[time-nuts] Observations on how "Atomic" WWVB clocks set time

[Wayne Holder]

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.