George R. Kasica <geor...@netwrx1.com> writes: >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: The other possibility is that shmpps and gpsd are fighting over the serial port. Both are trying to read the lines and to grab the interrupt. It may be that gpsd is messing it up for shmpps. ># 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??? No idea, but I have offered a couple of possiblities. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
