Did the NIST "break" a bunch of radio-controlled (WWVB) clocks?

Figure 1:
Was  this clock - and thousands of others like it -
"broken" by a recent WWVB format change?
Shown is a SkyScan model 86715.

NOTE:

For a followup of this article, see the March 18, 2013 entry of this blog - linked here. 

Spoiler alert:  The WWVB format change is NOT responsible for this clock's no longer working - see the above link.


In case you are interested, the August 7, 2012 post - linked here - discusses the construction of an active "repeater" to relay signals from an outdoor antenna to indoor clocks so that they may reliably receive the signal from an LF time station such as WWVB.



Several months ago - late summer or fall of 2012 - I noticed that one of my radio-controlled clocks (often mistakenly referred to as "Atomic Clocks") started drifting away from the correct time.  These clocks use a signal transmitted by radio station WWVB on 60 kHz from Fort Collins, Colorado to wirelessly set their time and date. I checked the voltage on the battery - a common cause of a failure for them to not be able to set the time - and found them to be about 1.2 volts - a bit on the weak side - so I replaced them and the clock reset itself properly to the correct time and date.

A few weeks or a month later I happened to notice, again, that this clock was off a bit - but the "antenna" symbol indicating that it had automatically set its time was turned on.

Hmmm...

I reset the clock again by removing the cells, waiting a minute and then re-installed them and again the clock set itself to the proper time.

A few days later, I checked the clock and again it indicated that it had properly set the time, but it was definitely off by a few seconds.  I then got suspicious and checked the time on another, identical clock (same model number) in a different part of the house - one to which I didn't normally pay close attention - and it, too was off by quite a bit indicating that it hadn't synchronized itself for many weeks.  As an experiment, I took the batteries out of both of these clocks and then reinstalled them, set them where I had a very good signal (to rule out a local interference problem) and let them reset themselves - which they did.

A few days later, I checked them both again and while both indicated by the on-screen icon that they'd set themselves, they were both off - one quite a bit more than the other - and neither one had really synchronized itself after that first time just after installing the battery.

On a hunch, I put out a query on an amateur radio related mailing list related to time and frequency and asked if anyone else had been experiencing any trouble with their radio-controlled clock.

Others did!

In fact, one of them sent to me a picture of one of his clocks that hadn't recently behaved itself and it was the exact same make and model number of the two with which I'd been experiencing problems - the Skyscan model 86715.

What could be the problem, then?  There was one possibility that came to mind first.

WWVB Format changes:

Over the past several years - and especially in 2012 - WWVB's modulation format has changed somewhat.  Historically, WWVB had modulated the time code by reducing the carrier level - originally by 10dB and more recently by 17dB - in order to send, at 1 bit per second, data representing the time, date, magnitude and sign of UT1 corrections, warning of leap second and the Daylight Saving Time status.  The change from 10dB to 17dB was pretty much "transparent" to the existing consumer-grade receivers since that simply represented a greater depth of modulation and, in theory, made it "easier" for them to distinguish between "high" and "low" signal levels that help devices receive the digital time code, slightly improving the weak-signal performance.

For more information about this modulation change, see the NIST paper:

"Increasing the Modulation Depth of the WWVB Time Code to Improve the Performance of Radio Controlled Clocks" (link)

In perusing NIST publication #432 (available here:  http://tf.nist.gov/general/pdf/1383.pdf ) on page 20 one can see the definition of the bits used in the time code and one immediately notices that buts 10, 11, 14, 20, 21, 24, 34, 35, 44 and 54 are "reserved".  Interestingly, this particular publication doesn't actually state (at least not within a page or two of page 20) what the actual state of these "reserved" bits is supposed to be, but other references, including the Wikipedia article about WWVB (see:  http://en.wikipedia.org/wiki/WWVB ) and some of the other NIST publications linked on this page show that, nominally, these bits are supposed to be "0".

An interesting exception to this was bit #54 which, during 2007, was used to indicate the impending change to Daylight Saving time (see the announcement near the top of this page:  http://tf.nist.gov/stations/wwvb2007outages.htm  ) - but this practice was discontinued on July 10, 2007 due to apparent incompatibilities with many radio-controlled clocks.  This indicates a precedent that there can be a problem should the time code be changed!

So, what's different, now?

More recently, the folks at the NIST along with others involved with the U.S. Navy, various educational institutions, and a company called "Xtendwave" published a paper detailing the new modulation changes (it may be found here, in the web archive - link) that details the historical amplitude-modulated code, its shortcomings, and the theory and application of the newer format that includes the BPSK (180 degree phase shift) coding that was added.

The "new" modulation format, tested extensively in 2012, included adding a 180 degree phase modulation to the time code in addition to already-existing amplitude-modulated time code in order to allow different techniques to dig the signal out of the noise and potentially improve the coverage area.  This added modulation includes some error correction bits that - along with a "memory" of past minutes' data bits - could be used to reconstruct a degraded signal and, over time, recover the time code that would otherwise be lost.  In theory, the signal gain from these advanced techniques was more than 10dB - that is, equivalent to at least a 10-fold increase in transmitter power!

Supposedly this phase modulation is "invisible" to the existing base of radio-controlled clocks as they only were capable of detecting amplitude.  In theory, there could be a slight amount of degradation if the receiver's passband filter - typically a 60 kHz crystal or two - was a bit too narrow:  Those seconds during which the phase change occurred might skew the timing of the start of the bit slightly, but this was rather unlikely since for  to happen as the filter would probably have to be too narrow for it to even detect the "normal" 1 baud time code anyway!

I already had an important clue that this wasn't the problem:  The receiver always locked once (and only once!) just after the battery was installed.  If it had trouble detecting the time code in the first place, this would not be the case!

In perusing the document from JKS I noted in its Table 1 that the definitions of each of the bits of the old, amplitude-modulated (AM) code were spelled out in some detail.  According to this, there were no changes made in the format of AM code.

Hmmm, again...

In digging around, I found the formal NIST announcement on their own web site which may be found here:

http://www.nist.gov/pml/div688/grp40/upload/NIST-Enhanced-WWVB-Broadcast-Format-2012-12-07-33.pdf

On Page 5 of this announcement, in Table 1, the bits are again defined, this time with a note below the table that states "Bits 4, 14, 24, 34, 44 and 54 in the legacy AM system were historically reserved for future use, but are now set permanently to 0."  A look at Table 10 on page 13, also within this same document, also shows that these bits are all set to zero as well.

Yet another Hmmm...

So, what can possibly be causing some clocks to have a problem with the format change?

Figure 2:
WWVB (top) and WWV (bottom).  The audio from which the above was generated
may be heard on the video clip below.

To answer that question, I took a "snapshot" by recording both WWV (on 2.5 MHz) and WWVB (60 kHz - the signal to which these radio-controlled clocks listen) and then "manually" decoded it.

Note that the time code contained in WWV and WWVH transmissions' 100 Hz subcarriers is similar - but NOT identical to - the WWVB timecode.

For the recording, WWV was captured since it provided an easy way to edit the sound clip to begin exactly at the start of the minute so that the file's time aligned precisely with actual time, making it much easier to manually decode and identify each bit.  The actual recording may be heard by clicking on the link for the video, below.

For the WWVB's code, the second begins precisely when the carrier amplitude drops and those bits in which the carrier stays low for 0.8 seconds (e.g. only a 0.2 second carrier at full power) are the position marker bits that are used to identify the various portions of the data frame.  Binary "1's" are represented by those seconds during which the carrier is low (and high) for 0.5 seconds while binary "0's" are represented by those periods where the carrier is low for 0.2 seconds and high for 0.8 seconds. 

For a full explanation of the bits so that you can "decode" the time yourself, refer to NIST Publication 432, linked earlier on this page.

It was pretty easy to "manually" decode the entire time code by first printing it out, visually, on a piece of paper, writing in the "0's" and "1's" (and "m" for marker position bits) and then using the information in NIST publication 432 to decode the actual bits.  The result (not surprisingly) matched the voice announcement and analysis showed that the "reserved" bits were exactly what they should have been - all "0's" - so that ruled out the possibility that there was something amiss with the coding of the time signal!

Sniffing on the circuit board:

Since there was nothing about the actual data format that had changed, what about the added modulation itself?  In theory, this shouldn't have had anything at all to do with a clock such as this one that was designed to detect only the amplitude modulation of the WWVB signal.

Carefully taking the clock apart I applied the battery voltage and, while it started to set itself to the radio signal, I poked around on the circuit board until I found the trace that conveyed the raw, demodulated WWVB data from the receive chip (a black epoxy blob on the circuit board near-ish where the antenna connects) to the main clock chip (another black epoxy blob) and attached a wire.

Reinstalling the circuit board with the back of the clock still removed - but with the clock fully functional - I then re-installed the battery so that it turned on its receiver to set itself.  Monitoring the data signal with an oscilloscope, I could see that it was in lock-step with what I was hearing being received on a communications receiver that was tuned to 60 kHz, listening to WWVB.

What this told me was this:  NO, the added BPSK modulation did not affect the clock's ability to receive the data.

I already knew this:  If this weren't true, why would the clock be able to set itself even once, when the battery was first installed?

Well, did the NIST actually break anything?

The quick answer is NO, the addition of the BPSK signalling to the time code did NOT break this - and other - receivers.  Since the data format that was being sent via the amplitude-modulated time code had not changed either, that idea could be tossed out as well!

So, if it isn't anything the NIST is doing (or not doing, for that matter) why have these particular clocks failed to work properly?

I'm still not 100% sure, but I'm beginning to think that it's a "silicon problem" - that is, the part of the clock that takes the WWVB time code and converts it to the actual time of day and date is "broken" when it sees recent dates.  Since the time of day, "day of year" and UT1 corrections appear to be the same as they have always been, could it be that the clocks are now having a problem with the year?  If this is the case, why, then, did it work for most of 2012 before failing - and what's significant about the date?

As it happens, these clocks also show the phase of the moon - presumably from a lookup table:  Could it be that this table has "expired" and that the clock is "choking" when trying to update the lunar phases?  For the time being, however, the clocks do seem to correctly show the phase of the moon.  Is there something else that, as of mid-late 2012, has "broken" within the clock's internal logic circuitry/programming?

The next step  - when I get time - will be to locally regenerate a simulated WWVB signal without the phase shift, just to see if that has anything to do with it and synthesize different scenarios - including different dates. Hopefully, this should answer the question about whether or not it's the modulation or the actual time and date that is causing these clocks to exhibit problems!

For a followup of this article where I construct a "WWVB Simulator" and try other dates to see if the clocks "break", see the March 18, 2013 entry of this blog - link.

Comment: 

There are some types of WWVB receivers that have been "broken" by the addition of the BPSK time code.  These receivers had been used in the past to provide accurate frequency references based on the 60 kHz carrier, but have been supplanted in professional and institutional use by the use of GPS, rubidium and cesium-based references/standards.

Since these inexpensive, consumer-grade clocks in no way care about the exact carrier frequency of the WWVB signal, they don't even "see" the added BPSK modulation and are thus unaffected.

.

[End]

This page stolen from ka7oei.blogspot.com