Introduction

Some years ago my father in law was cleaning out his workshop and gave me a Rockwell Jupiter GPS module dating back to the late 90s. More recently I decided to see if I could get it running. The exact model number is TU3-D165-001 which was released in 1998. The manufacture date code on my module is is 9907, which is the week of 15-21 February 1999. The PCB silk-screen proudly announces: “Made in USA”.

Nowadays, with the ubiquity of GNSS-enabled devices (phones, cars, wrist watches…), the bar for doing something interesting with a discrete GPS module is high (Cf. high-altitude balloon experiments) so the best thing I could come up with was to make a stratum-1 NTP server.

Hardware hook-up

Some kind soul has kept the the datasheet available on the web. This document provides the pin-out for the connector and other vital information (like this specific module being the 3.3V version - hence the separate buck-converter).

I soldered a bridge between pin 7 (GPIO2/NMEA select) and ground, and besides for power (pins 1 and 4 to 3.3V, and 17 to PSU ground) the rest is just hook up between the boards:

• Module pin 11 (TX1) to UART RX on the Pi
• Module pin 12 (RX1) to UART TX on the Pi
• Module pin 19 (1PPS) to a GPIO pin on the Pi
• Module pin 20 (GND) to ground on the Pi

The GPS requires an active antenna (one that contains a pre-amp powered by DC bias provided on the connector).

Resurrection

I applied power and it sputters to life at 4800 baud from its long sleep:

$PRWIRID,12,01.80,12/08/98,0003,*42
$GPGGA,,,,,,0,00,,,,,,,*66
$GPGSA,,,,,,*42
$GPGGA,,,,,,0,00,,,,,,,*66
$GPGSA,A,1,,,,,,,,,,,,,2.57,0.88,2.41*07
$GPGSV,3,1,12,03,57,197,00,16,42,135,,01,41,316,,21,33,358,*7D
$GPGSV,3,2,12,07,30,253,,08,28,356,,27,27,061,,26,23,143,*7D
$GPGSV,3,3,12,04,21,171,,22,06,093,,09,01,218,,32,00,076,*75
$GPRMC,070319,V,0424.9765,N,15609.5929,E,0.000,0.0,090802,6.6,E*6D

This module supports saving useful initial conditions and information about the GPS constellation to non-volatile or super-capacitor-backed S-RAM for faster time-to-first fix, but we have no such luxury, so it wakes up assuming the date is 12/08/98 (presumably the nonsensical American notation for 8 December 1998 - a date likely hard coded in the firmware).

The datasheet quotes a cold-start time-to-first fix of 2 to 2.5 minutes, but suggests that not having valid EEPROM data is considered “frozen start” (no timing provided). I think I waited about 20 minutes for a fix, but it eventually happened! GPSD decodes and displays the position/time information from this ancient relic:

┌──────────────────────────────────────────────────────────────────────────────┐
│Time: 2022-03-27T06:26:49.000Z Lat:  27 17' XX.XX020" Son: 153 03' YY.YY999" E│
└───────────────────────────────── Cooked TPV ─────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│ GPGGA GPGSA GPGSV GPRMC PRWIZCH                                              │
└───────────────────────────────── Sentences ──────────────────────────────────┘
┌──────────────────┐┌────────────────────────────┐┌────────────────────────────┐
│Ch PRN  Az El S/N ││Time:      062649           ││Time:      062649           │
│ 0   3 237 80  43 ││Latitude:     27XX.XX17 S   ││Latitude:  27XX.XX17        │
│ 1  16  65 49  44 ││Longitude:   153YY.YY50 E   ││Longitude: 153YY.YY50       │
│ 2   4 210 47  30 ││Speed:     0.000            ││Altitude:  4.3              │
│ 3  26 113 41  42 ││Course:    0.0              ││Quality:   1   Sats: 05     │
│ 4   1 325 23  33 ││Status:    A       FAA:     ││HDOP:      1.04             │
│ 5   9 238 20   0 ││MagVar:    11.2 E           ││Geoid:     37.6             │
│ 6  31 135 15   0 │└─────────── RMC ────────────┘└─────────── GGA ────────────┘
│ 7   7 302  9   0 │┌────────────────────────────┐┌────────────────────────────┐
│ 8  22  94  7  29 ││Mode: A3 Sats: 3 16 4 26 1  ││UTC:           RMS:         │
│ 9  21 353  7   0 ││DOP: H=1.04  V=1.57  P=1.89 ││MAJ:           MIN:         │
│10   6 225  5   0 ││TOFF: > 1 day               ││ORI:           LAT:         │
│11                ││PPS:                        ││LON:           ALT:         │
└────── GSV ───────┘└──────── GSA + PPS ─────────┘└─────────── GST ────────────┘

(Coordinates slightly obfuscated. If you can figure out where I live based on the Az/El/SV number/timestamp, please come over for a beer!)

With the Linux PPS driver configured to monitor the correct GPIO pin, we also get a 1 pulse per second heartbeat:

# ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1680138798.844018524, sequence: 171811 - clear  0.000000000, sequence: 0
source 0 - assert 1680138799.844014116, sequence: 171812 - clear  0.000000000, sequence: 0
source 0 - assert 1680138800.844012521, sequence: 171813 - clear  0.000000000, sequence: 0
source 0 - assert 1680138801.844011342, sequence: 171814 - clear  0.000000000, sequence: 0

So does it work?

Besides GPS being generally impressive technology, I’m blown away by the fact that a quarter of a century later, the Navstar system is way more capable and yet still backwards compatible with some of the earliest commercial receivers. Those of you who (like me) enjoy reading retro-computing blogs will have noticed that moderately old computers (say, a machine running Windows 95 and the Netscape browser of that vintage) aren’t really usable on the modern web.

To a first approximation, Rockwell’s Jupiter GPS (and the Zodiac chipset from SiRF) is an old computer. On the other hand - this is an embedded system, and the tech was built to last since (despite definitely being consumer electronics) it was used for safety-critical applications. It still (mostly) works!

Modern GPS receivers leverage network connectivity to obtain data that it would otherwise have to receive from the satellites at a very slow speed. This is called Assisted GPS (A-GPS). While the Jupiter module doesn’t support A-GPS, providing backup power to persist ephemeris data speed up obtaining a fix considerably.

Y2K-ish problem

One other issue I noticed is that once it gets a fix, the time is correct (this is required as GPS cannot function without accurate time) but the date is wrong. According to this page:

After power-on and then acquiring satellite lock, the displayed date (via the RS-232 port) is exactly 1024 weeks earlier than the true date.

This first came to light on 2015 Feb 15 [Sun], GPS Week 1832, after some 20 years of normal behaviour, and appears to be due to the inability of the firmware of older Jupiters to retain the last used date in its EEPROM.

However, the Jupiter GPS receiver’s ‘Scorpio’ DSP engine is processing the satellite signals correctly; acquisition of satellites, generation of hardware 1PPS and 10 kHz output signals are perfectly OK. The GPSDO produces its precise 10.0 MHz output as normal.

If your application does not use the RS-232 data stream, NO action is required. If otherwise, you might want to reset the date.

The author goes on to describe a work-around to correct the reported date in NMEA mode by sending a reset command with the current date to the GPS.

The Rockwell Jupiter legacy

SiRF, the designers of the Zodiac chipset were the first to commercialise GPS technology after it was declassified by the DoD. Speaking of retro-computing: one of SiRF’s founders (Dado Banatao) has a connection to the Steves via the Homebrew Computer Club. SiRF continued to make GNSS chipsets until they were gobbled up by Qualcomm in 2015.

My module was made by Rockwell Semiconductor Systems, Inc, which was spun off into Conexant a few weeks before the manufacture date. Then in 2002 Conexant sold their GPS module business to Navman New Zealand. Navman struggled for some years before dying but the GPS module business was passed into a separately owned division until Telit acquired (and as far as I can tell, finally consumed) the Jupiter brand in 2012.

The NTP server

After fighting with ntpd for a bit, I discovered chrony which is a breath of fresh air. I was able to combine an external battery backed RTC on the Raspberry PI with the GPS/1PPS for time sync (modulo the date issue). It does work, but after some reading about timing issues with the Jupiter NMEA mode, I’m not convinced using the end result is accurate enough to be worth the fuss.

Conclusion

Let’s be honest, no-one really needs a stratum-1 NTP server at home. As such, this is a “me also” project and if I was really dedicated to precise time (I’m not) I would be better off buying a modern u-Blox multi-constellation GNSS module. It was fun though, and I would encourage anyone who has the inclination to explore retro-electronics.