George R. Kasica <geor...@netwrx1.com> writes: >On Tue, 30 Dec 2008 09:59:50 -0600, George R. Kasica ><geor...@netwrx1.com> wrote:
>>On Tue, 30 Dec 2008 09:42:06 -0600, George R. Kasica >><geor...@netwrx1.com> wrote: >> >>>On Tue, 30 Dec 2008 07:25:55 GMT, "David J Taylor" >>><david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk> wrote: >>> >>>>David J Taylor wrote: >>>>> Richard B. Gilbert wrote: >>>>> [] >>>>>> I think your best help/advice will come from another GPS18LVC user. >>>>> >>>>> I described my own simple setup here: >>>>> >>>>> http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm >>>>> >>>>> but it's not Linux, and I don't feel competent enough to give >>>>> "advice". It seems likely that the wrong edge is being detected, so >>>>> why not try reversing the polarity? I only use the: 127.127.20.1 >>>>> reference clock, with GPS configured in the kernel. >>>>> >>>>> Cheers, >>>>> David >>>> >>>>That should read: with PPS configured in the kernel. >>>> >>>>The polarity switch is listed here: >>>> >>>> http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html >>>> >>>>as: >>>> >>>>flag2 0 | 1 >>>> Specifies the PPS signal on-time edge: 0 for assert (default), 1 for >>>>clear. >>> >>>OK I've added the >>> >>>flag2 1 >>> >>>to both the GPS and PPS fudge lines and restarted here....so far not >>>much change. >>> >>># ntpq -p >>> remote refid st t when poll reach delay offset >>>jitter >>>============================================================================== >>>xGPS_NMEA(0) .GPS. 0 l 18 16 376 0.000 -635.06 >>>10.323 >>>xSHM(0) .PPS. 0 l 6 16 377 0.000 -628.03 >>>108.161 >>> >>> >>>George >> >> >>Removing the GPS entry from the ntp.conf and taking out the flag2 1 >>items so I'm back to just PPS with shm driver and no gpsd running I >>get almost immediately: >> >># ntpq -p >> remote refid st t when poll reach delay offset >>jitter >>============================================================================== >>*SHM(0) .PPS. 0 l 6 16 17 0.000 1.283 >>1.803 >> eagle-local 192.168.1.7 4 u 8 64 3 0.122 -32.943 >>0.865 >> apollo-local 192.168.1.7 4 u 6 64 3 0.240 -12.200 >>0.630 >>-220962.ds.nac.n 129.6.15.28 2 u 4 64 3 37.344 32.745 >>97.004 >>+mighty.poclabs. 64.202.112.75 2 u 3 64 3 11.679 15.479 >>186.690 >>+splenda.rustyte 192.43.244.18 2 u 2 64 3 47.755 5.733 >>86.910 >> >> >>What am I doing wrong here when I add back GPS data to break this >>thing??? >Next step....I added back GPS NEMA data without the gpsd daemon (I >don't pass the data out to anywhere so there's no real need for it) What does "I added back GPS NMEA" mean? What program did you use to do that? What reads teh NMEA data and passes it on to ntp. >and I see ># ntpq -p > remote refid st t when poll reach delay offset >jitter >============================================================================== >xGPS_NMEA(0) .GPS. 0 l 13 16 377 0.000 -616.37 >10.466 Looks to me like you could get rid of that offset with a fudge. >*SHM(0) .PPS. 0 l 14 16 377 0.000 -0.557 >0.712 > eagle-local 192.168.1.7 2 u 36 64 377 0.153 -44.398 >0.607 > apollo-local 192.168.1.7 3 u 24 64 377 0.250 -16.713 >1.912 >-mirror 209.132.176.4 2 u 29 64 377 10.272 6.391 >135.974 >+tesla.fireduck. 198.82.1.202 3 u 28 64 377 36.123 2.841 >115.565 >+rikku.vrillusio 209.51.161.238 2 u 21 64 377 38.531 -3.260 >156.267 >I have good PPS and am getting GPS NEMA in as well but the offset for >the NEMA data seems quite large....what would I do to fix that?? Use the fudge to get rid of that offset. nmea is very very slow. And I suspect that you are having the Garmin report a huge number of nmea sentences. That takes along time to parse. And it does not report on the resulting time until the sentences finish. Having just the one standard sentence would reduce that time. >George _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions