Linux NTP GPS Experiment #6

Using a Deluo GPS unit as a NTP time source

Setup

The server is a 133 MHz Pentium system, with 128 MB of RAM, running Fedora linux. A Deluo GPS receiver is attached to the first serial port. An internal modification to the serial port cable sends power to the GPS unit from an unused drive power connector in the computer. The system runs gpsd, which acts as a server to allow access to the GPS data from the receiver, and also implements the shared memory driver interface to ntpd.

The GPS receiver is located on the sill of a west-facing window, with limited view of the sky. The causes frequent loss of lock, which no doubt also impacts its performance as a time base source.

Ntpd is configured thus:

# /etc/ntp.conf
driftfile /etc/ntp.drift

# configure shared memory driver, pulls data from gpsd
#  fudge time offset to trim NMEA delay, push stratum
#  down to discourage clients from using this experimental
#  server, and set refid to GPS
server 127.127.28.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.0 time1 1.276 stratum 9 refid GPS

# Local clock for when the GPS losses lock
server 127.127.1.0 minpoll 4 maxpoll 4 
fudge 127.127.1.0 stratum 11 refid XO

# Tell ntpd to keep statistics
statsdir        /var/log/ntp/
filegen clockstats      file clockstats type day        enable
filegen peerstats       file peerstats  type day        enable
filegen loopstats       file loopstats  type day        enable
statistics clockstats peerstats loopstats
logfile /var/log/ntp/messages

gpsd is started at boot by adding the start command to /etc/rc.local:

# Start gpsd
/usr/local/sbin/gpsd -b -n /dev/ttyS1

This points to COM1. The '-b' tells gpsd to start in 'non-break' mode, which prevents it from sending commands to the GPS (for some reason gpsd's query/commands crash the Deluo GPS unit). '-n' tells gpsd to listen to the GPS even when no clients are connected to gpsd, so that no timing messages are lost.

The 'time1' fudge offset was determined by running ntpd against other ntp servers, with the shared memory driver marked 'noselect'. This allowed the offset to stabilize. The driver offset was adjusted and ntpd restarted a few times to make sure it was tracking other ntp servers properly. The configuration file was then changed to only track the shared memory driver (and thus, the GPS time data coming from gpsd).

The local clock driver was added when it was realized that when only the gpsd shared memory driver was in the configuration, the ntp server would continue to report that the SHM source was being used, even when the GPS lost lock and no time updates were being sent to ntpd. Using the local clock driver, the refid field changes and the stratum drops when lock is lost, giving clients a better idea of what's going on.

The quality of the ntp server was then measured by another computer which compares it to several other ntp servers.

Results:
An ntp server with only a GPS NMEA input and no pulse-per-second signal has inherent instability due to the variation of the NMEA string transmission timing. This server was set up mostly as an exercise in using gpsd and the shared memory driver, and to measure the instability of NMEA-only time bases, not as an operational low- stratum ntp server. In all fairness, the Deluo GPS unit used was never intended as a time reference, it was merely on-hand and was pressed into service for the experiment.

Update: September 24, 2008
The system continues to function fairly well. The GPS receiver loses lock quite frequently, and sometimes spends fairly large periods before reaquiring it (10s of minutes at most).

The performance of the system is what was expected with the hardware limitations: an NTP server with a very good long-term stability, tracking UTC time delivered via GPS, but suffering from short-term instability (jitter) due to the lack of a pulse per second signal from the GPS and frequent GPS outages due to receiver antenna location. Ntpd is currently set for minimum time between clock updates, which probably contributes to the jitter. An interesting experiment would be to change this to the maximum update time, and let the local clock run free between updates. This would probably lower short-term instability.

Update: October 24, 2008
The system was moved to a different building with roof access. The GPS receiver was modified by splicing a long length of cat 5 network cable into the line, such that the receiver could be mounted in a PVC housing on the roof and connected to a computer located indoors.

Despite the much better view of the sky, the receiver still experiences significant periods of loss of position lock. NMEA health sentences are still sent successfully, so the lengethened serial cable is not suspect at this time. Local interference may be an issue, a fault may exist in the GPS receiver, or the PVC pipe housing that protects the unit from weather may be causing attenuation of the signal.

Update: March 2, 2009
Gpsd's shared memory driver for ntpd stopped functioning, though gpsd continued to run and serve GPS data. A restart of gpsd got the driver working again.

Moving the GPS receiver to a steel plate on the roof top solved the signal problem. The original PVC pipe enclosure mounted to an antenna mast had a very poor signal reception record. The new mount is a few feet away, with a PVC cap placed over the receiver to offer protection from weather.

Links:
http://gpsd.berlios.de/
http://www.deluogps.com/