gnu not unix wrote: > In message <[EMAIL PROTECTED]> you write: >> Udo van den Heuvel wrote: >>> If the commandline at http://time.qnan.org/ for shmpps really configures >>> for low-to-high (i.e.: rising edge) then why do I see -180+ ms offset >>> for my Garmin GPS 18 with rising edge configured? > (...) >>> So what is the correct way to tell ntpd what's going on? >>> Is there some peculiarity going on? >>> Or am I missing something obvious? > > You are using a TTL (well, CMOS) level signal to drive the > RS-232 input of your serial port. The expected level conversion > that should be done is thus missing. This level conversion also > does a signal inversion.
Ah, this helps explain some of the stuff. > The only thing to care about is that one uses the correct side > of the PPS pulse. The "rising edge" (as seen in the CMOS level > signal) is the proper edge to trigger on. The falling edge > will exhibit the "200ms offset" symptom, along with jitter. So with server 127.127.20.0 prefer fudge 127.127.20.0 flag3 1 flag2 1 time1 0.200 I am indeed using the (inverted) rising edge of the original PPS signal in its TTL form but then I should not need the 200 ms offset time? Thanks, this helps a lot but not 100%. What am I missing further? The only issues I have left are the possibility for compensating the DCD interrupt time of my system, but it looks like this time is below 1 ms? Also there is the situation that ntpd chooses an external clock as the clock to use and marks my GPS clock as a falseticker. (!) How can I fix that? _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
