I've set up a linux box running debian lenny, with the stock kernel. I got the CHU_AUDIO driver working, which gives me a good signal here about 19 or 20 hours out of the day, and generally has been keeping the clock set within about 3 ms. I decided to buy a Garmin GPS 18x LVC to try and see if I could use it as a PPS time source.
I tried downloading the latest pps patch for the kernel. I managed to patch my kernel, as suggested by this site: http://time.qnan.org/ I couldn't find all the options that it said were supposed to be enabled in menuconfig. It said that CONFIG_SERIAL_8250, CONFIG_PPS, and CONFIG_PPS_CLIENT_8250 needed to be enabled, but I couldn't find CONFIG_PPS_CLIENT_8250, and then when I recompiled the kernel, it wouldn't find the pps source. The pps entries that were supposed to show up in /proc didn't. That's why I went to gpsd, but I'm wondering if my huge offset between the pps and NMEA data is messing things up. I used apt-get to install gpsd, but it kept giving me ntpshm_pps: not in locking range: errors. I found a posting here http://lists.berlios.de/pipermail/gpsd-users/2007-June/002693.html which suggested the code that does that check could be safely commented out. I'm not a coder, and so when I commented out the code referenced in the posting, it wouldn't compile ntpshm.c This is the code that the posting suggested could be commented: if (labs( l_offset ) > PUT_MAX_OFFSET) { gpsd_report(LOG_RAW, "ntpshm_pps: not in locking range: %ld\n" , (long)l_offset); return -1; } Instead, I ended up changing a line in ntpshm.c to #define PUT_MAX_OFFSET 800000 from #define PUT_MAX_OFFSET 500000 because occasionally the offset between NMEA and the PPS signal even goes above 700 ms. From what I've read here in this group, typical values for the Garmin GPS 18x LVC are generally about 190 ms. gpsd: GPRMC starts a reporting cycle. gpsd: GPRMC sets mode 2 gpsd: ntpshm_put: Clock: 1229964787 @ 1229964787.710811 gpsd: pps-detect (DCD) on /dev/ttyS0 changed to 1 gpsd: ntpshm_pps: not in locking range: 710811 gpsd: PPS pulse. cycle: 1000018, duration: 800015 gpsd: pps-detect (DCD) on /dev/ttyS0 changed to 0 gpsd: ntpshm_pps: not in locking range: 710811 <------------ gpsd: PPS pulse. cycle: 1000019, duration: 200004 gpsd: <= GPS: $GPRMC,165308,A,4502.9718,N,07750.6521,W, 000.0,000.0,221208,012.3,W*75 I started out without a time1 offset in ntp.conf (before I got PPS working) for the NMEA output remote refid st t when poll reach delay offset jitter =================================================== *CHU_AUDIO(0) 0.0.0.0 1 l 16 64 377 0.000 10.164 1.903 xSHM(0) .GPS. 1 l 32 16 34 0.000 -619.58 46.609 SHM(1) .PPS. 1 l - 16 0 0.000 0.000 0.001 but now I have: #gpsd server 127.127.28.0 minpoll 4 fudge 127.127.28.0 refid GPS stratum 3 time1 0.7 #PPS server 127.127.28.1 minpoll 4 prefer fudge 127.127.28.1 refid PPS stratum 0 Does the offset matter? There's something really wrong with this setup, because it keeps declaring my time sources as falsetickers: remote refid st t when poll reach delay offset jitter ======================================================= xCHU_AUDIO(0) 0.0.0.0 1 l 13 64 377 0.000 -12.242 3.018 +SHM(0) .GPS. 3 l 2 16 377 0.000 -62.711 36.816 *SHM(1) .PPS. 0 l 1 16 377 0.000 -62.414 0.529 One minute later: remote refid st t when poll reach delay offset jitter ==================================================== *CHU_AUDIO(0) 0.0.0.0 1 l 8 64 377 0.000 -12.722 2.343 +SHM(0) .GPS. 3 l 9 16 377 0.000 -30.715 27.335 xSHM(1) .PPS. 0 l 10 16 377 0.000 -62.789 0.543 And so on. Thanks, Court _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
