mrapple@quack.sac.ca.us (Nick Sayer) (06/05/91)
Lately I've had far too much time on my hands, and to alleviate it, I've ordered an MC68HC11EVB to play with (and started a mailing list on the subject, but never mind). Well, this chip is just the thing to watch the output of my CHU modem and generate an LED time display along the lines of what the Heath clock did before I unplugged it in disgust (it's for sale, btw). Well, while it's generating an LED display, it could very well be providing RS-232 output in a far more clean fashion than the raw CHU data. Thinking about this has led me to the idea of generating the most helpful format for RS-232 data, making it do that, and maybe selling it. I'd like comments from you folks on this format. Unfortunately, CHU only gives day-of-year and time-of-day. That sort of limits what can be done. Additionally, to make my job easier, the format ought to take no more than 400 msec or so to transmit. The idea is that the format will be sent sometime after 500 msec before the begining of the second, then a mark sent such that the begining of the start bit "hits the post". 400 msec at 9600 baud is a lot, as it turns out. One of the mistakes the Heath clock makes is that the output varies with the whims of the dipswitches. Another is that you can't tell from the output how trustworthy the time is. So... ddd hhmmss Stt.t xxxx yyy *\n | | | | | | | | | | | +--- Sent at the begining of the second | | | | +------ "trust" index 000-999. like ntp's disp. | | | +---------- Number of minutes since last frame decoded | | +---------------- timezone S=sign, t=hours from UTC | +---------------------- time UTC +---------------------------- day of year I think a sensible thing would be to have the clock set itself anytime it gets a valid frame (valid meaning it would pass the "anal_retentive" processing of the recently posted kernel CHU module), and set the trust index to K*dif, where K is a constant, and dif is the difference between the clock and the frame. Additionaly if the difference was less than some other constant amount of time, the clock "tick" value would be adjusted a little. I'm thinking of a clock granularity of 100 usec. Any comments? Would anyone port some xntpd support for this? Would anyone buy it? Anyone want to help? -- Nick Sayer | Official Scapegoat for the | RIP: Mel Blanc mrapple@quack.sac.ca.us | MC68HC11 Mailing List. | 1908--1989 N6QQQ | To subscribe, send mail to | May he never 209-952-5347 (Telebit) | mc68hc11-request@quack.sac.ca.us | be silenced.