Hardware and GNSS/PPS wiring#

Why#

Two distinct signals come out of the GNSS receiver, and they don’t play the same role: the serial stream (NMEA/UBX) gives an approximate time with a variable latency of several tens of milliseconds, while the PPS (Pulse Per Second) pulse marks the exact tick of the second with precision on the order of tens of nanoseconds. Wiring both correctly, and understanding why both are needed, is the prerequisite for everything else.

Hardware needed#

Nothing more is strictly required for a working Stratum 1, no HAT, no user-facing I2C bus, no external display clock.

Pick a GNSS receiver that exposes both a serial output (NMEA or UBX) and a separate hardware PPS pin. An “all-in-one” USB receiver without an exposed PPS will never reach microsecond-level precision: the USB port itself introduces several milliseconds of variable latency.

How: the wiring#

┌──────────────────────┐                      ┌────────────────────────────────┐
│    u-blox NEO-M9N    │                      │         Raspberry Pi 5         │
│   (GNSS receiver)    │                      │        (GPIO, 40 pins)         │
│                      │                      │                                │
│                  TX  │─────────────────────►│ GPIO15 / RXD0 (ttyAMA0)        │
│                  RX  │◄─────────────────────│ GPIO14 / TXD0                  │
│                 PPS  │─────────────────────►│ GPIO4  (pps-gpio)              │
│                 GND  │──────────────────────│ GND                            │
│                 VCC  │◄─────────────────────│ 3V3                            │
│                      │                      │                                │
│ [SMA] active antenna │                      │                                │
└──────────────────────┘                      └────────────────────────────────┘

• TX/RX (UART, ttyAMA0): carries NMEA/UBX frames (position, approximate date). This stream tells you which second just ticked.
• PPS (GPIO 4): one electrical pulse per second, aligned to the rising edge of the UTC second. This is what gives you precision.
• 3.3 V power only, never 5 V: the Pi’s GPIO pins do not tolerate 5 V inputs.

The Linux kernel handles PPS via the pps-gpio module, which fires a hardware interrupt (IRQ) on every rising edge and exposes the result as /dev/pps0. This is covered in detail in the GNSS/PPS acquisition chapter.

Pitfalls to avoid#

• Swapping TX and RX. Classic mistake: the receiver’s TX should go to the Pi’s RX, not to its own TX. If ttyAMA0 receives nothing, check this first.
• Antenna cable too long without compensation. Radio signal propagates at ~5 ns/meter through coax cable. Over a few meters the effect is negligible; beyond that, chrony lets you explicitly compensate for this delay (offset directive on the PPS refclock, see the Chrony chapter), but you need to measure the actual cable length first.
• Poorly placed antenna. A GNSS antenna needs a clear view of the sky. Behind a window facing open sky works fine (that’s the actual production setup for this project); enclosed in a metal case or in a basement does not.
• Forgetting the RTC backup battery. If the Pi uses a battery-backed real-time clock, it must be connected before the first boot to benefit from automatic trickle charging, otherwise the clock resets on every power loss, which delays acquiring the first GNSS fix after reboot.

Verify#

Before installing any software, two physical checks are enough at this stage:

1. Wiring continuity: using a multimeter, check for no short circuit between 3V3 and GND once the receiver is connected, before first power-up.
2. Receiver power: once the Pi has booted (with a minimal OS, see next chapter), the GNSS receiver should show an activity LED (depending on model) as soon as it acquires satellites, typically tens of seconds to a few minutes on a cold start.

Full software verification (ppstest, gpspipe) is covered in the GNSS/PPS acquisition chapter.

📚 Going further

• The PPS signal on modern u-blox receivers is aligned to the UTC second transition with ±10 to 30 ns precision (u-blox NEO-M9N manufacturer specifications).
• NMEA frame latency over serial (UART, 9600 baud) is on the order of ±10 ms, non-deterministic, as it depends on CPU load and UART buffering, which is structurally why PPS is required for any precision better than a millisecond. See Michael A. Lombardi et al. (NIST), Time and Frequency Measurements Using the Global Positioning System (GPS), 2001, on serial interface latency versus hardware PPS.
• The GPS L1 C/A navigation frame format (50 bit/s, 30 s frame) is specified in IS-GPS-200 (Interface Specification, latest revision N).