[time-nuts] WWVB Clocks don't sync anymore (revisited)
lists at rtty.us
Wed Mar 20 12:13:14 EDT 2013
Also consider that some of these receivers use a narrowband crystal filter
in front of the IC. I doubt they spend a ton of money on the components, so
that may not be the world's best crystal in terms of aging. If it ages far
enough the receiver simply goes deaf. If it ages a bit less than that, it
slices off one sideband much more than the other. That's likely to do all
sorts of odd things to it's ability to ignore phase modulation.
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
Behalf Of Herbert Poetzl
Sent: Wednesday, March 20, 2013 10:58 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] WWVB Clocks don't sync anymore (revisited)
On Wed, Mar 20, 2013 at 02:34:19AM -0400, Bill S 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 have an analog Lacrosse clock
> that is running correctly. Nothing I've tried will make the
> other clocks synch.
Maybe this is related to the phase modulation time code
protocol used by WWVB since October 29th, 2012.
Their website also states that clocks using information
from the carrier will no longer work, and that during the
transition period (at least March 21st 2013), the PM
signal will be turned for for 30 minutes twice a day
(noon and midnight MST) so maybe check if the clocks
> 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
>> 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, 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"
>>> 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:
>>> k-bunch-of-radio.html>- The initial testing
>>> st-did-break-bunch-of-radio.html>- The testing with the WWVB
>>> Clint KA7OEI
>>> time-nuts mailing list -- time-nuts at febo.com To
>>> unsubscribe, go to https://www.febo.com/cgi-bin/**
>>> an/listinfo/time-nuts> and follow the instructions there.
>> _______________________________________________ time-nuts
>> mailing list -- time-nuts at febo.com To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and
>> follow the instructions there.
> _______________________________________________ time-nuts
> mailing list -- time-nuts at febo.com To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts 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