dmr@research.UUCP (09/29/84)
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
henry@utzoo.UUCP (Henry Spencer) (09/30/84)
> 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). The manual we got with ours specifically mentions a one-second delay between "real" time and the rs232 time output. The wording is slightly ambiguous, but a consistent one-second delay is the most plausible interpretation. They don't say *why* the delay is there -- Dennis's conjecture sounds plausible -- but it is (now) documented. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry