Other than WWVB-based frequency references/clocks that lock onto the 60
kHz carrier itself, I'm not aware of any WWVB-based clocks that were the
slightest-bit affected by format change (e.g. the addition of the
low-rate BPSK): Please point me to any references to the contrary if
you find them.
Co-incident with the WWVB format change there were a number of WWVB
clocks that quit working - namely, a few of the older "SkyScan" models,
but this had nothing at all to do with the format change, but rather an
error in the silicon that caused them to fail to automatically set
themselves (after initially doing so when first powered-up). For WWVB,
the timing of the manifestation of this bug was most unfortunate and
there is/was quite a bit of information on the net that continues to
propel this myth.
Being a bit of a nerd and Time Nut I went out of my way to determine the
actual cause of this problem.
There is this:
http://ka7oei.blogspot.com/2013/02/did-nist-break-bunch-of-radio.html
In this, I determined that at least with this receiver, its detection
bandwidth was far too wide to be adversely affected by the phase
reversal which - in theory - could skew the timing of the recovered
amplitude waveform of the time code modulation. From this I concluded
that the TRF receivers used by these inexpensive clocks weren't likely
to be affected in the least by the BPSK.
And secondly, there is this:
http://ka7oei.blogspot.com/2013/03/yes-nist-did-break-bunch-of-radio.html
In short, I created my own, local WWVB signal and demonstrated to my
satisfaction that the real problem with these particular clocks was that
they couldn't tolerate dates beyond a certain range. A shame, too,
since these same clocks will happily display UTC with no DST - although
they would sync at "Midnight" and early morning for their set time zone
which means that they would sync during daylight hours: Not a problem
here in Utah where we have mV/m signal levels, but it could be
disastrous for stations farther east where usable signals are available
only in the wee hours of the morning! (These clocks also had a bug that
would cause them to delay a day during the spring change onto DST -
disconcerting on the morning of the time change if it was set to local
time with DST!)
73,
Clint
KA7OEI
Wouldn't that be nice!
They implement a new format which destroys much of the installed
infrastructure, then don't actually produce the 'better replacement'.
How very LORAN!
-John
_______________________________________________
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.
