On 05/07/2018 21:30, Daniel Gearty wrote:
server 127.127.20.3 iburst minpoll 3 mode 17
# COM3, 8 second polling, NMEA GPRMC, 9600 bps, NaviSys GR-8013W u-blox M8 USB
PPS GPS
fudge 127.127.20.3 time1 0.000142 time2 0.111111 flag1 1 flag2 1 flag3 0
# PPS offset, NMEA offset, enable PPS, pulse on falling edge, disable kernel PPS
I am using a u-blox M8.
I had trouble with it until I realized that the pulse is on the falling edge
rather than the default of the rising edge.
I used a u-blox utility to see timestamps for the NMEA GPRMC sentence coming
through. It took about a tenth of a second. If it is accurate to within four
tenths of a second, it works. It not, then it does not work.
Barring access to a more accurate clock, PPS offset is a blind guess. All I do
is offset by an average of the NTP loopstats offset over time. I use 142
microseconds.
I've compared a number of GSP/PPS sources using an oscilloscope and the
PPS offset between them is usually within 100 nanoseconds, so I would be
surprised if the PPS leading edge is as much as 142 microseconds out.
With a Raspberry Pi, I typically I see offsets reported by ntpq -pn well
under 20 microseconds:
C:\Windows\System32>ntpq -pn raspi-1
remote refid st t when poll reach delay offset
jitter
==============================================================================
o127.127.22.0 .kPPS. 0 l 13 16 377 0.000 -0.001
0.004
127.127.28.0 .GPSD. 0 l 12 16 377 0.000 367.025
5.593
*192.168.0.3 .kPPS. 1 u 6 32 377 0.542 0.054
0.008
.
.
https://www.satsignal.eu/mrtg/raspi1_ntp.html
--
Cheers,
David
Web: http://www.satsignal.eu
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
