[ntp:questions] pps coming in, not received by ntpd

David Taylor david-taylor at blueyonder.co.uk.invalid
Tue Jul 2 05:23:43 UTC 2013


On 02/07/2013 02:14, Edward T. Mischanko wrote:
>
>
> "folkert"  wrote in message
> news:20130629175716.GM18765 at belle.intranet.vanheusden.com...
[]

A)
> server 127.127.28.0 minpoll 4
> fudge  127.127.28.0 refid NMEA
> server 127.127.28.1 minpoll 4 prefer
> fudge  127.127.28.1 refid PPS

B) > Don't you need this for PPS?
>
> server 127.127.28.0 minpoll 3 prefer
> fudge 127.127.28.0 time2 0.275 refid NMEA
> server 127.127.22.0 minpoll 3
> fudge 127.127.22.0 refid PPS

These are two different ways of getting the PPS timestamp into NTP.  As 
I understand it:

(A) requires that gpsd has some way of getting the PPS timestamps into 
one of its shared memory segments.  The only time I've used this is with 
a program of Folkert's which worked on the Raspberry Pi to read the 
timestamp when a GPIO pin changed in user-mode, and insert that 
timestamp into gpsd's second segment (numbered 1).

Aside: I couldn't find a description of using units 0 and 1 with the 
type 28 shared memory driver.  It seems that the timestamps in unit 0 
may be from the serial NMEA data, and those in unit 1 from the PPS data, 
and hence the "prefer" on unit 1.  Perhaps someone could confirm this. 
I looked at:

   http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver28.html

(B) requires that the OS support PPS transitions, and could be tested 
with a command such as Folkert gave:

# cat /sys/devices/virtual/pps/pps0/{assert,clear}
1372528130.997131540#54
1372528131.097120120#54

I think most people try to use this with the OS kernel supporting PPS, 
to give better results than with user-mode support.

That's about the limit of my knowledge and could easily be wrong!
-- 
Cheers,
David
Web: http://www.satsignal.eu



More information about the questions mailing list