jgd@rsiatl.UUCP (John G. De Armond) (01/13/90)
In article <3230@psivax.UUCP> torkil@psivax.UUCP (Torkil Hammer) writes: >In article <1990Jan10.175719.8720@haven.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: > >#As far as the Heathkit "Most Accurate Clock", well, its not. The >#RS-232 interface has some severe problems which precludes its >#effective use to those persons that want accuracy in the millisecond >#regime. If you're looking for somethat that's accurate to within a > >Could you elaborate on this? It seems from the Heathkit specs that >all what it amounts to is a fixed and predictable time difference between >displayed time and the leading edge of the RS232 output, which can be >compensated for in the computer - e.g. by waiting for the minute interrupt >and then setting the clock seconds to 1.3 or whatever it amounts to. The problems with the Heath RS-232 interface are many. At the top of the list is the protocol they chose to implement. The protocol is as follows: To strobe a time value, you toggle a handshake line (RTS?). Sometime after that, and supposidly starting exactly when the data represents a valid time, the time is sent in ascii format. Since the time was valid at the START of the transmission, the following things affect the accuracy of the time as finally recorded on the host: The latency internal to the clock. The short term stability of the el-cheapo baud rate oscillator in the clock. The latency from receipt of the stop bit to generation of the interrupt in the host uart. The short term stability of the host uart baud rate generator. The interrupt latency stability of the host. The variability of the delay in transmitting the characters from the to the user process. The correct way to implement this is the following: Host strobes a data request. Clock sends a time value valid one or 2 seconds in the future. When the actual clock circuitry determines the transmitted time is valid, it (the clock circuit) strobes a "data valid" line which could be another handshake line. Host assigns a high priority to servicing this strobe. Another problem, which probably swamps all others is that even in the strobed mode, the start of data seens somewhat unrelated to the actual second intervals. I have observed this on my clock by hooking a dual trace scope to the clock and observing when the tick occurs relative to when the data starts. According to the reprint of the NBS specifications for the IRIG code used to encode the time, the leading edge of the tick is the marker for the seconds boundary. The clock is pretty handy, though, for setting your watch. :-) And I have it interfaced to this system and set the system clock with it 4 times a day. (you can guaran-damn-tee that the timestamp on this post is actually when I wrote it :-) John -- John De Armond, WD4OQC | The Fano Factor - Radiation Systems, Inc. Atlanta, GA | Where Theory meets Reality. emory!rsiatl!jgd **I am the NRA** |