Almost Accurate Clock

dmr at research.UUCP dmr at research.UUCP
Sat Sep 29 17:23:49 AEST 1984


Here's a long story on the clock that has been mentioned here.
I wrote it a while ago; there's an addendum on recent experiences.
---
A few months ago we bought the Heath "Most Accurate Clock" (model GC100),
partly as a toy, partly because we wanted to keep a network of 20-odd
machines on a single time standard.

The clock has an optional RS232 interface that emits the current date
and time about once a second, to a precision of .1 second.  It claims
the title "most accurate" because it listens to WWV, the radio station
maintained by NBS, and if all goes well, it should indeed be able to
keep a time standard accurate to a few milliseconds.  WWV sends a complicated
signal that includes seconds ticks, and over a period of a minute,
a BCD encoding on a 100 Hz subcarrier of the day of the year,
the hour and minute, the difference between UTC and UT1 (i.e. how much the
earth has slowed down recently).  The clock decodes all this and sets itself
accordingly.  When it can't hear WWV it uses an internal crystal oscillator,
whose frequency it trims whenever it resynchronizes.

It sounds very neat in the ads.  Here's an account of what we discovered
in practice.

1) In a steel building on the East Coast in a radio-noisy neighborhood,
you can't hear WWV well, so we constructed an antenna between
two of the towers on the roof.  We now acquire an acceptable signal
throughout most of the day.  Because there is no builtin battery backup,
power dips mean that the clock is inoperative until it reacquires WWV.
(There is a 12V DC input; it pulls 750 ma with the LEDs on.  Heath
suggests car batteries.)

2) That big antenna is excellent at collecting the atmospheric electrical
field.  The first time the clock broke, we just sent it back, assuming
infant mortality.  During a subsequent thunderstorm, the disconnected
end of the antenna was observed arcing to the steel wall, but we foolishly
assumed that Heath would know about such things.  The day after the clock
returned, we saw it die again during another thunderstorm,
and finally got smart.  The antenna is now isolated by a collection of
inductor shunts to the building frame and series mica caps.

3)  When synchronization with WWV has not been achieved recently,
the clock listens for three successive minutes and checks the data
received for consistency.  The check is not strong enough.  On two
occasions, the time has jumped for a while, and then been reset.
One jump was +1 minute, another -2 minutes.

4) There is some sort of bug in the crystal-trimming algorithm.
We have a frequency counter attached to the 3.6 MHz signal it puts out.
Most of the time it is off by about +/-10 Hz (.24 sec/day).
On many occasions in several months the difference has suddenly increased to
+140 Hz, enough to drag along the time maintained by the network machines
quite visibly.  It resets itself the next time it acquires WWV,
but if it can't hear the radio the drift is painfully evident.

5) The time emitted from the RS232 interface lags WWV and the displayed time by
almost 1 second.  We can only assume that this owes to slow computation
in the RS232 microprocessor (it's not network delay or time to put out
the characters serially).

6) There is a silly bug in the date conversion.  WWV transmits
day number, the clock gives you month and day. It has switches for
the year so it can handle leap year.  Unfortunately it converts June 30
to July 0.  Subsequent month ends have been OK.

7)  It has problems, but may be worth buying.  It has taught us
something about vaxen, too.  For example, a microsecond seems like
a short time.  But if you always load the interval timer with a constant
value, and take clock interrupts at 60 Hz, you have a choice of using
16666 or 16667 microseconds, so with a perfect crystal and no lost clock
ticks you either gain about 1.7 seconds or lose about 3.4 seconds per day;
those fractions of a  microsecond add up.
In practice the vax clocks are often worse than one would expect
from garden variety crystals.  For example, the TOY clock on one of our 780s 
runs about 5 sec/day slow (this is the hardware clock, not the interval
timer). You would think the crystal in a temperature-stable computer would
be more accurate than the one in a $15 watch, but it isn't.

Addendum:

I wrote a letter to Heath with the information above.  I got back
a detailed and responsive reply.  It admitted they should have been
more specific about lightning/static protection and promised to send
some resistors and diodes to improve the front-end protection
(which we got, along with schematics.)  It claimed that the
time-jumps were caused by static and would be alleviated by installing the
network.

The reply also admitted to July 0 and bugs in the trimming algorithm;
it promised to send new microprocessors.  We got one new chip, but
the part number stamped on it wasn't the same as any in the clock
so we didn't know where to install it.

Before we put in any of the new parts, the clock went belly-up on its own,
rather than as a result of lightning.  We took all the parts sent,
all the letters, and the clock corpse to a Heath service center
and commanded them to cope.  It hasn't come back yet.

Despite the problems, this is a fun toy.  It breaks a lot and is quirky,
but it can be useful.  Heath seems to understand most of the problems;
I hope they fix them.


	Dennis Ritchie



More information about the Comp.unix.wizards mailing list