FreeBSD NTP GPS Experiment

Using a commercial GPS unit as a NTP time source

This system is no longer in operation. Check here for a list of other systems.

This page monitors an experimental NTP time server connected to a DeLorme Earthmate GPS receiver (the older, non USB version). The time server also takes input from two other NTP servers to calibrate and measure the GPS time accuracy.

Note: in the peer stats page, a jitter of 4000 indicates the GPS receiver has either been reset or lost its lock on the satellite signal.

Building the server

The server hardware was pretty easy to setup. The computer is an old Pentium 2 250MHz running FreeBSD 4.7. The GPS receiver is a DeLorme Earthmate. The first order of business was running the GPS from a power source other than internal batteries. From KA9MVA's hacking the DeLorme Earthmate site I learned the unit can be powered via pin 9 of the DB9 connector. I built a custom serial cable, injecting +6VDC on pin 9. Since the Earthmate doesn't take much power, I used an old wall-wart 12VDC power supply fed into an regulated automotive power adapter. Set for 6VDC, the hot line goes to pin 9 and the ground to pin 5. I didn't bother trying to isolate the voltage from the computer end of the cable, since RS-232 is +-9VDC. Of course, I could have just bought an adapter from DeLorme, but what fun is that?

The Earthmate uses the Rockwell Jupiter GPS engine, but has a custom ROM that won't let you reset it to NMEA mode: it only does Rockwell binary format. Also, you need to feed the Earthmate a string ('EARTHA' followed by a carraige return and linefeed) to activate the unit. NTP comes with a Rockwell driver, but doesn't have the specifics required by the Earthmate to power up and keep running.

Murray Marien was kind enough to send me copies of a driver he modified to allow using either the Earthmate or the Tripmate with NTP (Thanks Murray!). He sent replacement files for ntp_refclock.c, refclock_conf.c, and refclock_jupiter.c. I put these three file in the ntpd/ subdirectory under the main ntp distro, ran 'configure', and proceeded from there.

After the new ntpd was built and installed, there were a few last details to take care of to allow it to access the GPS. Murray's modified Jupiter driver looks for the GPS as unit /dev/emate0. I made a symbolic link from /dev/emate0 to /dev/ttyd1, since I had the GPS plugged into the com2 serial port. Finally a new ntp.conf file for /etc to tell ntpd to use the GPS driver using the 'server' directive. The 'fudge' entry is to correct the GPS' running offset of around 1 second, caused by a polling issue. The stats directives are used to keep GPS and NTP statistics. These can pile up quickly, so beware of leaving them running and forgetting about them.

GPS receiver location makes a big difference in reception. I put my Earthmate on a window ledge, with only a limited view of the northern sky. In that location the unit can take up to 45 minutes to lock on to the satellites from a cold start. The same receiver outdoors locks on in only around 20 seconds, so this obviously isn't an ideal location. The best place to put the receiver would be a weather-proof enclosure on the roof of the building. Several people have reported success using plastic containers with snap-on lids (i.e. 'Rubbermaid') to house the unit, and sealing any cable entry points with silicone caulk.

Caveats

It should be mentioned that consumer GPS units were never designed to be precision time and frequency standards. Hooking one up to an old workstation running ntpd will get you close, but you won't put any true stratum 1 NTP servers to shame.

Building a system like this one is fun and educational, but if you need a highly precise and accurate time on your machines, and you have an internet pipe that isn't usually clogged with traffic, pointing your ntpd at one of the NIST time servers is probably a better bet. There are also off-the-shelf commercial GPS time solutions such as Trimble Acutime that are much more accurate than a generic handheld GPS.

Update: March 3, 2003

After running the system over the weekend to see how it performed, I've set a fudge factor on the GPS clock of about one second. We'll see how close this gets us to the actual time as reported by the other servers.

Update: August 15, 2003

The system has been running fairly reliably for a while now. Even with the offset, I'm still seeing a difference between the GPS and NTP servers, which I may be able to tune out with a bit of tweaking. The GPS signal reliability varies a bit. Here is a graph of the reported GPS altitude versus time for as big a chunk of the data as I could fit into Excel. Altitude is the least reliable parameter reported by GPS, and can vary quite a bit with time.

Update: September 5, 2003

I had to move the server which the GPS receiver was connected to to another location. The new location has no window in which to put the receiver, so the GPS/NTP experiment is on hold. I've turned off the logging function for now as well.

Links:
Using a GPS receiver as a NIST traceable frequency standard
NIST GPS data archive
NIST Time and Frequency Lab
NIST Ion Storage Group