Adrian von Bidder wrote: > On Wednesday 03 May 2006 20:20, Udo van den Heuvel wrote: >> Hello, >> >> Now that I have PPS from GPS running more or less, could anybody tell me >> what an acceptable time is to compensate for the slowish serial >> interface, etc? >> Should I compensate? >> If so: how? > > I think you'll find the comp.protocols.time.ntp newsgroup (also gated to > some mailing list, but I don't remember where) has some people who are > experts on this.
OK, thanks. I found the serial data does not matter, I am interested in the DCD handling delay. I am slightly confused about the PPS signal on DCD: The Garmin GPS18 LVC manual states: The rising edge of the signal is aligned to the start of each GPS second[...] The NMEA 0183 that follow each rising edge of the PPS signal tell when you were and where you were at that previous rising edge[...] When I consult http://time.qnan.org/ I see a Garmin GPS18 LVC used with shmpps configured for high-to-low rather than low-to-high. (i.e.: falling edge) With shmpps I get a PPS clock that is close (in time) to the remote clocks I see with ntpd. When configuring the local Garmin GPS 18 for rising edge I see remote clocks that are 160-170+ ms off. My local PPS pulse is 200 ms long. My ntp.conf has: (for Generic NMEA GPS Receiver) server 127.127.20.0 prefer fudge 127.127.20.0 flag3 1 flag2 0 time1 0.000 So what is the truth? Was my time off for 160-170 ms in the past? Is it rising or falling edge? Etc. Who understands what is going on and what is wrong, if at all? _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
