[ntp:questions] shm + pps calibration

David Taylor 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 iburst minpoll 3 mode 17
> # COM3, 8 second polling, NMEA GPRMC, 9600 bps, NaviSys GR-8013W u-blox M8 USB PPS GPS
> fudge 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 
0.004    .GPSD.           0 l   12   16  377    0.000  367.025 
*     .kPPS.           1 u    6   32  377    0.542    0.054 


Web: http://www.satsignal.eu

More information about the questions mailing list