On Jan 1, 12:38 pm, Evandro Menezes <[email protected]> wrote: > On Dec 31 2008, 8:49 pm, [email protected] wrote: > > > > > So, basically I'm manually adjusting the nmea second reading forward > > by 1. > > > The SHM(0) gps is still fudged to account for normal lag w/ the time > > given on qnan. Here's my conf with the modified gpsd: > > #Garmin GPS 18x LVC 0 > > server 127.127.28.0 minpoll 4 noselect #Local GPS serial > > fudge 127.127.28.0 time1 -0.420 refid GPSa > > How is this different from leaving the source code intact and fudging > the reference by +0.580? > > TIA
Sorry for the double post, but it's easier to prove via logs too. ntpd.conf: #Garmin GPS 18x LVC 0.520 worked tried up to 0.800 server 127.127.28.0 minpoll 4 noselect #Local GPS serial #fudge 127.127.28.0 time1 -0.420 refid GPSa #to prove positive adjustment doesn't work fudge 127.127.28.0 time1 0.580 refid GPSa #PPS pin server 127.127.28.1 minpoll 4 prefer fudge 127.127.28.1 refid PPSa ntpq -p response: ============================================================================== SHM(0) .GPSa. 0 l 13 16 77 0.000 -79.107 20.795 SHM(1) .PPSa. 0 l - 16 0 0.000 0.000 0.001 navobs1.gatech. .GPS. 1 u 32 64 3 62.163 3.120 0.211 ntp-s1.cise.ufl .GPS. 1 u 28 64 3 67.988 1.296 18.917 See, no PPS output but SHM(0) is about on target. and gpsd (non-modified version) output log --SNIP-- gpsd: pps-detect (DCD) on /dev/ttyS0 changed to 1 gpsd: ntpshm_pps: not in locking range: 627236 gpsd: PPS pulse. cycle: 1000006, duration: 799999 gpsd: pps-detect (DCD) on /dev/ttyS0 changed to 0 gpsd: ntpshm_pps: not in locking range: 627236 gpsd: PPS pulse. cycle: 999988, duration: 199989 --SNIP-- _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
