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