Yes, the NIST did break a bunch of radio controlled (WWVB) clocks... Sorta...

In a previous post - link I commented on how several radio-controlled clocks of one particular model (Skyscan model 86715) seemed to have stopped working properly in the summer/fall of 2012 in that they would synchronize to the proper time and date only once - just after the battery had been installed - but never again.

PLEASE NOTE:

There have been anecdotal reports by some customers of the affected-model clocks that some representatives of the manufacturer suggest that they are misconfiguring them and/or a change in WWVB's signal format is to blame for their clock no longer working.

If your clock will properly set itself ONCE after removing the battery and replacing it - but it does NOT set itself again, despite the "antenna" symbol, it is a defect in the clock itself!

Because the affected clocks are rather old, it is perhaps unreasonable to expect the manufacturer to "make good" on the clocks' defects, but I would expect that they do know by now the true nature of the defect and would post information accordingly.

Comment:  This problem may also affect Skyscan models 86730 and 87315 as well.

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 - but it will NOT solve the problem with the affected clocks!



Making a WWVB simulator:

Figure 1:
The SkyScan model 86715 radio-controlled
"Atomic" clock - apparently not
Y2.013k compliant!
Spoiler:  The WWVB modulation change by
the NIST is NOT responsible for this clock's
no longer setting itself!
Click on the image for a larger version.

Since the suspicion based on the previous observations was that it seemed more likely that these clocks were "unhappy" with the date with which they were presented and were subsequently unable to set themselves to the correct time, I decided to generate my own local version of the WWVB 60 kHz signal to test this theory.

For a signal source I didn't have handy a synthesized 60 kHz generator (I could have built one, though) but I did have a synthesized audio generator built into a service monitor that could produce a 30 kHz sine wave.  Frequency stability is important as the bandwidth of these receivers is just a few Hertz and not only would it be rather tricky to set a free-running oscillator exactly on-frequency, it would also be unrealistic to expect it to stay within +/- 1 or 2 Hz over a period of several days without a bit of extra care.  Since this audio generator could produce about 5 volts (at 600 ohms impedance) of nice, stable audio signal at 30 kHz I just needed to double the frequency.

That's what full-wave bridge rectifiers are for!

Figure 2:
Setup for simulating the WWVB signal using a computer-controlled relay (in the Model 100),
a 30 kHz signal source and a full-wave bridge rectifier.
Click on the image for a larger version.

Rummaging around, I found a small-ish (4 amp) bridge rectifier (but I could have used 4 ordinary diodes) and in testing it with an oscilloscope, noted that its diodes were plenty fast enough to take the 30 kHz sine wave from the audio generator and produce a nice, pulsating DC 60 kHz waveform out the other end.  Connecting the output (DC) terminals of this full-wave rectifier to a couple meters of wire I now had a coil that I could wrap around the clocks being tested to induce into them a 60 kHz signal:  A quick test with a portable ultrasonic receiver and coupling loop that I have used in the past to listen for WWVB and other longwave signals verified that this portion was working properly.

The next step was to generate some time code.  In thinking about this, all sorts of things came to mind from hacking a program with a Raspberry Pi to "key" the 60 kHz signal to programming a PIC with an attached GPS receiver to generate a modifiable time code to even using a PC to toggle some sort of hardware line.

In the end, I settled on something much more retro and comparatively low-tech:  An old Radio Shack Model 100 Laptop.

Made in about 1983, this thing has been around for a long time.  It has only an 8-line by 40 character display and 32k of RAM and a CMOS 8085 processor that runs at less than 4 MHz, but it has a built-in clock which, by the way, is not Y2k compliant as it has a hard-coded "19" in mask ROM for the first two digits of the year!  By knocking together a simple program in the computer's built-in BASIC language I could fairly easily generate a time code that was timed using the Model 100's internal clock.

Originally, I was going to toggle a handshake line on the computer's RS-232 port to key a transistor or diode to turn on/off the 60 kHz signal, but it occurred to me that the Model 100 already had a built-in relay that was intended to start/stop the motor of a cassette recorder used for program/data storage and backup.  This was easily controlled by the "Motor On" and "Motor Off" commands built into BASIC and in testing this feature I observed that it very easily keyed the locally-generated RF signal on/off.

Using NIST publication #432 (available here:  http://tf.nist.gov/general/pdf/1383.pdf ) as a reference, I set about hacking together some (rather ugly) code that would plow through the ASCII time/date strings accessible in BASIC to generate the BCD time code used by WWVB to convey the time and date.  For sending the amplitude-modulated bits themselves, these are defined by the reduction of carrier amplitude at the instant that the second began which meant that all I needed to do was to generate a pre-determined period of silence (no carrier) to generate the appropriate bit (a zero, a one, or a "position marker") and then turn the carrier back on and wait for the second to change:  While waiting for the second to advance, I would do my string processing to generate upcoming bits and when done with this, simply wait for the second to change and then drop the carrier, avoiding the need to do any sort of rudimentary multitasking or interrupt.

When first started the program initializes an array that contains integers for each of the 60 seconds (0-59) and "pre-loads" those bit positions that are "reserved", marker bits, the UT1 corrections, Leap second, Leap Year, daylight saving time bits and those that define the year.  What that left to do on-the-fly was to generate just hours, minutes, and the day-of-year count - pretty easy to do even on a 30 year old 8-bit computer!

(I was lazy and didn't have the program calculate the 2-digit year from the built-in clock:  To change the year I just go into the array initialization routine and modify the relevant bits manually!)

Aside from fat-fingering the pre-loading of one of the marker bits, the program worked the first time with the clock immediately synchronizing to the time to which the Model 100 was set.  After a bit of fine-tuning of the "FOR-NEXT" loops used to generate the "carrier on" delays for indicating 0's, 1's and marker bits, I was ready to go!

Comment:

During testing of the program to simulate the time code I found that the WWVB clock was quite insensitive to the precise timing of the bits themselves and variations of +/- 100 milliseconds from the official specifications (e.g. 200ms "off" carrier for a binary "0", 500 ms for a "1" and 800ms for a position marker) didn't seem to faze it.

This ability to deal with wide timing variances further indicated that it should be more capable of dealing with bit timing variations that might be caused by the addition of a BPSK modulation component.

One minor point of departure from the WWVB modulation format was that I was on-off-keying the carrier rather than reducing it by 17dB in the manner of the longwave transmissions.  Practically speaking, this was unimportant since the receivers simply look for a reduction in signal with respect to the recent peak signal level.  Using a very simple TRF (Tuned Radio Frequency) receiver, the receivers have a very slow AGC (Automatic Gain Control) that keeps track of the signal level and allow the reductions in power that comprise the modulation to be easily detected.  This AGC also allows my very strong, locally-generated signal to completely override the much weaker WWVB signal coming over the air.

Were I a purist I could have simply connected a potentiometer across the computer-controlled relay as suggested in figure 2 to set the level of the "backwave" to be about 17dB down -just like the transmitted signal - but I didn't bother doing this!

Note: 

The NIST experimented with on-off keying several years ago to determine the optimal amplitude change.  These consumer-grade clocks actually work best with a complete interruption of the carrier as that makes most clear the distinction between the two modulation states.  The white paper about this testing that may be found here:  "Increasing the Modulation Depth of the WWVB Time Code to Improve the Performance of Radio Controlled Clocks" - link.

Testing the clocks:

I have two of these Skyscan 86715 clocks, both with the same problem and one of them had been "stuck" for several weeks, seemingly unable to reset itself daily to synchronize its time.  The other clock I had reset during the testing of this WWVB simulator and had allowed it synchronize to the UTC time and date being generated by the Model 100 - February 1, 2010 - a time and date with which I knew the clocks had been happy.  Wrapping a couple turns of wire around each clock, I let them sit overnight.  (Initially, I also placed next to them another WWVB clock that was known to still work:  It happily synchronized to any time that I programmed the old Model 100 to send.)

The next morning I looked at the two clocks:  The one that had been recently reset was still synchronized to my "local" WWVB signal and now showing February 2, 2010 with the proper time zone offset, but the one that had previously been listening to the off-air signal was still "stuck" with the March 2013 date.  To be sure of what I was seeing, I let it run overnight again and the next morning I saw the sat the first clock had, in fact, dutifully set itself overnight and was in lock-step with the local signal while the other one had not.

Resetting the second clock - the one that hadn't been updating itself - by removing its battery for a moment, I saw that it immediately set itself to the same time and date as the other clock so I left it to run for a couple more days:  Both clocks were now staying in lock-step with the clock on the Model 100, drifting off by a fraction of a second by the end of the "day" before resetting themselves as they should.

What this exercise had indicated was that once a clock locks to the current time and date, it will never resynchronize again - even if it is receiving a time/date with which it is happy (e.g. from a time "before" it broke)!  In other words, whatever it is that causes the clock to dislike dates beyond late 2012, it seems to "crash" the clock so that it will never correct itself later unless the battery is removed.

Will it break?

Now for the "Date Test."

I reset the time on the Model 100 to be about 6 hours off from what it had been and also set the date to February 15, 2013 to allow me to easily tell if they had resynchronized to the new "reality."  The next morning showed that both clocks had dutifully reset themselves and were now showing February 16, 2013.

The next step was to wait another couple days to see if they would resynchronize themselves again, or just get "stuck" again, never resetting their time again.

The results:

It would appear that we have an instance of "broken sand" here!

Over the next several days, the clocks never did reset themselves again, drifting farther and farther away from the time being generated by the Model 100.  To me this indicated that there is something in the programming that does not like the current date - that is, anything in the year 2013!  I also tried a few years hence (2014, 2015, etc.) with the same result.

Figure 3:
The Model 100-based WWVB simulator and the two clocks being tested.  One clock was set to Mountain
time, the other to Eastern time.  The beige wire wrapped around the clocks are the coupling loops.
The generator of the 30.000 kHz signal source used for producing the modulated  60 kHz carrier is not shown.
Click on the image for a larger version.

Strictly speaking, these clocks are not Y2k compliant since they don't know about the century - but neither is the WWVB time code as it sends only the last two digits of the year.  Since the problem is most likely year-related, it's likely that eventually - in another 85 years or so, the the years are again in the very late 90's - the clocks will start working again on their own, but neither the clocks or I (and possibly WWVB) are likely be around at that time!

In perusing the manual for this clock I did note that it mentioned that it would not properly display the years past 2020, restarting at "01" again to represent 2021, but nowhere else did it mention that there would be a time at which it would stop working properly well before then.  Clearly, they did expect the clock to work past 2020, so, what is the problem?

My guess is that it may have something to do with the display that shows the phase of the moon.  I'm guessing that it uses either a lookup table or a simple counter based from a past date to determine the (approximate) phase of the moon:  It would only need to be approximate since it has the capability of showing just 8 possible lunar phases so an error of a couple of days would likely go unnoticed.  Perhaps it's now "hanging" somewhere when trying to determine the phase of the moon and then never resolving some sort of logical condition and therefore never again - until power-cycled - be able to get the time from its receiver and setting itself to the current time.

The other possibility is that these clocks "break" when doing the "Day-of-Week" calculation, but this needs to be researched further.

Over what dates will these clocks function properly?

I have yet to nail down the precise range of dates over which these clocks will function properly as it is a bit of hassle to do this, but I've narrowed it down to at a period of least March '99 to June August '12.  I am quite certain that these clocks will not function "prior" to March, '98 and "after" November '12, but further narrowing the dates would require more work and the question is only academic, anyway.

If one were to "modify" the dates reported by these clocks using one of the techniques mentioned below, these limitations would have to be kept in mind

Note:

Again, these clocks do not "know" about the century as only the last two digits of the year are used in the WWVB time code.  If, for example, they are known to work from "March '99 to June '12" that means that they will function from March 1999 to June 2012 or March 2099 to June 2112 (and so on) - if they last that long and there is a suitable 60 kHz signal available to which they can synchronize!  What will probably not be correct is the day of the week and the phase of the moon for any time other than the 1999-2012 time frame.

What can be done about it?

Other than pointlessly complain to the manufacturer of the clock (they are long since out of warranty!) there's probably not much to be done!  One of the advantages of these clocks is that one is supposed to be able to attach them to the wall and forget about them and doing anything else to "fix" them would probably go against that notion.

In case you were hell-bent on making them "work" again, perhaps you could:

• #1  Include a low-power microcontroller to force a reset of the clock every few days so that it would re-synchronize itself.  In theory, this computer could monitor the receiver's data line and set itself to the WWVB time and then keep its own time, resetting the clock portion at, say, 1 AM.  The problem with this is that any time zone offset (other than the default U.S. Eastern time) and the customization of the display (e.g. 12/24 hour time, display of different parameters like the second, temperature, date) would be lost.

Or

• #2  Have a small microcontroller intercept the time code from the receiver and change the year to one during which the clock works properly.  By selecting a year in which the calendar lines up with the current year's days of the week, one could make the clock usable - although it is likely that the moon display will be incorrect.  (The clock doesn't normally display the year, anyway, so that shouldn't be an issue!) 

Or

• #3  Many of these clocks can be forced to resynchronize their time by pressing one of their buttons.  While this particular model doesn't have this feature there is a sequence of buttons that one can press (related to the manual setting of time, I believe) that may force it to reacquire the time signal.  If this is the case, a small microcontroller could do this or, possibly, a simple circuit attached to the alarm piezo buzzer could do this same thing:  Setting the alarm for, say, 12:30 AM (with the beeper disconnected) may cause it to try to re-synchronize every night.  If, in fact, the on-board WWVB receiver circuit is being activated normally, it should be possible to use that as a trigger for the added microcontroller to "press the buttons" and force the clock to reset itself.

Or

• #4  Generate your own local 60 kHz WWVB signal for the clock, but "lie" about the date!  A PIC or Arduino-based device should be able to intercept the time from a cheap GPS (or WWVB receiver!) and generate a suitable 60 kHz signal to which the clocks could lock:  As with #2 above, you could pick a year in which the days of the week and the calendar days line up with the current year!

Of the above possibilities, #2 one is that which is most likely to be practical as one could, in theory, insert this simple circuit into the clock. 


The answer to the question "Did the NIST break the clocks?":
 
So yes, the NIST did break the clocks - but only by sending out the correct date and time, so it's not really their fault!  It would seem that these clocks were "pre-broken" for dates beyond some time in the fall of 2012 when they left the factory!

It is NOT due to the format change (the addition of a BPSK component) of the WWVB signal that has caused these clocks to fail to synchronize:  The folks at NIST are just unlucky to have changed their WWVB format at about the same time that these clocks' hardware has become unable to properly process the date!

Are there other model clocks with this same problem?  Probably, but since only my SkyScan 86715's have this issue - and my other "SkyScan" clocks don't - I can't say exactly which ones have a problem.

In researching this issue on the Internet, I came across this page from the makers of this very clock:

http://skyscanatomicclocks.com/site/help-my-86715-86730-87315-is-not-catching-the-signal/  link

On a previous version of this page they suggested that it was the NIST itself that, in changing their format, might have caused the problem - but we know differently now, don't we!


Again, the ACTUAL problem with these clocks is that there appears to be a bug in their own firmware/hardware that causes them to lose the ability to re-synchronize themselves on their own, a problem that appears to have manifested itself some time in mid/late 2012.



A couple of noted "quirks" with this model of clock:

This particular model of clock - the SkyScan 86715 - has a number of "quirks" that I've observed over the years that other other radio-controlled clocks that I have do not seem to exhibit:

• A day late with the spring time change.  These particular clocks - when they still worked - would be one day late with the spring time change.  Apparently, they didn't properly look at the "DST Pending" bit in the time code and change themselves at 2AM like the other clocks that I have.  Oddly, they didn't have the same problem (going the"other" direction) in the fall!

• When set to display UTC, they would synchronize at UTC "Midnight".  One nice thing about these particular clocks was that they can be set to display UTC where not all of my other radio-controlled clocks have this option.  The only problem with this (when they still worked) was that they would attempt to synchronize every hour, on the hour from 1 AM through 6 AM in the time zone selected.  What this meant was that if you set them to display UTC they would actually try to synchronize in the late afternoon/evening in North America when there was likely to be more interference from computer monitors, electronic lamps (e.g. CFL's) and televisions.  Fortunately, the WWVB signal at this location (Utah) is quite strong and they would usually be successful.

A note about how these clocks synchronize themselves:

I've had these clocks for over a decade and soon after installing the battery, I can see them setting themselves with a rather odd looking display, but I never really attempted to figure out what was going on.  During this projected, I paid more attention and observed that it provided quite a useful tool.

Here's what seems to happen during the initial time and date setting process:

• The clock will display "0:00", but the first zero (the units of hours) will change between "0", "1" and "8".  It would appear that the clock is waiting for the marker bits at seconds 59 and 00 so that it "knows" where the timecode frame is to begin.  After first "seeing" the two back-to-back marker bits, it waits for the next minute for them to appear again before starting to "download" the time code.
• After at least one minute, the "minutes" digits will start counting up, 00-59, with the hours digit showing "0", "1", or "8".  The "0" indicates a "zero" bit in the received time code while the "1" is a binary "one."  The "8" represents one of the marker bits that is sent to help the clock synchronize the framing of the time code that it is downloading.
• The clock seems to download two full minutes of time code - and then it seems to stop downloading again, waiting to synchronize itself to the marker bits at seconds 59 and 00.  This usually seems to take two minutes or so.
• It then downloads two more minutes of time code, perhaps to do another "sanity check" to make sure that the time that it already had the first time that it set the clock matches the time that it just received.
• If everything matches, the clock sets itself to the current time.
• In the next minute or so, the "Phase-of-the-Moon" indicator will finally update.

These clocks will attempt to set themselves on the hour between 1 AM and 6 AM, but it will stop doing this as soon as it gets the correct time.  Since the clocks don't generate this same diagnostic feature when they update, I don't know if it's internal process is the same as above:  My guess that it first spends 1-2 minutes synchronizing to the 59-00 second marker bits and then downloads two minutes of time code.  If these two minutes match, it will reset itself to the newly-updated time.


Minor update:

I received an email from someone whose LaCrosse clock had been failing to update properly - at least until the beginning of Standard Time in November 2013:  After this point, they seemed to be working again.


Hopeful that my SkyScan clocks would do the same, I pulled the battery from each and allowed them to reset.  Alas, the problem persists in that they won't continue to update their time after the initial synchronization.

What would be interesting would be to know if the LaCrosse clocks will continue to work after the end of standard time in early 2014?

[End]

This page stolen from ka7oei.blogspot.com