[ntp:questions] shm + pps calibration

[David Taylor]

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