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

[Clint Turner]

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
>