Re: [chrony-users] GPS / Chrony NTP server config questions

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

On Mon, 13 Nov 2017, Joe Smith wrote:

> A little background... I am building a small NTP server utilizing a BeagleBone Black Rev C
> and an AdaFruit Ultimate GPS breakout board (with external antenna)
> (https://learn.adafruit.com/adafruit-ultimate-gps/overview). I have the hardware connected,
> have GPS data coming in, and the PPS signal being fed to the BeagleBone on a GPIO pin
> (hardware overlays are correct). The purpose of this server is to serve up NTP to local
> clients (very few) on an isolated network with no internet connection. I referred to some
> online references for similar setups and have tried to read up as much as I can.
> Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux
>
> The problems I'm having I think are probably configuration based. I just can't seem to
> figure out what I'm doing wrong. I fear the accuracy and jitter is much poorer than I need
> (I need <1ms accuracy) based on the output of chronyc sources. Any guidance you can give on
> what to try would be greatly appreciated. Also if you could give some tips on how to get a
> general feel for how accurate my clock is that would also. Thanks in advance.
>
> debian@beaglebone:~$ chronyc sources
> 210 Number of sources = 2
> MS Name/IP address         Stratum Poll Reach LastRx Last sample
> ===============================================================================
> #? NMEA                          0   4   377    21   +102ms[ +102ms] +/-  107ms
> #? PPS                           0   4     0     -     +0ns[   +0ns] +/-    0ns

The "reach" tells you how many of the past 8 ntp packets have returned with a
valid response packet. Your reach on PPS is 0. Ie it has not had any response
from PPS. Thus your time is determined completely by the gps nmea for which
getting even 1ms is hard. (more like 10ms-100ms).

So something is going wrong with PPS. you have not set it up correctly.

cat /sys/devices/virtual/pps/pps0/assert
should show something like
1510613723.000000613#3741424
The stuff before the # is the time in seconds of the system clock when the
assert edge of the pulse came in, and the number after the # is the packet
number. Yours will probably either be non-existent of 0 in both.

So you need to debug your PPS.
The PPS is coming in on the GPIO 10 pine you say. I have never worked with the
GPIO and so am not sure how you get that working.


> I was expecting the Last sample values to be much smaller but maybe I'm misinterpreting the
> output.
>
> # chrony.conf settings
> minsamples 10
> refclock SHM 0 offset 0.395 delay 0.2 refid NMEA noselect
> refclock PPS /dev/pps1 refid PPS precision 1e-9 poll 4 prefer
> commandkey 1
> driftfile /var/lib/chrony/chrony.drift
> log tracking measurements statistics
> logdir /var/log/chrony
> maxupdateskew 100.0
> dumponexit
> dumpdir /var/lib/chrony
> allow
> logchange 0.5
> rtconutc

Once you get the pps working your accuracy will be something like 1us .