During this season of giving, you can show your support for the NTP Project by making a donation to Network Time Foundation.

Configuring Jupiter Refclock with Linux

This driver is only valid for Jupiter GPS Modules that support the Rockwell/Conexant/Navman binary interface (up to the model 12 modules). The newer models seem to have switched to the SiRF / NMEA protocols.

I have a working setup with linux-2.4.21-NANO and a Jupiter GPS receiver.

Refer to the Refclock Jupiter documentation.

These notes are for these versions. They assume you have already patched the kernel with PPSkit, compiled and installed a working NANO-kernel.

  • linux-2.4.21.tar.gz
  • PPSkit-2.1.4.tar.gz
  • ntp-stable-2.4.0a-20040617.tar.gz

To enable kernel PPS disipline you need edit one line in refclock_jupiter.c. See diff below

@@ -232,5 +232,5 @@
 #ifdef HAVE_PPSAPI
        instance->assert = 1;
-       instance->hardpps = 0;
+       instance->hardpps = 1;   // Enable kernel PPS dicipline
        /*
         * Start the PPSAPI interface if it is there. Default to use

Note that there seems to be a patch floating around that fixes the hardpps issue.

NTP builds refclock_jupiter by default, if the necessary bits are found.

Jupiter specific lines from my ntp.conf

      # Jupiter binary mode
      server 127.127.31.0 prefer        #
      fudge 127.127.31.0 time1 0.00     #
      fudge 127.127.31.0 flag3 1        # I use the nonstandard edge on the PPS signal

With the 62euro GPSKIT from https://www.gpskit.nl, I get quite good performance.

# ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp1.sth.netnod .PPS.            1 u   40  512  377   12.084    0.442   0.337
+ntp2.sth.netnod .PPS.            1 u   47  512  377   12.006    0.415   0.299
-ntp1.mmo.netnod .PPS.            1 u   67  512  377   20.919   -0.222   0.264
-ntp2.mmo.netnod .PPS.            1 u   44  512  377   20.808   -0.263   0.217
+ntp1.sp.se      .PPS.            1 u   32  512  377   17.369    0.084   0.199
+ntp2.sp.se      .PPS.            1 u   43  512  377   17.131    0.002   0.263
*GPS_JUPITER(0)  .GPS.            0 l   14   64  377    0.000    0.000   0.001

# ntptime
ntp_gettime() returns code 0 (OK)
  time c4a80538.8eb6f164  Tue, Jul 20 2004 22:55:20.557, (.557479878),
  maximum error 2934 us, estimated error 0 us, TAI offset -1073743080
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -0.023 us, frequency 37.670 ppm, interval 32 s,
  maximum error 2934 us, estimated error 0 us,
  status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
  time constant 7, precision 1.788 us, tolerance 496 ppm,
  pps frequency 37.670 ppm, stability 0.144 ppm, jitter 0.405 us,
  intervals 1751, jitter exceeded 3449, stability exceeded 44, errors 21.
In the output from 'ntptime' you can look at the status line. When everything has settled down the status should look like it does in the above output.

It is also possible to have a Jupiter GPS receiver output NMEA messages. However, this is not recommended, since the receiver outputs NMEA when everything else is done. They can be either 1+ seconds late or 2+ seconds late (it can vary based on time / day). Since there is no way the NMEA message can reliably tell what second a PPS edge belongs to, this GPS receiver is unusable for precision timing in NMEA mode.

-- BjornGabrielsson - 20 Jul 2004

Related Topics: JupiterRefclockUsers
Topic revision: r13 - 20 Sep 2022, DruLavigne
Copyright © by the contributing authors.Use of this website indicates your agreement with, and acceptance of, the PrivacyPolicy, the WikiDisclaimer, and the PrivateWebPolicy.