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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
