[ntp:questions] shm + pps calibration
david-taylor at blueyonder.co.uk.invalid
Fri Jul 6 06:14:07 UTC 2018
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
o127.127.22.0 .kPPS. 0 l 13 16 377 0.000 -0.001
127.127.28.0 .GPSD. 0 l 12 16 377 0.000 367.025
*192.168.0.3 .kPPS. 1 u 6 32 377 0.542 0.054
More information about the questions