An NTP server using GNSS for time

It seems that my workhorse distro prefers chronyd to ntpd. I was wondering why my ntpd was exiting after a day or two of operation. It turns out that this was due to a clash with chronyd. After reading an article on the Internet I have accepted my distro's judgement that chronyd is an improvement on ntpd, so I have configured it to use my GNSS server in the same way, by adding a server line. Here's the output of chronyc sources -v. You can see there is a wealth of detail.

# chronyc sources -v
210 Number of sources = 17

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| /   '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^- ntp1.ds.network               4   6   377    32  -3854us[-3670us] +/-   37ms
^- any.time.nl                   2   6   377    36  -2552us[-2369us] +/-   56ms
^- ec2-13-55-50-68.ap-south>     3   6   377    30  +3660us[+3660us] +/-  109ms
^- ntp3.ds.network               4   6   377    35  -3247us[-3064us] +/-   36ms
^- dns01.ntl02.privatecloud>     2   6   377    33   -799us[ -615us] +/-   47ms
^- cosima.470n.act.tsgnl.co      2   6   377    34  -1030us[ -846us] +/-   61ms
^+ time.cloudflare.com           3   6   377    33  -1061us[ -877us] +/-   15ms
^- 220-158-215-20.broadband>     2   6   377    32  +9851us[  +10ms] +/-   38ms
^- ntp2.ds.network               4   6   377    32  -1467us[-1283us] +/-   37ms
^- dns01.syd01.privatecloud>     2   6   377    32  -3567us[-3382us] +/-   42ms
^- mika.470n.act.tsgnl.co        2   6   377    31  -1762us[-1762us] +/-   51ms
^- pauseq4vntp1.datamossa.io     2   6   377    30  -1399us[-1399us] +/-   42ms
^+ time.cloudflare.com           3   6   377    35  -1016us[ -833us] +/-   15ms
^+ bitburger.simonrumble.com     1   6   377    30   +676us[ +676us] +/-   13ms
^- 123.50.146.78                 2   6   337    34   -899us[ -716us] +/-  172ms
^- pauseq4vntp2.datamossa.io     2   6   377    35  -1745us[-1562us] +/-   38ms
^* rpi1.local                    1   6   377    31   +354us[ +538us] +/- 6065us

 I might be able to reduce that 6 ms estimated error by tuning.

The RPi has been running for a while now. The last thing I did was to cut away a panel of the acrylic case so that the GPIO flat cable can enter the box with the cover on. It's strange the makers of the case didn't consider this but I suppose most buyers, including me, ended up using the RPi as a cheap Linux machine and not as a hardware experimentation platform like the Arduino.

So I'm marking this project completed. If I add other capabilities to the RPi, like bluetooth comms, I'll start a new project.

Adding my RPi NTP server was simply a matter of adding a server line to my workhorse's /etc/ntp.conf. After doing that running ntpq -p on it gave this:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+61-68-38-238.st 203.59.7.248     3 u   10   64  377   60.369   -0.377   1.405
+103.38.121.36 ( 202.6.131.118    2 u    -   64  377   20.083   -0.977   1.474
-y.ns.gin.ntt.ne 249.224.99.213   2 u    6   64  377   14.956   +0.761   1.208
*rpi1.local      .GPS.            1 u   21   64  377    0.708   -2.365   0.296

So I will let it run for a while. Hopefully I don't get woken up at the wrong hour in the morning by my computer's alarm 😁, like the programmer who was pranked by friends who changed his computer's clock's timezone or something like that. Actually NTP will throw out outliers so if the GNSS time is wrong it will be disregarded.

As explained in the time server document, you can get the NTP server to keep statistics on the offset and later compute an adjustment to the fudge line in ntp.conf. The suggested computation had to be modified, probably because I'm running ntpsec instead of ntp. This was what I ended up using:

awk '/SHM\(0\)/ { sum += $5 * 1000; cnt++; } END { print sum / cnt; }' < /var/log/ntpsec/peerstats

The original used a search filter of 127.127.28.0 but it seems that ntpsec records GPS readings as SHM(0). Also the output is in milliseconds so has to be translated to seconds for adjusting the time1 value on the fudge line. This is what I have currently.

fudge 127.127.28.0 time1 0.118 refid GPS

a difference of 2 milliseconds from the previous value. Here's a typical output of ntpq -p:

     remote           refid      st t when poll reach   delay   offset   jitter
===============================================================================
 0.debian.pool.n .POOL.          16 p    -  256    0   0.0000   0.0000   0.0019
 1.debian.pool.n .POOL.          16 p    -  256    0   0.0000   0.0000   0.0019
 2.debian.pool.n .POOL.          16 p    -  256    0   0.0000   0.0000   0.0019
 3.debian.pool.n .POOL.          16 p    -  256    0   0.0000   0.0000   0.0019
 192.168.16.1    .INIT.          16 u    - 1024    0   0.0000   0.0000   0.0019
*SHM(0)          .GPS.            0 l   49   64  377   0.0000  -1.1543   0.6951
+time.cloudflare 10.26.8.188      3 u   42   64  377  15.2933   4.4961   1.1248
+time.cloudflare 10.26.8.188      3 u   50   64  377  15.2943   5.6666   0.5611
-220-158-215-20. 202.46.178.18    2 u   17  128  377  39.1423  -6.5729   0.8229
-cosima.470n.act 203.35.83.242    2 u   15  128  377  18.9447   4.4120   1.0238

I may fine tune it further after running it for longer, but at this point we are in millisecond territory which is far more accuracy than I need for home purposes. There's no point tweaking it much more given the jitter in the absence of an accurate PPS hardware signal which is coupled into the kernel.

Next task is to register the RPi as a time server for my workhorse PC.

For this part of the project, I followed the instructions on the page GPSD Time Service HOWTO at the gpsd website in the links.

You may be wondering how a serial interface with significant delay could convey a very accurate time stamp. In fact it doesn't. Even if you measure from the leading edge of the first character, there is enough jitter in the chain to swamp the accuracy. The solution is a pin on the GNSS module called 1PPS (1 Pulse Per Second) or just PPS. Actually it can be configured to other frequencies, but usually 1 Hz is used. This hardware line is connected directly to the hardware and the CPU takes the edge of this signal as the time conveyed by the serial interface an instant later.

For this to work, the pulse output from the GNSS module must be connected to the CPU. Unfortunately in the module I have, only two power lines and two serial data lines are used. On custom built GNSS clock rigs, the PPS pin could be connected to a GPIO line.

So I have to live without PPS.

Next is how to send the time information from gpsd to ntpd. This is done by gpsd creating a Unix shared memory segment (shm) which ntpd reads. There is a set of magic IP addresses which are used to specify gpsd to ntpd as a "local time server".

# GPS Serial data reference (NTP0)
server 127.127.28.0
fudge 127.127.28.0 time1 0.12 refid GPS

The IP address maps to the ID of the shared memory segment.

A few things. gpsd should be started with the -n argument so that it starts taking a fix even if no client is connected to it. The time1 parameter in the snippet above specifies the total delay in the data feed via the serial interface and chips. It's specified in seconds and can be estimated by watching the output of ntpq -p after the system has settled down. You can see that there is about 120 ms of delay there. Finally, following the recommendation, I replaced the ntp package with ntpsec which is a compatible, more recent, and more secure derivative of ntp. It was just a matter of doing an apt install.

Here is the output of ntpq -p. The GNSS module has a refid of .GPS. Offset is in ms so not as bad as it looks. I might tune the GNSS delay by and by.

     remote           refid      st t when poll reach   delay   offset   jitter
===============================================================================
 0.debian.pool.n .POOL.          16 p    -  256    0   0.0000   0.0000   0.0019
 1.debian.pool.n .POOL.          16 p    -  256    0   0.0000   0.0000   0.0019
 2.debian.pool.n .POOL.          16 p    -  256    0   0.0000   0.0000   0.0019
 3.debian.pool.n .POOL.          16 p    -   64    0   0.0000   0.0000   0.0019
 192.168.16.1    .INIT.          16 u    - 1024    0   0.0000   0.0000   0.0019
*SHM(0)          .GPS.            0 l   32   64  377   0.0000  -6.3869   5.0497
-pauseq4vntp1.da 202.6.131.118    2 u   70  128  377  17.3605   5.0752   0.5022
+time.cloudflare 10.26.8.188      3 u   33   64  377  16.8134   5.0694   0.5466
+dns.seby.io     17.253.66.125    2 u    7   64  377  17.1365   5.6812   0.3424
-dns01.ntl02.pri 130.95.179.80    2 u   15  128  377  21.5701   4.7036   0.4717

So now I have an ntp server that uses GNSS as a source of time, in addition to servers from the Debian ntp pool.

I shut down the RPi, moved the kit to a window sill and powered it up again. This time running cgps elicited a bunch of messages showing it was getting fixes from the satellites. The readings swung wildly until they stabilised. I've blanked the lat/long in this screenshot.

So it works. Next I have to make gpsd a source of time for ntpd.

The module arrived today. It comprises a small breakout board for the module and a ceramic antenna.

I soldered a 4 pin header to the board, plugged it into the RPi breakout board and made the power and serial data connections following the instructable in the list of links.

I had to figure out how to start the gpsd service. At first I thought I had to enable the gpsd service with systemctl. Running the ncurses command line client cgps showed no connection to the module.

When I tried to run gpsd at the command line it said that the TCP and UDP sockets were already used. A quick look with lsof (which I installed on the fly) showed that systemd was holding them open. Huh?

A search of the Internet showed that this was indeed supposed to be the case, systemd listens on the Unix socket and network sockets and if a connection is made, it starts up gpsd.

So reenabling and starting the service running cgps eventually elicited a response from the module. There was no location fix, it stayed at mode:1 all the time.

{"class":"VERSION","release":"3.17","rev":"3.17","proto_major":3,"proto_minor":1
2}
{"class":"WATCH","enable":true,"json":true,"nmea":false,"raw":0,"scaled":false,"
":9600,"parity":"N","stopbits":1,"cycle":1.00}]}
{"class":"WATCH","enable":true,"json":true,"nmea":false,"raw":0,"scaled":false,"
timing":false,"split24":false,"pps":false}
{"class":"DEVICE","path":"/dev/ttyAMA0","driver":"NMEA0183","activated":"2020-07
-15T12:48:30.763Z","native":0,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00}
{"class":"GST","device":"/dev/ttyAMA0","rms":0.000,"lat":3750000.000,"lon":37500
00.000,"alt":3750000.000}
{"class":"DEVICE","path":"/dev/ttyAMA0","driver":"u-blox","activated":"2020-07-1
5T12:48:31.464Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycl
e":1.00,"mincycle":0.25}
{"class":"TPV","device":"/dev/ttyAMA0","mode":1}

 
I will have to move it to a location nearer a window.

It turns out that I had to do a couple of tweaks to the RPi configuration. The first is to edit /etc/dhcp/dhclient not to request a NTP server in the DHCP request because then ntpd ignores /etc/ntp.conf. In fact later I should switch to a static IP address so that the RPi not reliant on the DHCP server on the LAN being up.

I also discovered that I had to set the NTP config in DietPi to custom, otherwise every morning it would kill the ntp daemon

It also helped me discover that my LAN's NTP server wasn't configured to accept NTP requests due to a change in the shipped default configuration. I had to edit out the noquery parameter on the IPv4 and IPv6 restrict lines.

Pretty much by the instructions on the site. I downloaded the distribution, extracted and wrote the image on the 4GB SD card, inserted that into the RPi and powered up. I already had an entry in my DHCP server for the Ethernet interface so it appeared at a known IP address. I ssh'ed in and let it update itself to the latest release, then configured it. Similar to Rasberry Pi OS, it's configured using a ncurses/dialog interface.

So, nothing to see here, let's move on. Only additional things I did were to install the wiringpi, ntpd, gpsd, nfs-client and autofs packages. The last two are to mount an NFS directory from my workhorse so that I can backup configuration information.

For powering the RPi, I used a wall wart putting out 12V feeding a buck converter to 5V. According to a USB meter in the power lead, it draws 0.41A. So just over 2W consumption.