A (simple) WWVB loop amplifier for radio-controlled clocks

Note:

The techniques described below should work - with only minor adaptation - for any "Longwave" time signal used by these radio-controlled (non-GPS) clocks - not only WWVB, but DCF77, MSF, BPC and both JJY signals as well.

* * * * *

Last year I moved a bunch of SDRs (KiwiSDRs, RTL-SDR) and a bunch of network gear to a new shelf in my shack, but this placed them much closer to the wall on which I'd previously mounted the two "Atomic" (e.g. radio-controlled) clocks which had been there - and operating - for years.  Since then, they hadn't been able to reliably synchronize to the 60 kHz WWVB signal out of Fort Collins, Colorado.

Figure 1:
The two radio clocks surrounded by
the four-turn loop, near a number of
pieces of "noisy"equipment.
The top clock is set to UTC and
the bottom for local time.
Click for a larger version.

While annoying, I wasn't terribly surprised.  There are several switch-mode power supplies involved in the aformentioned gear and it's not uncommon for them to operate in the 30-60kHz range, offering the potential of "jamming" the receivers.  As both the location of these clocks - and the nearby gear - is convenient, I wasn't too inclined to move them again and initial efforts to "filter" the switching power supplies didn't really help - but I wasn't surprised about this, either, since it's likely direct coupling of their magnetic fields that is the culprit rather than any electrostatic field as the clocks themselves use ferrite loopstick antennas sensitive to just the H-field.

A solution

Many years ago a friend came to me to solve a similar problem in a downtown Salt Lake office building where the WWVB clocks in a conference room never synchronized and I constructed the remote loop and amplifier/coupling system, described here:

• Getting "Atomic" (WWVB) clocks to work indoors and in weak signal areas - LINK 

In short, a rooftop loop antenna amplified the signal and it was conveyed into the room with the clocks where it was further amplified and then, using inductive loops placed in the proximity of the clocks.  This is how the WWVB signal was coupled to them.  To my knowledge, this system worked for many years (well over a decade) and for all I know, it may still be in use.

 Why revisit?

I've tackled this type of problem before - but I decided to revisit it as the circumstances are slightly different:  I already had a signal source as noted below plus I wanted to see if I could do this with more commonly-available components in a simpler manner.

While I don't have a WWVB loop on my roof, I do have a dedicated LF E-field whip antenna - a 40 year old LF Engineering LF-400B with integrated low-pass filter.  This antenna has been on the roof wherever I have lived almost continuously since I purchased it in the mid-late 1980s and with a few repairs over the years, it still works well, having been on the roof of my current house for several decades.  Its use for LF reception as described on the following page:

• A (semi)-typical suburban E-field whip receive system for the 630 and 2200 meter amateur bands - LINK 

The fact that I already had an LF/VLF receive antenna system meant that I had a "clean" source for WWVB, and other devices that receive signals below 500 kHz (e.g. LF receivers for 630 and 2200 meter operation and my Blitzortung "Blue" receiver) and I decided to add one more to the list.

Other types of outdoor antennas 

Note that the circuit described here should work well with other types of active antennas including E-field types such as the PA0RDT "Mini-Whip" and the DX Engineering ARAV3 - to name but two.  An amplified loop such as the Wellbrook and similar will work, provided that it is not oriented such that the desired time station's transmitter is not in its nulls.

Buffer/Amplifier

Through back-of-the-envelope calculations I figured that the already-amplified signal from the active whip needed another 15dB or so of boost and it could then be applied to a loop of wire around the WWVB clocks on my wall.  One thing that helps greatly is that the WWVB signal is extremely strong here in northern Utah - on the order of 5mV/meter or so - and connecting an oscilloscope to my LF-400B whip's signal output showed that the amplitude-modulated time code of the 60 kHz signal from WWVB was visible among the many others.

What I needed to do was to tap off the signal (e.g. "bridge" the connection) from the existing coaxial cable without affecting was was being sent to the other devices using it, amplify it. and apply it to the loop - and I did this "tap" using a BNC "Tee" connector on my antenna feed.

The circuit diagram below gives more details:

Figure 2:
The schematic of the loop buffer/amplifier/driver showing the isolation from the power supply
via L1, the buffer circuit of Q1 and the amplifier and loop driver of Q2.
Click on the image for a larger version.

Circuit description

Of high importance is L1, a common-mode choke, liberated from a failed switch-mode power supply somewhere.  This particular unit has an inductance of about 1mH per winding meaning that it has about 377 Ohms of impedance at 60 kHz and helps to prevent a ground loop and the coupling of noise from the power mains.  If you replicate this circuit I would strongly suggest that whatever you use for L1 have at least a similar amount of inductance.  On either side of L1 are electrolytic capacitors (C1, C2 - preferably of low ESR types) to offer low impedance and a degree of reinforcement of common-mode rejection through L1 while C2 and C3 provide RF bypassing for the circuit itself.

A buffer amplifier consisting of Q1 - with a high-impedance input, but no actual gain - couples the signal from the existing antenna:  Having several k-Ohm of input impedance, it is unlikely to appreciably load the existing antenna system.  On the feed from the E-field whip, I simply installed a coaxial "T" connector to allow me to bridge across the signal feed rather than split the signal, which would have been complicated owing to the fact that the DC power for the whip was also being carried on that same cable.  The connection to the amplifier in Figure 3 was made using a very short piece of coaxial cable (about 2 feet long - less than a meter) and since this whip is not used for reception above about 500 kHz, neither its presence or that of the added amplifier had any discernible effect on the other received signals.

Coupling from the existing antenna are series components L2 and C4, selected to resonate at about 60 kHz:  The resonance is extremely broad, so finding a capacitor combination precisely equal to the "ideal" value of C4 - according to the formula below actually calculating as 0.007uF (7000 pF) - is unimportant.  This series resonant circuit is probably not essential and a simple coupling capacitor of 0.01uF (10000 pF) could be used (omitting L2 entirely) but I chose built it with L2 to broadly filter off-frequency signals - something that might be important if your E-field whip antenna doesn't have a low-pass filter to remove AM (Mediumwave) signals as mine does as well as to block any stray coupling of HF signals when I transmit.

Figure 3:
The circuit of Figure 2 built on a piece of prototyping board
in the case.  Bifilar choke L1 is on the right with the BNC
connector (J1, input) and output to the loop (J2) on the left.
Click on the image for a larger version.

The buffered signal from Q1 is then passed to amplifier Q2 which is configured to have "about" 15dB of signal gain.  This circuit is, perhaps, slightly more complicated than it needs to be, but with its feedback, it is very stable and tolerant of large signals.  The use of electrolytic capacitors for C5 and C6 is, perhaps, overkill (0.1uF ceramic would probably suffice) but I used them as they were handy.

As the signal from WWVB is quite strong at this location, there is only one stage of amplification shown in Figure 2, but if I lived more distant, greater overall system gain might be required.  Replicating the circuit involving Q2 (R4-R8, C5-C6) and cascading it with the existing amplifier would add yet another block of gain to boost the absolute signal level - but this would presume that whatever active antenna you were using outdoors to pick up the WWVB signal was working well, providing a "clean" signal and that the deficit was just in signal strength at the clocks rather than than signal-noise ratio.

Due to the smallness of the project box that I chose I couldn't mount the bifilar choke "through" the prototype board so it was mounted on the edge to minimize height.  To hold it in place I used UV cured resin along the edge to prevent it from breaking the pin connections mechanically:  UV cured resin is very handy as it's about a strong as epoxy, but it is cured almost instantly meaning that it's able to be handled immediately.  For the BNC connector, the one that I found in my parts bin didn't have its matching mounting nut, but more UV-cured epoxy did the job for that, too!  As can be seen in Figure 3, I didn't bother "mounting" the board in the box, letting it hang about on its own wires.

Indoor Coupling loop

The "coupling loop" - visible in Figure 1 and shown on the schematic - is just a loop of wire - and it is used to inductively couple the signals from the outside antenna to the clocks.  In my case, I measured a rectangle that would encompass both of the wall clocks and found a cardboard box with similar dimensions and on it I wound four turns of 22AWG hookup wire.  Connecting this loop to the amplifier, I used some shielded microphone cable:  Coaxial cable would have been fine as would just some single-pair speaker wire as this frequency is not all that much higher than audio!

Neatly forming the individual conductors, I used small "zip" ties to hold them together and with four screws, attached it to the wall, placing the clocks inside the loop of wire.  Within the loop, signals from the amplifier would be strongly coupled into the ferrite loopsticks in the clocks themselves - but being very small in terms of the 60kHz wavelength, this loop is unlikely to radiate more than a few feet/meter outside it.

To improve efficiency of the coupling loop I wanted to series-resonate it at around 60 kHz as this would increase the amount of energy transferred to the loop from the amplifier somewhat, effectively providing "free" signal gain.  Measuring the inductance of the loop I found that it happened to be about 22uH and using this simple formula, I calculated the value of C7 - the resonating capacitor in Figure 3:

LC = 25330/(F_MHz)²

Where:

LC is the product of the inductance and capacitance (e.g. Capacitance in pF * Inductance in uH)

F_MHz is the desired resonant frequency in MHz (e.g. kHz/1000)

Knowing that we have 22uH of inductance in the coupling loop and a frequency of 60 kHz (0.06MHz) we end up with "LC" being equal to 7036111.  Dividing this value by the known inductance of our coupling loop (22uH) we get  the capacitance, as in (7036111/22) = 319823pF, or 0.319uF.

Figure 4:
The finished amplifier in its box, hanging
out below the loop - connected, and in
service.  (It's just visible in the bottom
of Figure 1)
Click on the image for a larger version.

As 0.33uF (330000 pF) is the closest common capacitor value, I used that for C7.  Again, as with C4 and L2, the resonance is very broad and precision isn't too important.  The article linked near the top of this page goes into more detail on how one would construct and resonate a coupling loop.  Based on this formula, if I wanted to resonate the same loop for use with DCF77 at 77.5 kHz I would have picked a 0.18 or 0.2uF (180000 or 200000 pf) capacitor, instead.  Similar changes could be made to accommodate longwave time signals on other frequencies (e.g. 40 kHz, 50 kHz, 68 kHz).

The formula above can also be used to calculate the value of C4 with the 1mH (1000uH) L2 inductor:  If your interest was for another frequency, such as DCF77 at 77.5 kHz, C4 would be 0.0047uF (4700 pf), instead.

It need not be said that this loop should not be placed very close to whatever outdoor receive antenna you are using - but more than about 10-15 feet (3-5 meters) should suffice:  If they are too close to each other, feedback (oscillation) could occur - but as this loop is only around 0.01% of a wavelength in circumference it does not radiate efficiently at all - and since it's inductive, its signals won't efficiently couple to an E-field antenna, anyway.

In the diagram, C7, the resonating capacitor for the coupling loop, is shown at the amplifier - but it could have been placed at the loop itself.

Power supply  

First off, do not use a switching power supply for this device!

As noted, common-mode choke L1 was used to "decouple" the power supply from the amplifier - and also from the coaxial cable of the LF antenna.  To power this loop amplifier I would strongly recommend using ONLY a transformer-type DC power supply and NOT any type of switching power supply for the simple reason that the switching power supply will be comparatively noisy, and it - its harmonic - will likely operate at/near the frequency of WWVB or whatever time signal you are trying to receive.

This power supply does not need to be regulated:  Simple capacitor filtering with low-ish ripple (a few hundred millivolts) will suffice and any voltage between about 11 and 16 volts will work which means that about any old "wall wart" in that voltage range - regulated or not - would be fine.

Conclusion

Having had the parts on hand it took only a bit more than an hour to piece this together and almost as long to put it in the box seen in Figure 4.

When I forced both clocks to re-acquire WWVB's signal for syncing they immediately set themselves to the correct time and date - and since it had been the start of daylight saving time the night before but had not been able to synchronize prior to this - they "knew" the new, correct time, too!

* * * * *

This page stolen from ka7oei.blogspot.com

[END]

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.