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

Clint Turner turner at ussc.com
Tue Mar 19 20:55:17 UTC 2013


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




More information about the Time-nuts_lists.febo.com mailing list