Philip M. White wrote: > On Sat, May 06, 2006 at 11:15:13AM +0200, Udo van den Heuvel wrote: >> 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) > > This may not be entirely accurate -- the variable 'hitolow' in the > source code of shmpps may be misnamed. Richard Leach implemented this > variable, and here's what he wrote to me about a month ago: > >> Confession: hitolow is my own thing. Somehow I got the sense implied by >> the name back to front. It should really be called lowtohigh, and this >> may be what's confusing you. It surely confused me. Maybe I am still. > > Maybe it is confusing you too. :-) > > Perhaps the variable should be renamed, if it does the opposite of what > the name implies.
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? i.e.: server 127.127.20.0 prefer fudge 127.127.20.0 flag3 1 flag2 0 time1 0.000 flag2 is 0 and there is no time offset compensation. I see stuff like: remote refid st t when poll reach delay offset jitter ============================================================================== 127.127.1.0 LOCAL(0) 10 l 45 64 377 0.000 0.000 0.004 x127.127.20.0 .GPS. 0 l 14 16 377 0.000 -173.72 6.702 (cut) This makes me wonder. It also makes me think that ntpd still triggers on an edge that is allmost 200 ms off, the width of the pulse that I 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? Udo _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
