[ntp:questions] GPS-PPS, standalone server. NTP

girino66 at gmail.com girino66 at gmail.com
Tue Jun 13 18:05:07 UTC 2017

Le mardi 13 juin 2017 13:54:25 UTC+2, Fida Hasan a écrit :
> > Hi, 
> > 
> > My 18x is linked with an Odroid C1+ and I use only driver 20 with 0x10000 mode enabled to have a better look on NMEA sentences. It's by looking 'ntpq -c clockvar' results that I discovered the quality of my 18x comparing with some others 'Adafruit' or basic GPS chips.
> > 
> > from my ntp.conf:
> > server mode 65553 minpoll 5 maxpoll 5 
> > fudge time2 0.550 flag1 1 flag3 1 flag4 1  
> > 
> > Knowing that by default flags are set to 0 I don't explicitly feel the need to reset them again to 0. 
> > Having only one physical device (GPS) connected I also don't feel the need to rename the driver with 'refid' option. 
> > 
> > Jean-Michel
> Hi Jean-Michel,
> You came up with so many good information. Thank you so much. Regarding this specific point you did not say how accuracy you got through the driver 20 (both with/without internet)?
> In my understanding, Driver 20 gives NMEA sentences and its accuracy suppose to fluctuates in millisecond range! 
> I am very keen to get a stable clock with 1 micro accuracy. Aiming this I have tested many settings.
> According to my achievement, I have got:
> 1. 1 micro accuracy in driver 22! 
> 2. then I compiled the kernel and get nano second level accuracy in driver 22! Though it fluctuates in microsecond range as well, not stable but average I was able to develop around 800ns there.
> But in driver 22, it is just merely a precise tick without time, my system always follows driver 20 (showed asterisk on it *). But still I can't develop microsecond accuracy on it. 
> My question, if I can't develop microsecond accuracy on the usable reference ID, then what's the point of saying GPS is as accurate as microsecond?
> However, I have got a link here,
> https://www.lammertbies.nl/comm/info/GPS-time.html
> According to this site, it uses shared driver 28 ( to develop achievable accuracy in microsecond range (follow the asterisk).
>   remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> +SHM(0)          .GPS.            0 l    6   16  377    0.000   28.775  10.971
> *SHM(1)          .PPS.            0 l    5   16  377    0.000   -0.001   0.002
> However, I haven't able to develop it yet, for some reasons it is not working with my Rpi system! 
> Will appreciate your further comment at this stage.
> Kind Regards,
> Fida

Hi Fida,

There are several possibilities to configure NTP to let it talk to NMEA GPS with PPS signal like the Garmin 18x.

Lot of internet examples are using GPSD and SHM drivers to communicate with ntpd; it is the easiest way because unfortunately ntpd is not compiled in standard with all 'interesting' features... In particular the driver 20 doesn't work in standard and a local compilation with '--enable-linuxcaps' option is required to fully activate all ntpd features.

As many of us I try to increase at it's best ntpd capabilities and the computer hardware used has also a role to play, this is why I switched from Rpi to Odroid computers in order to benefit a true Ethernet link. The gain is quite important for clients.

As the PPS signal involves directly the hardware I decided to let the kernel directly manage the PPS irq. Cannot be better in term of latency.
That last decision requires also a kernel compilation to enable several options liked with PPS support and to disable some other options that controls the CPU frequency.

At the end I use a small pool of stratum 1 peers composed by some RPIs and one OdroidC1+. Only the Odroid uses the Garmin, all peers uses driver 20.

That command gives all details:
ntpq -c rv -c pe -c cv -c kern -c as

associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
version="ntpd 4.2.8p10 at 1.3728 Tue May 16 04:35:53 UTC 2017 (1)",
processor="armv7l", system="Linux/3.10.104-KPPS", leap=00, stratum=1,
precision=-24, rootdelay=0.000, rootdisp=1.195, refid=GPS,
reftime=dceaa6d4.0b6f4fcb  Tue, Jun 13 2017 20:00:52.044,
clock=dceaa6e1.471ffbf5  Tue, Jun 13 2017 20:01:05.277, peer=46420, tc=5,
mintc=3, offset=-0.000094, frequency=2.094, sys_jitter=0.000060,
clk_jitter=0.001, clk_wander=0.002
     remote           refid      st t when poll reach   delay   offset  jitter
+   .GPS.            1 s   21   32  377    0.630   -0.008   0.009
+   .GPS.            1 s    5   32  377    0.449    0.058   0.011    2 s   24   32  377    0.640    0.006   0.024
oGPS_NMEA(0)     .GPS.            0 l   13   32  377    0.000    0.000   0.000
associd=0 status=0000 no events, clk_unspec,
device="NMEA GPS Clock",
poll=21509, noreply=0, badformat=0, baddata=0, fudgetime2=550.000,
stratum=0, refid=GPS, flags=13
associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
pll offset:            0
pll frequency:         2.09364
maximum error:         0.0075
estimated error:       0
kernel status:         pll ppsfreq ppstime ppssignal nano
pll time constant:     5
precision:             1e-06
frequency tolerance:   500
pps frequency:         2.09375
pps stability:         0.00802612
pps jitter:            0.001
calibration interval   256
calibration cycles:    12684
jitter exceeded:       26092
stability exceeded:    0
calibration errors:    0

ind assid status  conf reach auth condition  last_event cnt
  1 46417  f4fd   yes   yes   ok  candidate             15
  2 46418  f43d   yes   yes   ok  candidate              3
  3 46419  f01d   yes   yes   ok     reject              1
  4 46420  971a   yes   yes  none  pps.peer    sys_peer  1

As you can see the result is quite good and stable

More information about the questions mailing list