[time-nuts] WWVB Clocks don't sync anymore (revisited)

[Clint Turner]

I found a note on the SkyScan web site itself that attempts to offer an 
explanation/excuse as to why some of their clocks no longer synchronize:

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

This, however, is a BIG red herring.

The ONLY change that was made of any significance was the addition of a 
BPSK component to the carrier.  Fortunately, this occurs at the instant 
that the UTC second begins - when the carrier drops in amplitude - 
which, in the unlikely event that the "ringing" of the filtering in 
these clocks TRF receivers were enough be at all sensitive to BPSK, this 
phase shift would only go toward assisting them in their immediate 
detection of the amplitude reduction of the ASK signal transmitted by 
WWVB.  Certainly, by the minimum time at which the carrier amplitude 
might increase (0.2 seconds for sending a binary "0") the filter has 
pretty much recovered from the effects of the phase reversal.  In 
programming the WWVB simulation, I also found that the clock's timing 
was very forgiving - seeming not to care if the timing of these bits was 
over 100ms out of spec in either direction!  (The fact that the clock 
reliably locked once, after replacing the battery, indicated that it had 
no trouble with the "different" modulation.)

On these clocks I was able to locate the circuit board trace that 
connects one epoxy-covered blob (the TRF chip) to the other (the clock 
itself) and find the demoduated time code which was present after a 
power-cycle.  Even with a fairly poor S/N and the added BPSK, the 
bandwidth of the TRF is wide enough that time code very nicely matched 
what WWVB was sending - albeit that it was offset very slightly in time 
(group delay, etc.)  This was easily determined with a dual-trace scope 
with one channel coming from a strong audio beat note from an LF 
receiver on a good antenna, and the other channel looking at this logic 
line.

As far as any of these consumer-grade clocks are concerned, there is no 
modulation present other than the ASK signal and I tend to believe the 
assertion by the NIST that the addition of the BPSK would be transparent 
to these receivers.

While I don't have an answer for those clocks that flat out refuse to 
acquire a time signal in the first place (again, even my clocks would 
lock exactly once after replacing the battery) it would seem clear that 
these particular units have a problem with their programming in that 
they don't know what to do with the now-current dates.  I've been 
experimenting on the WWVB simulator with different years to try to more 
accurately determine the window during which they work, but the initial 
indications are that the period for which the programming works ranges 
from somewhere in the late '90s to mid-late '12.

As I note on the web page, the 60 kHz WWVB frequency is, unfortunately, 
fairly close to that on which many switching converters operate - or 
near its 2nd harmonic and I've found that having an operating CFL or 
switching "wall wart" in somewhat close proximity can prevent one of 
these clocks from acquiring lock - and this is in an area in which the 
signal's field strength is quite strong, somewhere in the 5 
millivolts/meter range!  In at least one occasion, I've found that a 
non-locking clock could be explained by the recent addition of one of 
these unintentional radiators.

73,

Clint
KA7OEI