Someone pointed out a typo: I wrote model number "86716" where I meant
to write "86715" for the SkyScan clock in question. In the linked web
pages it is correct, however.
73,
Clint
KA7OEI
Clint Turner wrote:
A few weeks ago I posted a question/comment about some of my
WWVB-based "Atomic" clocks no longer setting themselves properly.
These two clocks, SkyScan #86716, would show the symbol indicating
that they had set themselves, but their time was drifting away from
UTC. Interestingly, they *would* set themselves exactly once upon
installation of the battery, but never again.
Since that time, I've done a bit of digging around.
The first suspicion was that, perhaps, the NIST had fudged a bit in
the WWVB timecode recently, so I manually decoded a few frames and
analyzed them: Nothing suspicious there.
The next question was if the addition of the BPSK somehow skewed the
timing of the TRF's AGC/threshold - but logically, this didn't make
sense since the clock *did* set itself exactly ONCE - and it wouldn't
have been able to do this at all were this the case. Out of curiosity
I poked around on the board and found the trace containing the time
code and found that despite the BPSK, its timing was exactly as it
should have been: No surprise there.
This left the clock itself, so I did what any other Time Nut would
do: I built a WWVB simulator.
Initially, I set it to a 2010 date - a time that I knew that the clock
worked properly. I had two clocks: One that I'd just reset by
pulling and replacing the battery while the other had been "stuck" for
a few weeks, not resetting itself nightly as it should. I put both of
these in the coupling loops from my WWVB simulator and over the next
few days, the recently re-set clock happily synchronized itself while
the other one with the 2013 date was still "stuck." I then reset that
clock and it, too, behaved itself from then on.
I then reset the clock on the simulator to a February 2013 date and
time. Initially, both clocks reset themselves to the current time and
date at their next midnight, but after that, they got "stuck", never
resetting themselves at "night" again.
So, it appears to be a problem with "Broken Sand" (e.g. a silicon
problem).
For the morbidly curious, I have documented my efforts here:
http://ka7oei.blogspot.com/2013/02/did-nist-break-bunch-of-radio.html
- The initial testing
http://ka7oei.blogspot.com/2013/03/yes-nist-did-break-bunch-of-radio.html
- The testing with the WWVB simulator
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.
