On 02/07/2013 02:14, Edward T. Mischanko wrote:
"folkert" wrote in message
news:20130629175716.gm18...@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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
