home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / time / ntp / 865 < prev    next >
Encoding:
Text File  |  1992-09-03  |  2.8 KB  |  63 lines
  1. Newsgroups: comp.protocols.time.ntp
  2. Path: sparky!uunet!UB.com!quack!mrapple
  3. From: mrapple@quack.sac.ca.us (Nick Sayer)
  4. Subject: Re: Accuracy problems on the Heathkit clock
  5. Message-ID: <fR8Pqm#@quack.sac.ca.us>
  6. Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
  7. References: <Sep.2.11.39.26.1992.26046@turbo.bio.net>
  8. Date: Thu, 3 Sep 1992 19:54:24 GMT
  9. Lines: 52
  10.  
  11. shibumi@turbo.bio.net (Kenton A. Hoover) writes:
  12.  
  13. >At some point in time, there was some discussion about how Heathkit clocks
  14. >made poor sources for chimers.  I just recieved the technical manuals for the 
  15. >new Motorola 6-channel GPS core receiver.  The interface on it maxes out
  16. >at 9600 baud, and I was trying to figure out if it would suffer from the
  17. >same problems as the Heathkit in terms of accuracy.  Would someone care to
  18. >summarize the reason for the Heathkit's problems?
  19.  
  20. They pretty much boil down to two things:
  21.  
  22. 1. There is no point in the RS-232 timecode that is an official
  23. "on-time" mark. At 9600 bps, the 20 characters (or so) in the
  24. timecode take 20/960 of a second, or about 20 msec.
  25.  
  26. 2. The timecode lacks sufficient granularity. The timecode itself
  27. contains time down to the nearest 100 msec. This wouldn't be so
  28. bad if it was guaranteed to start or end on time, but that is
  29. not the case. The timecode starts whenever it likes within that
  30. 100 msec window. This is the truly damning fault.
  31.  
  32. #define FLAME
  33. Both of these faults were confirmed by technical support personel
  34. at Heath hot-line. They acknowledged that it was not possible
  35. to get 5 ms timestamps from the clock. They said that the clock
  36. was not supposed to be considered a serious tool. I suspect
  37. this sort of attitude is what did Heath in.
  38. #undef FLAME
  39.  
  40. The moral: The GC-100 can be trusted to about +/- 120 msec. Hardly
  41. the 5 ms they claim. To be fair, it is possible that the clock
  42. internally gets +/- 5 ms, but that isn't terribly helpful.
  43.  
  44. >BTW, the Motorola 6-channel GPS core reciever eval kit will cost $1200.00
  45. >and will be available in November. 
  46.  
  47. Most reasonable clocks define some point within the timecode at which
  48. the time given by the timecode is accurate. For example, CHU timestamps
  49. are on-time at the end of the last stop-bit in the code. Some other
  50. systems send a garbage character and use the begining or end of a
  51. particular bit in that garbage character to signify the point at
  52. which the next (or previous) timestamp is in effect. You can then take
  53. a local clock reading of what time your system THINKS it is when that
  54. bit has arrived, then compare that stamp with the time that the
  55. bit in question represents and thus get a good difference between
  56. the standard and your local clock.
  57.  
  58. -- 
  59. Nick Sayer <mrapple@quack.sac.ca.us> | 
  60. N6QQQ @ N0ARY.#NOCAL.CA.USA.NA       | "Leave everything to me!"
  61. 37 19 49 N / 121 57 36 W             | 
  62. +1 408 249 9630, log in as 'guest'   |     -- Powdered Toast Man
  63.