-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Taylor Sent: Friday, 28 December 2012 2:33 PM To: [email protected] Subject: Re: [ntp:questions] Using PPS
On 28/12/2012 00:15, Joshua Small wrote: > Hi David, > > Thank you for this. I guess this leads me to the question of "how do I debug this", since I seem to have neither of those features listed. > > I do note that your example uses the ATOM driver 22, whereas several pages have referred me to using the driver 20 as a "better" option - was this a bad move? > > I did have to compile my own kernel as I added other modules not > present in the precompiled kernels featuring the PPS > > pi@raspberrypi ~ $ ntpq -p > remote refid st t when poll reach delay offset jitter > ======================================================================== ====== > *GPS_NMEA(0) .GPS. 0 l 4 8 1 0.000 -27.038 0.004 > +wombat.osoal.or .GPS. 1 u 1 64 1 43.639 144.936 1.213 > warrane.connect 130.95.179.80 2 u 1 64 1 5.842 144.114 0.574 > +203.192.179.98 223.252.32.9 2 u 2 64 1 21.483 103.720 1.765 > > pi@raspberrypi ~ $ ntpq -c rv > > associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, > version="ntpd [email protected] Mon Dec 17 22:19:03 UTC 2012 (1)", > processor="armv6l", system="Linux/3.2.27+", leap=00, stratum=1, > precision=-18, rootdelay=0.000, rootdisp=1028.296, refid=GPS, > reftime=d4875ebc.1c973e69 Fri, Dec 28 2012 10:56:44.111, > clock=d4875ebd.51aa5e49 Fri, Dec 28 2012 10:56:45.319, peer=1115, > tc=3, mintc=3, offset=-36.735257, frequency=-14.904, > sys_jitter=47.867458, clk_jitter=58.208, clk_wander=0.000 > > (the somewhat large offset is due to the fact I only turned this on > two seconds before running the command.. they do level out) > > I'm running dev version 4.2.7p334, I also tried stable 4.2.6p5 with no difference. Joshua, The fact that you don't have the "o" as the tally code (ntpq -p) and the lack of "kern" (ntpq -c rv) says that PPS isn't working. My understanding (and I am open to correction) is this: - the type 20 driver can detect PPS transitions on the DCD RS-232 line, and can timestamp those. - the type 22 driver relies on the OS detecting the PPS transition time, via PPS built into the kernel of the OS. - in the Raspberry Pi, there is no DCD line, and hence no DCD timestamp, and hence the type 20 driver will not detect the PPS transitions. - in the Raspberry Pi, there is direct I/O supported for some of the GPIO pins, and one extension to the basic OS has been to use one of those pins for PPS support. This requires both a different kernel, and a "module" driver add-on. That's why I used the type 22 driver rather then type 20. -- Cheers, David Web: http://www.satsignal.eu _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions I use the type 20 driver on my pi, and PPS to the GPIO boards works a treat with an $RMC or $ZDA string. regards pk _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
