Building the Jupiter driver for the Delorme Tripmate

---- update march.2005: ----
I updated to Fedora Core 3 and it included NTP 4.2.0a which of course it replaced my old ntpd daemon with the jupiter reference clock. I decided to use the new version of NTP and tried to compile with my refclock_jupiter.c source code. It quit with an error. The refclockproc structure in ntp_refclock.h has been changed. It dropped the msec and usec members and added nsec. If you read the latest information about NTP, you will see that it has been updated to nanoseconds and they talk about nanosecond kernels for Linux.

I checked the Rockwell Zodiac GPS Receiver Family Designer's Guide. Table 5-5 of the guide shows that the chip already outputs nanoseconds. So I changed the refclock_jupiter.c source file in two places to reflect to change. The new driver file for NTP 4.2 can be downloaded here. The rest of the instructions following are the same.
---- end of update march.2005: ----

The driver file (for NTP 4.1 and earlier) can be downloaded here. It's in gzip format.

Since I'm not all that familiar compiling Linux programs I'm not going to repeat any instructions already in the NTP documentation other than what is required to get the Jupiter driver for the Delorme Tripmate/Earthmate working. The full instructions for building the NTP system are with the NTP source code. You might want to review them before you read this information. 

You will need the source code for NTP. The best place to get it is from your distro as it will already be tweaked for your system. Otherwise download it from www.ntp.org. When you extract the source it creates a directory structure with a directory named ntpd. Unzip the refclock_jupiter.c driver source code that you downloaded here and replace the file with the same name in the ntpd directory. You might want to rename the original file to save it. This is the only file you need to replace. The jupiter.h header file is the same as the original.

The refclock_jupiter.c source code will build for the Tripmate. If you have the Earthmate you will have to change that in the source code. Look for the three lines:

#define EARTHMATE 0 /* 0 for EarthMate, 1 for TripMate */
#define TRIPMATE 1

#define MMODEL TRIPMATE /* compile for Tripmate 

To compile for the Earthmate replace the last line with:

#define MMODEL EARTHMATE /* compile for Earthmate 

You might want to search for the keyword "jupiter" in all the source files to see what files are affected by the jupiter driver for your own information, but I only found two files that need to be modified. They are as follows:

config.h

In the config.h file, find the line:

/* Rockwell Jupiter GPS clock? */
#define CLOCK_JUPITER 1

If it's missing or commented out, add it as shown. This tells the compiler to include the jupiter driver. You also can look through the rest of the file and remove the clocks that you don't want included. This will slim down the final ntpd daemon but it's not necessary.

---- update march.2005: ----
On this last episode with NTP, I found out that the config.h file is actually created from the configure routine. It has switches to turn clocks on or off. By default a bunch of common clocks are compiled into the code. You can remove all the unused clocks with this:

# ./configure --disable-debugging --disable-all-clocks --enable-LOCAL-CLOCK --enable-JUPITER 

This will create a new config.h file with only the two clocks you specified. You need the local clock as a minimum. It's a failsafe if the remote clock servers can't be reached. The problem is, the JUPITER driver still isn't enabled unless you have a PPSAPI. So you have to change this file after you run configure.
---- end of update march.2005: ----

ntpd/refclock_conf.c

The new jupiter driver doesn't require the PPS driver. In the refclock_conf.c file find the line:

#if defined(CLOCK_JUPITER) /* && defined(HAVE_PPSAPI) */

and comment out the last part as shown.

---- update march.2005: ----
I think the PPS API is suppose to be included in the new Linux kernels. With my update to Fedora Core 3, I still have to comment out this line shown above. If you recompile the kernel, then you could include the PPSAPI.
---- end of update march.2005: ----

That should do it. Follow the instructions to compile and build NTP. That usually is done by typing make from the NTP directory and then a make install. In my case I ran configure, edited the config.h and refclock_conf.h files, then ran make and make install. I then copied the binary files it created from /usr/local/bin to /usr/sbin.

Installing the Delorme Tripmate

Once you have the driver compiled into the code, you need to attach the Delorme Tripmate GPS receiver to the computer with the serial cable and update the /etc/ntp.conf file. You will also have to resolve how you will get power to the receiver. There are several article on the Internet on how to wire the receiver for continuous power. I just used the Delorme solution. They have a cable to split one of the PS/2 ports and draw power off from it. 

I attached my tripmate to the first serial port /dev/ttyS0. The driver expects the GPS receiver on a device called /dev/emateX where X is the port number. To create this device, just link it to the serial device with the command:

ln -s /dev/ttySX /dev/emateX

where X is the port number. For the first serial port use:

ln -s /dev/ttyS0 /dev/emate0

Use emate whether you have the Tripmate or the Earthmate. 

Add the following line to the /etc/ntp.conf file:

server 127.127.31.0

ln -s /dev/ttyS1 /dev/emate1

You will want to add some other servers to discipline your clock. See the NTP documentation. You should connect to three or four other remote NTP servers so that there is some redundancy and NTP can make a better estimate of the correct time.

You also will probably have to add a fudge factor. This would be the difference between what your Tripmate/Earthmate reports the time to be and what the real time is. The difference is the delay in requesting the time and actually receiving and processing it. I have a fudge factor of about one second so I added the following line to the /etc/ntp.conf file.

fudge 127.127.31.0 time1 1.000

To find out what the fudge factor would be, use the command ntpq -p once your GPS clock has been running for a while. You will get the output:

   remote            refid       st t when poll reach   delay   offset  jitter
==============================================================================
LOCAL(0)         LOCAL(0)        10 l   36   64  377    0.000    0.000   0.008
*GPS_JUPITER(0)  .GPS.            0 l   44   64  377    0.000    0.389   0.647
-sue.cc.uregina. tick.ucla.edu    2 u   12   64  377   49.261    1.862   7.977
+dense.utcc.utor 128.100.200.166  2 u   34   64  377  105.798    1.209   0.858
-br3.umtnet.umt. ntp-p1.obspm.fr  2 u   18   64  377   88.764   -3.599   0.045
+caesar.cs.wisc. ben.cs.wisc.edu  2 u   23   64  377  119.030    0.242   0.008

The offset displayed is the difference between the computers clock and the other clocks. If you take an average of the servers clocks offsets and subtract the GPS clock offset, that will give you an idea of how far off real time your GPS clock is and how much of a fudge factor you should use to correct it.

To fine tune the fudge factor, turn on the log files. The peerstats log file will record each reading from the servers and record it in a similar format as the output from ntpq -p. After a couple of days, or weeks, you can use the peerstats log file to calculate an accurate fudge factor. To turn on the peerstats log files add the following lines to your /etc/ntp.conf file.

statsdir /var/NTP/
filegen peerstats file peerstats type day enable
statistics peerstats

The first line specifies what directory to place the files. The next line specifies how to generate the file name for the peerstats log file and at what interval (daily) to change it. The final line specifies what statistics to log. In this case just the peerstats. You can also log loopstats and clockstats. See the NTP documentation on monitoring for a better explanation.

Back to Update Feb 2002