Interestingly, I have three timepieces that will no longer synch to
wwvb.Two Radio Shack digital clocks and a Casio wristwatch that I've
worn for a couple of years and was always pretty much dead on. Like
Paul, I have an analog Lacrosse clock that is running correctly. Nothing
I've tried will make the other clocks synch.
Bill_S
W2FMA
On 3/19/2013 5:29 PM, paul swed wrote:
Funny you bring this up. I am just noticing a sharp clock that I always use
and it has been accurate. But it did not flip with the time change this
time and though it says its locked its off by 45 seconds slow. Yet a
lacross clock across the room seems to be on second wise but never flipped
with the time change.
As I say its just becoming apparent.
Regards
Paul
WB8TSL
On Tue, Mar 19, 2013 at 4:55 PM, Clint Turner <[email protected]> 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<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<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 -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/**
mailman/listinfo/time-nuts<https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts>
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
