See last page for copyright and document info, File: Reeve_GpsNtp-Pi_Setup.doc, Page 28
10. Final Adjustments and Checks
The convergence time constant of the RPi NTP server is about 1 h. Thus, assuming the GPS receiver has a fix, the
server achieves close to 0 ms offset of the PPS reference clock in a couple hours. The offset can be followed as it
changes by repeatedly using the ntpq commands described above.
When the RPi power is first applied and the GPS receiver obtains a fix, the PPS offset after a few minutes will be
some positive or negative value. Over the next couple hours the offset will move closer to 0.000 ms as the NTP
daemon learns about the GPS clock characteristics. Many factors are involved so, even after several hours, the
offset may not be 0.000 ms and some variation will be noted with each query. My lab test systems typically run
0.000 ± 0.002 ms for the system with the GTop receiver and 0.000 ± 0.005 ms for the U-Blox receiver .
Note: The GPS receivers store the time and satellite ephemeris data in battery-backed RAM. In addition, the
NTPD uses a
driftfile
(location specified in the NTP configuration file) to store the clock frequency offset
determined by the NTPD. This offset is updated every hour. If the RPi and GPS receiver are power cycled, the
stored clock data provides very close to actual date and time and the driftfile provides very close to actual
frequency offset. With these two parameters, the convergence is faster. Therefore, on the first cold-start,
convergence requires a couple hours after satellite tracking starts but on subsequent starts convergence will be
much faster.
The PPS is a precise signal with around 10 ns of jitter. On the other hand, the offset of the GPS serial data output
(GPSD) generally will have much more variation than the PPS because of the variables involved in sending data
over an asynchronous serial port. However, the GPSD offset can be reduced somewhat by adjusting the GPSD
reference clock fudge parameter time1 in the ntp.conf file. The initial value used in the ntp.conf file is 500 ms
(0.500 s). Enter the following to see the present offset; repeat several times over a period of a few tens of
minutes:
ntpq -p
Look for the row with remote SHM(0) and refid GPSD. The offset values probably will be different for each
query. Do a mental average. For values –100 < offset < +100 ms, there probably is no need for adjustment. If you
consistently see larger negative or positive offsets, the NTP statistics can be used to calculate the average. Let
the RPi run for at least 4 hours and then at the RPi prompt enter the following series of statements to calculate
the average:
awk ‘
/127\.127\.28\.0/ { sum += $5 * 1000; cnt++; }
END { print sum / cnt; }
‘ < /var/log/ntpstats/peerstats
A moment after the last line is entered, a positive or negative value will be returned. The value is the average
GPSD reference clock offset in ms and is to be subtracted from the GPSD time1 value in ntp.conf. For example,
say the value is –33.573. This means the time1 value for GPSD in ntp.conf needs to be increased by 34 ms from
+0.500 to +0.534 s. If the value is 33.573, then time1 needs to be reduced by 34 ms to 0.466. To make the
change, use the nano editor:
sudo nano /etc/ntp.conf
