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

unruh unruh at invalid.ca
Tue Jul 2 14:18:35 UTC 2013


On 2013-07-02, David Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
> 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 

It is different. You need some code which reads and timestamps the
interrupt. I believe tht gpsd can do that. Then you need some way of
getting that timestamp to ntpd. that is what the shared memory does (it
is common piece of memory shared between two programs.) 
Now, you can use the kernel pps code, you can use shmpps ( which reads
the serial or parallel port interrupts and puts the timestamp into the
shared memory segment etc) 


> 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:

This is another, kernel type code to timestamp the interrupt. As you say
it puts out the info into /dev/pps*


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

That is just a monitoring peek into the kernel module.


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

To timestamp the pps, you have to have some module (ie kernel level)
timestamp process. shmpps, gpsd, the kernel pps, write your own,....

>
> That's about the limit of my knowledge and could easily be wrong!



More information about the questions mailing list