How GNSS constellations broadcast time#

Why#

This guide uses the generic term “GNSS” (Global Navigation Satellite System) rather than “GPS”, because the receiver used here, like most modern receivers, isn’t limited to the American constellation: it can receive GPS, Galileo, GLONASS, and BeiDou simultaneously. Understanding how these systems actually broadcast time, and how a receiver extracts both its position and the exact time from the same signal, helps diagnose reception issues and understand why some of this project’s settings are what they are.

The four major constellations#

All are Medium Earth Orbit (MEO) constellations, positioned so a ground receiver constantly sees several satellites from each system at once, an essential prerequisite for computing a position, as explained below.

The receiver used in this project (u-blox NEO-M9N) can receive up to four constellations simultaneously. More visible satellites means better computation geometry (lower DOP, Dilution Of Precision) and greater resilience if part of the sky is obstructed.

How a satellite broadcasts time#

Each satellite carries two to four atomic clocks (rubidium and/or cesium; Galileo additionally uses passive hydrogen masers, even more stable). These clocks are kept aligned to each system’s own time scale (GPS Time, Galileo System Time, etc.) by a ground control segment, with precision on the order of tens of nanoseconds.

Each satellite continuously broadcasts a navigation message containing, among other things:

• Its precise position at a given instant (ephemeris)
• The exact time of that instant, per the satellite’s clock
• Correction parameters for the satellite’s clock relative to the system’s time scale
• An almanac (approximate positions of every other satellite in the constellation)

On GPS, for instance, this message is broadcast at 50 bits per second; a complete frame is 1500 bits, i.e. 30 seconds, split into 5 subframes.

GNSS time scales (GPS Time, Galileo System Time…) are continuous: they don’t apply the leap seconds periodically added to UTC. The navigation message includes the current offset between system time and UTC, which lets the receiver (and chrony downstream, via the leap-seconds.list file, see the Chrony chapter) do the conversion.

How a receiver computes position AND time#

This is the commonly misunderstood part: a GNSS receiver does not initially know the exact time, its internal clock (a cheap oscillator) is potentially off by several milliseconds. It must therefore solve simultaneously for two unknowns: where it is (3 coordinates) and what its own clock’s offset is (1 unknown), 4 unknowns total.

Each satellite received provides one equation: the apparent distance (pseudorange) between satellite and receiver, derived from the radio signal’s travel time. Since there are 4 unknowns, a minimum of 4 simultaneously visible satellites is required for the system of equations to be solvable. That’s where this project’s practical requirement (see the Final verification chapter) of at least 8 satellites used comes from, a comfortable margin above the theoretical minimum, to absorb measurement noise and less-reliable low-elevation satellites.

                           ┌────────────────────────┐
                           │  4 visible satellites  │
                           └────────────────────────┘
                                        │
                                        ▼
                        ┌───────────────────────────────┐
                        │  4 pseudo-range measurements  │
                        │     (signal travel time)      │
                        └───────────────────────────────┘
                                        │
                                        ▼
                    ┌──────────────────────────────────────┐
                    │  System of 4 equations, 4 unknowns:  │
                    │    • receiver position X, Y, Z       │
                    │    • receiver clock offset dt        │
                    └──────────────────────────────────────┘
                                        │
                                        ▼
               ┌────────────────────────────────────────────────┐
               │  Simultaneous solve → position AND exact time  │
               └────────────────────────────────────────────────┘

Once this system is solved, the receiver knows its position and UTC time with typical precision of tens of nanoseconds on the timestamp, this is the time subsequently broadcast on the PPS pin (Hardware and wiring chapter) with even better precision, since PPS doesn’t need to carry position information, only the second tick.

Common misconceptions#

• “PPS gives the complete time.” Wrong: PPS only gives a precise second transition tick, not which second, nor which date. That information is carried by the NMEA/UBX stream, with much lower precision (see the Wiring chapter). That’s why chrony needs both streams in parallel.
• “More GPS satellites is always better than mixing constellations.” Generally wrong: mixing constellations improves reception geometry (more satellites spread across the sky) and resilience, at the cost of extra complexity (each system has its own time scale, which the receiver must convert internally).
• “Without a satellite fix, the receiver returns nothing.” Wrong, see the GNSS/PPS acquisition chapter: the receiver keeps emitting NMEA frames with empty fields and an “invalid” status until it gets a fix, which can be confusing without an explicit check of the status.

Verify#

# Interactive view of currently tracked satellites, by constellation
cgps -s

# Raw per-constellation detail (gnssid identifier):
#   0 = GPS, 1 = SBAS, 2 = Galileo, 3 = BeiDou, 5 = QZSS, 6 = GLONASS
gpspipe -w -n 5 | grep -o '"class":"SKY".*'

On an indoor antenna sitting near a window (this project’s actual production setup), it’s common to see a dozen satellites used, spread across 2 to 3 different constellations.

📚 Going further

• The GPS L1 C/A navigation message format (1575.42 MHz frequency, CDMA coding, 50 bit/s) is specified in IS-GPS-200 (Interface Specification, latest revision N).
• Onboard atomic clocks are kept aligned to International Atomic Time (TAI) within ±10 ns by the ground control segment (Schriever Space Force Base, Colorado, and sites distributed worldwide). See P. Misra, P. Enge, Global Positioning System: Signals, Measurements, and Performance, 2011, chapter 2.
• The principle of simultaneous position/time resolution via 4-unknown multilateration is described in detail in the same book, as well as in NAVCENTER documentation (US Coast Guard Navigation Center, the historical operator of public GPS information).