[ntp:questions] Using PPS

David Taylor david-taylor at blueyonder.co.uk.invalid
Fri Dec 28 06:32:55 UTC 2012


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 at 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 at raspberrypi ~ $ ntpq -c rv
>
> associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
> version="ntpd 4.2.7p334 at 1.2483-o 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



More information about the questions mailing list