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

[ Thread Index | Date Index | More Archives ]

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)
( 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
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

# 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
dumpdir /var/lib/chrony
logchange 0.5

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

Mail converted by MHonArc 2.6.19+