[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 127.127.20.0 mode 65553 minpoll 5 maxpoll 5
> > fudge 127.127.20.0 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 (127.127.28.1) 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
==============================================================================
+192.168.0.111 .GPS. 1 s 21 32 377 0.630 -0.008 0.009
+192.168.0.112 .GPS. 1 s 5 32 377 0.449 0.058 0.011
192.168.0.115 192.168.0.107 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",
timecode="$GPRMC,180104,A,____.____,_,_____.____,_,000.0,224.0,130617,001.8,E*__",
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
Best,
Jean-Michel.
More information about the questions
mailing list