[time-nuts] WWVB Clocks don't sync anymore (revisited)
lists at rtty.us
Wed Mar 20 12:20:01 EDT 2013
Actually given the way the funding formula probably works (number of mom and
pop taxpayers directly using the service) WWVB is pretty safe. There aren't
very many other NIST services that connect directly to mom and pop.
.... and no, I didn't think up that formula, nor do I believe it's 100% of
the funding story for any program. It is indeed part of it.
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
Behalf Of paul swed
Sent: Wednesday, March 20, 2013 12:03 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] WWVB Clocks don't sync anymore (revisited)
Yes I did seriously try to get the sharp unit going last night no luck at
The Lacrosse seems to be doing well still.
I suspect this is NISTs effort to finally and completely get rid of that
totally non green power sucking LF wwvb. Lets face it those towers are an
eye sore. The property if not burned has more value for houses at least
Besides as we all know the only system needed is GPS. Its always available.
All of the above very tongue in cheek.
On Wed, Mar 20, 2013 at 2:34 AM, Bill S <biltime at gmail.com> wrote:
> 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
> an analog Lacrosse clock that is running correctly. Nothing I've tried
> make the other clocks synch.
> 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
>> 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
>> with the time change.
>> As I say its just becoming apparent.
>> On Tue, Mar 19, 2013 at 4:55 PM, Clint Turner <turner at ussc.com> 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,
>>> *would* set themselves exactly once upon installation of the battery,
>>> 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
>>> since the clock *did* set itself exactly ONCE - and it wouldn't have
>>> able to do this at all were this the case. Out of curiosity I poked
>>> 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:
>>> 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
>>> replacing the battery while the other had been "stuck" for a few weeks,
>>> resetting itself nightly as it should. I put both of these in the
>>> 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
>>> 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
>>> Initially, both clocks reset themselves to the current time and date
>>> 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
>>> For the morbidly curious, I have documented my efforts here:
>>> The initial testing
>>> The testing with the WWVB simulator
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to
>>> and follow the instructions there.
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/**
>> and follow the instructions there.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/**
> and follow the instructions there.
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to
and follow the instructions there.
More information about the time-nuts