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

[Joe Smith <joe.smith@xxxxxxxxxxxxxxxxxxx>]

Thank you for the quick response Bill... The PPS is coming in on /dev/pps1 which is what I have in the refclock entry in my chrony.conf file. When run the cat command corresponding to that device I get:

debian@beaglebone:~/ntp-gps-server/pps-overlay$ cat /sys/devices/virtual/pps/pps1/assert

1510661769.997836084#571264

debian@beaglebone:~/ntp-gps-server/pps-overlay$ cat /sys/devices/virtual/pps/pps1/assert

1510661772.997843704#571267

debian@beaglebone:~/ntp-gps-server/pps-overlay$ cat /sys/devices/virtual/pps/pps1/assert

1510661777.997854254#571272

debian@beaglebone:~/ntp-gps-server/pps-overlay$ cat /sys/devices/virtual/pps/pps1/assert

1510661780.997830904#571275

debian@beaglebone:~/ntp-gps-server/pps-overlay$ cat /sys/devices/virtual/pps/pps1/assert

1510661790.997835992#571285

If I grep the /proc/interrupts file I get:

debian@beaglebone:~$ grep ocp /proc/interrupts

 88:     572416  4804c000.gpio  28 Edge      ocp:bs_pinmode_P9_12_0x27_pinm

debian@beaglebone:~$ grep ocp /proc/interrupts

 88:     572417  4804c000.gpio  28 Edge      ocp:bs_pinmode_P9_12_0x27_pinm

debian@beaglebone:~$ grep ocp /proc/interrupts

 88:     572418  4804c000.gpio  28 Edge      ocp:bs_pinmode_P9_12_0x27_pinm

debian@beaglebone:~$ grep ocp /proc/interrupts

 88:     572419  4804c000.gpio  28 Edge      ocp:bs_pinmode_P9_12_0x27_pinm

debian@beaglebone:~$ grep ocp /proc/interrupts

 88:     572420  4804c000.gpio  28 Edge      ocp:bs_pinmode_P9_12_0x27_pinm

The PPS is on pin 12 of the P9 header of the BeagleBone Black.

On Mon, Nov 13, 2017 at 5:59 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:

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 .