nsayer@uop.edu (Nick Sayer) (10/10/90)
Heath's "hi-spec" accuracy is +/- 10 ms, and its resolution is 100 ms. That comes from the manual's definition of hi-spec, and the fact that the clock's least significant digit is tenth-of-a-seconds. That's not so good, but the picture gets even bleaker. I just got off the phone with Heath, and they say there is no specification synchronizing the RS-232 output to real time! That is, you're not sure WHEN the data being transmitted is right. It could be right at the begining of the transmission, it could be right at the carriage-return. Given that a bit-time at 9600 baud is about a microsecond, and that it takes about 300 of them to get the message across, that's +/- another 3 or 4 msec. Besides which you're not sure WHERE within the 100 msec resolution you are. The net result is a resolution AND accuracy of 100 msec. Never mind the fact that the time you get is exactly 1 second slow! Well, that makes it a nice conversation piece, I suppose... If one is not happy with that, how tough is it to build a propper WWV clock? If one wanted to keep it simple, would this do: for GEE-173 (uProc sys design -- I'm a college student) we built an 8088 based small system with some ram, some rom, 2 8 bit parallel ports and a serial port (actually an 8256, so it's got some timers and stuff too). If one had the 100 Hz and 1 kHz decode outputs (i.e. a logic 1 when 100 Hz is heard and 0 otherwise), the 8088 can figure out what time it is, probably using the same sort of heuristics the heath clock uses. The difference is that you could provide a sensible RS-232 output. Using the sort of circuitry that heath used (567's for the tone decoders and a normal double-het AM receiver), what kind of accuracy could I get? How about if I keep it REALLY simple and just grab the two decodes straight from my existing heath clock? Let it worry about which signal (5/10/15 MHz) to use, and just piggyback the data. the 8256 internal timers have a basic granularity of 62.5 usec (or 1 msec if you want), but this can be halved with some simple handwaving to 32.25 usec. If this isn't the right group to talk about this stuff, just let me know and I'll be on my merry way. -- Nick Sayer | "Disclaimer? I don't think so! mrapple@quack.sac.ca.us | Homey don't play dat." N6QQQ [44.2.1.17] | 209-952-5347 (Telebit) | -- Homey the Clown
Mills@udel.edu (10/31/90)
Nick, Sorry this is so slow coming. Actually, you can do pretty well with the Heath RS232 directly. I was able most of the time to realize a small few tens of milliseconds using a crafted driver and an LSI-11 fuzzball. The problem was that the clock could sail off into the sunset once it lost hi-spec lock. I have some fancy graphs and other data around here, but buried in some years of dust. From what I observed, the problem is temperature stability of the DAC and VCXO. Undoubtably you could improve on its algorithms by geeping the decoder and doing good in an outboard PC. Dave
wales@CS.UCLA.EDU (Rich Wales) (11/01/90)
Dave -- Regarding the Heath WWV clock, I've noticed more than a few occasions where my clock will "lock" onto a time that is off by a couple of min- utes, or even a couple of hours. Apparently, the clock sometimes misinterprets the time code pulses and inverts one or more bits. This isn't supposed to happen, I gather, since the clock looks at several consecutive minutes' worth of info before acting -- but as I said, on rare occasion it still does this. Yet another reason, I suppose, not to use the Heath clock as a stratum-1 reference. My clock is not being used for NTP, by the way; it's just a conversation piece at my home. It's a fairly early model, so maybe this problem has been fixed in a later firmware version. Rich Wales <wales@CS.UCLA.EDU> // UCLA Computer Science Department 3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683 "The universe is a spheroid region, 705 meters in diameter."
Mills@udel.edu (11/01/90)
Rich, I had an early Heath WWV model, too. The only defect I found obviously due to firmware was an incorrect rollover at the end of the month to day 0, not day 1. Heath replaced the CPU at no cost. I have also noticed the same thing as you - locking to a timewarp, but this happens (less frequently) to WWVB clocks, too. That's why we need multiple redundant, diverse peers. Dave
clements@bbn.com (Bob Clements) (11/01/90)
wales@CS.UCLA.EDU (Rich Wales) writes: > >Regarding the Heath WWV clock, I've noticed more than a few occasions >where my clock will "lock" onto a time that is off by a couple of min- >utes, or even a couple of hours. > > ... It's a fairly early model, so maybe this >problem has been fixed in a later firmware version. Yes, it has. I've never seen my two do this since putting new processor chips in about a year ago, and I often saw it before. Someone on this list told me about the upgrade when I grumbled about the problem. Aha! I've just found the relevant old mail, info correct as of a year ago last June: To: [deleted] Subject: Heath parts Cc: clements@BBN.COM Message-Id: <8906052222.AA00180@k1bc.UUCP> Date: 5 Jun 89 22:22:20 EDT (Mon) From: Bob Clements <rcc@k1bc.uucp> The microprocessor for the clock is Heath part 444-293-1 price $12.25 each. Phones: Ham-radio (knew about the clock) 616-982-3296. Parts orders (charge cards OK) 616-982-3571. Bob, K1BC And there are some fixes in the serial port handling (which uses another copy of the same chip) so you may want to order two of them per clock. Sorry, the details have exponentially decayed in the grey cells. Bob Clements, K1BC, clements@bbn.com