Atomic Clocks
Guy Macon
Roger A. Cope wrote:
>
>Moka Java wrote"
>
>> p4o2 wrote:
>
>>> The other day I noticed that our atomic wall clock was running with
>>> all the hands going round and round and not stopping. I guess it was
>>> searching for the correct time but I am not sure? Taking out the
>>> battery and pressing the button for ET I did it to the right time.
>>> Anyone have this happen?
>>
>> Yes. My 12+ year old RC analog clock has done that a few times.
>> I'm sure it does wonders for battery life.
>
>In my experience such behavior is cured by a brand new battery.
>Usually the old one comes out showing weak values on a meter.
>While the facts might differ as to cause, when I put in a brand
>new battery those kind things stop happening. I've also heard of
>atmospheric conditions affecting the signal, which might scramble
>the program at just the right moment. But too, that could be an
>old wives' tale.
Perhaps I can shed some light on this "old wives' tale" from an
engineering perspective, starting from the basics.
In the continental United States, Radio Controlled watches / clocks
(often called "Atomic") get updates from from radio station WWVB
in Fort Collins, Colorado transmitting at 60 kHz.
This radio station sends out time data at a blazing one bit per
second. That's 56,000 times slower than a 56K modem. In the
middle of the night when radio waves propagate better, the RC
clock sets itself by this signal. In between updates, it is
a normal crystal-controlled digital clock.
It takes one minute to transmit the time data (43 bits for the
data, 7 framing bits, and 10 unused bits). In those 43 data
bits, WWVB transmits the current UTC minute, hour, day, and
year, plus information about leap seconds, leap years, daylight
saving time, and current fractional-second offset between UTC
and UT1. This leaves a few things local that you have to set,
such as your time zone and whether your state has daylight
saving time.
The WWVB signal does not include any sort of error-detection
or correction bits, and like all radio signals reception can
be really spotty and weak at times. This is where people like
me come in; we design the clocks so that they work well despite
possible errors in the time signal from WWVB.
The first line of defense is rejecting any time setting with a
time such as 62:22 or 3:94. Then we reject any time that is
too far off from previous updates. With a crystal that drifts
no more than 15 second per month, a time signal that tells the
clock that it drifted 25 minutes in a single day should be
rejected. The clock usually does several updates per night,
because the signal fades more at certain times in certain
places. A well-designed clock will even correct for any drift
in the crystal (consistently fast or slow). It should be noted
that most of the above techniques are useless the very first
time the clock synchronizes, so it may take a few days for your
clock to settle down and get it right.
So the bottom line is, if your RC clock or watch gets a wrong
setting after working correctly for a while, either it was not
designed well, it is broken, or the battery is going dead and
making the computer go slightly crazy.
As for the the hands going round and round and not stopping,
some electric clock mechanisms can't slow down or stop, and so
must go all the way around the 24 hours to set the clock back.
Even if they can stop the hands, that's OK for setting the
clock back a few seconds, but not OK for setting it back an
hour for DST. The computer should not get stuck in either
hands -stopped or hands-moving-forward-fast modes. If it
does, either it was not designed well, it is broken, or the
battery is going dead and making the computer go crazy.
Those are the basics. If anyone wants to learn more, let
me know so I can bore you with information about radio
propagation delays, relativistic effects on atomic
clocks in GPS orbit, and what happens when time doesn't
increase monotonically.
--
misc.business.product-dev: a Usenet newsgroup
about the Business of Product Development.
-- Guy Macon <http://www.guymacon.com/>