[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...

> server minpoll 4
> fudge refid NMEA
> server minpoll 4 prefer
> fudge refid PPS

B) > Don't you need this for PPS?
> server minpoll 3 prefer
> fudge time2 0.275 refid NMEA
> server minpoll 3
> fudge 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:


(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}

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!
Web: http://www.satsignal.eu

More information about the questions mailing list