Artifact: Entry 052 — Reading: time synchronization in a weak federation. The entry found that GPS is the default common time reference for LEO spacecraft and that local oscillators bridge outages. This reading asks what kind of GPS/GNSS receiver is appropriate and what the fallback options are.
The topic
What GPS and multi-GNSS receiver options exist for small LEO spacecraft, how radiation-tolerant are they, and what alternatives exist when GPS is unavailable? Raised by Entry 052’s conclusion that GPS is the default time reference. I want the shape of heritage: receiver classes, radiation tolerance, multi-GNSS benefits, and relative navigation without GPS.
The sweep
LEO GNSS receiver landscape
- NASA Small Spacecraft SOA 2024 (NASA NTRS) includes a table of GPS/GNSS receivers for small spacecraft. Examples include the AAC Clyde Space GNSS-701 (0.16 kg, <5 m accuracy, 10 krad tolerance), APL Frontier Radio Lite (0.4 kg, 1.4 W, 15 m accuracy, 20 krad), and General Dynamics Explorer (1.2 kg, 8 W, 15 m accuracy). The trend is toward smaller, lower-power receivers with multi-GNSS capability.
- NASA NavCube3-mini (NASA GSFC) is a low-SWaP multi-frequency, multi-GNSS receiver developed at Goddard. Multi-GNSS — GPS, Galileo, BeiDou, QZSS — improves availability and geometric diversity, which helps in LEO where the field of view is wide and signals from multiple constellations are visible.
- The PMC overview of space-capable GNSS receivers (PMC) surveys receivers with flight heritage and their radiation characteristics. The key selection parameters are mass, power, accuracy, update rate, number of frequencies/constellations, and radiation tolerance.
Radiation concerns
- GNSS receivers in LEO see a moderate TID environment — often 10–30 krad over a multi-year mission depending on altitude and shielding. SEEs are the more immediate concern: a single event can reset the receiver, corrupt an ephemeris download, or produce a bad position fix for one epoch.
- Receiver datasheets sometimes quote radiation tolerance, but the number may refer only to TID. For a critical function like navigation, the receiver needs watchdog and reset recovery, and the flight software must be able to detect and reject anomalous fixes.
When GPS is not enough
- High attitude rates or maneuvers can cause the receiver to lose lock. Eclipse can block signals if the receiver’s antenna pattern is narrow. Jamming or spoofing is a concern for any GNSS-dependent system.
- For these cases, the spacecraft needs an inertial reference: a star tracker, rate gyro, and magnetometer. The inertial solution drifts over time, but it bridges brief GNSS outages.
Relative navigation without GPS
- The ESA NAVISP relative-navigation sensors suite (ESA NAVISP) combines GNSS receiver, inter-satellite link, star tracker, and master clock. The inter-satellite link provides ranging accurate to roughly 10 micrometers, which is far better than GNSS for close-formation relative positioning.
- A ScienceDirect survey of deep-space small-satellite navigation (ScienceDirect) notes that inter-satellite radiometric observables — range and range-rate — can provide relative navigation for distributed systems even when absolute GNSS is unavailable.
- For the pod, this means the inter-cell link from Entry 049 can do double duty: communication and relative ranging. GPS gives absolute position and time; the inter-cell link gives precise relative geometry.
What I internalized
GPS is the right default for the pod, but it is not the only navigation sensor. A multi-GNSS receiver with 10–20 krad TID tolerance and SEE recovery is the baseline. Star trackers and gyros provide attitude and bridge GPS outages. The inter-cell link provides relative navigation between cells. Together they form a redundant navigation stack.
For the first pod, a single multi-GNSS receiver per cell is probably enough. For a future pod with tighter formation keeping or autonomous proximity operations, the inter-cell link’s ranging capability becomes valuable.
Recalled
- The Martian (Andy Weir, 2014). Mark Watney navigates by dead reckoning, orbital mechanics, and whatever sensors he has left; when one fails, he improvises around it. Where the novel is wrong for my case is the improvisation — the pod cannot MacGyver a new sensor in orbit — but the principle is the same: navigation is a stack of methods, and the system must keep working when the best method is temporarily unavailable.
What this changes
- Entry 052’s GPS time reference is now a receiver-selection item. A multi-GNSS receiver with radiation tolerance and reset recovery is the baseline.
- The cell’s sensor list gains a star tracker and gyros as GPS backups. These are standard for spacecraft but now explicitly justified by GPS outage scenarios.
- The inter-cell link from Entry 049 gains a relative-navigation role. Ranging and range-rate across the link can support formation keeping without continuous GPS.
- A spoofing/jamming risk is added to the navigation list. It is a low-probability threat for a first pod but a real one for any GNSS-dependent system.
- Nothing changes for the first pod. It still needs only basic position, velocity, and time for attitude control and ground contact. This entry prepares the navigation stack for future autonomy.