Introduction
"Understanding failure cases is essential for building reliable systems."
GNSS is a mature and highly capable technology, but it fails in the real world - sometimes subtly, sometimes catastrophically. The most dangerous failures are not outright dropouts, where the receiver reports no fix and the downstream system responds accordingly, but rather silent degradations, where the receiver continues to output a confident position solution that is silently wrong by metres or tens of metres. Engineers who design systems that depend on GNSS must understand the specific scenarios in which failures occur, what signatures those failures produce in receiver output, and how systems can be designed to degrade gracefully rather than fail dangerously.
Urban Navigation Errors
Urban environments are the most common source of sustained, systematic GNSS errors in commercial applications. The combination of signal blockage, multipath, and NLOS reception creates an error environment that is fundamentally different from open-sky conditions - and cannot be resolved simply by using a higher-quality receiver or additional constellations.
A characteristic urban failure scenario unfolds as follows: a vehicle enters a city street flanked by tall buildings. The receiver's visible satellite count drops from 20+ to 6–8. DOP rises from below 2 to above 6. Several of the remaining signals are reflections from building facades rather than direct LOS signals. The receiver, unaware that these are NLOS measurements, incorporates them into the navigation solution. The reported position shifts by 8–15 metres to one side of the actual road. The receiver reports no loss of fix, no quality alarm, and a full constellation - because from the receiver's perspective, it is successfully tracking multiple satellites with acceptable C/Nâ‚€ values. The error is invisible to any standard quality indicator.
Research conducted in Hong Kong urban canyons demonstrated horizontal positioning errors exceeding 13 metres RMS in NLOS-dominated environments, with individual position errors reaching tens of metres at specific epochs. Studies in Tokyo confirmed that dense urban environments can produce RTK fixed solutions with large absolute errors - the integer ambiguity is resolved, but resolved incorrectly due to NLOS contamination, producing a wrong-but-confident position output.
RTK Losing Fix
RTK positioning depends on resolving carrier-phase integer ambiguities, and this process is highly sensitive to signal interruptions, cycle slips, and multipath. Several well-documented scenarios cause RTK to lose its fix status:
- Passing under a bridge or overpass: All satellite signals are interrupted simultaneously. The receiver must completely re-initialise its ambiguity resolution when it emerges. Depending on receiver design and satellite geometry, re-convergence to RTK fix can take anywhere from a few seconds to several minutes. During this re-initialisation period, the system reverts to float or code-phase positioning with metre-level accuracy. Research from a Chicago autonomous vehicle study found that RTK fix was never fully re-established after overpass passages within the observation windows tested.
- Entering a tunnel: Complete GNSS outage. Systems without IMU integration have no position reference during tunnel traversal. On exit, RTK re-initialisation is required.
- Extended baseline distance: RTK accuracy degrades at approximately 1 ppm per kilometre of distance from the reference station. Beyond 10–20 km, atmospheric decorrelation between base and rover becomes significant, and fix status may be lost as residual atmospheric errors exceed the ambiguity resolution threshold.
- Heavy tree canopy: Signal attenuation through dense vegetation causes C/Nâ‚€ to drop across multiple channels simultaneously. Cycle slips occur on individual satellites, invalidating their ambiguity values. If enough satellites slip cycles, the ambiguity set is corrupted and RTK fix is lost.
- Multipath-induced cycle slips in urban canyons: Strong reflected signals cause the PLL to slip cycles without the receiver detecting the event. The corrupted ambiguity then either propagates errors into the solution or triggers a reset when the inconsistency is detected through post-fit residuals.
Sudden Position Jumps
Position jumps are discrete, instantaneous displacements in the reported position that do not correspond to any physical movement of the receiver. They are one of the most operationally disruptive GNSS failure modes because they inject a large, sudden error into the navigation solution without warning. Common causes include:
- Ambiguity re-resolution in RTK: When a new set of integer ambiguities is resolved after a disruption, the solution can jump by centimetres to decimetres if the new ambiguity set corresponds to a slightly different position than the previous one.
- Satellite set change: When a satellite rises or sets and is added to or removed from the navigation solution, the geometry changes discontinuously. If the new satellite carries a multipath-contaminated measurement, the solution can jump.
- NLOS satellite incorporation: If an NLOS signal is suddenly acquired and included in the solution - for example, as a vehicle clears a corner and a reflected signal becomes trackable - the incorrect range measurement can shift the position solution by several metres.
- Stale correction data: In RTK systems using cellular-delivered NTRIP corrections, a temporary loss of connectivity can cause corrections to become several minutes old. When fresh corrections resume, the solution may jump as the accumulated correction drift is applied.
A North American highway GNSS study covering 27,500 km of driving found that only 55% of positions achieved better than 10 cm horizontal accuracy, and that correction outages of several minutes occurred in 3% of observations due to cellular network gaps, each producing a correction jump on reconnection.
Ionospheric and Solar Events
Less frequent but highly impactful are GNSS degradation events caused by solar activity and ionospheric disturbances. During periods of high solar activity, ionospheric scintillation can cause rapid fluctuations in signal amplitude and phase across large geographic areas. Unlike urban multipath, these events affect all satellites simultaneously and cannot be mitigated by better antenna placement or receiver design. The effects include rapid C/Nâ‚€ fluctuations, cycle slips on multiple channels, and in severe cases, complete loss of carrier-phase lock across an entire constellation for periods of minutes to hours. Such events are unpredictable and can affect open-sky receivers that perform perfectly under normal conditions.
Lessons for System Design
The common thread across all real-world GNSS failure cases is that the receiver continues to operate normally while the position output is wrong or uncertain. Designing reliable systems requires acknowledging this reality and implementing appropriate protective measures:
- Integrity monitoring: Implement receiver autonomous integrity monitoring (RAIM) or advanced fault detection algorithms that use solution residuals to identify and exclude anomalous measurements.
- Sensor fusion: Integrate IMU, wheel odometry, or other positioning sensors so that brief or extended GNSS outages can be bridged without position discontinuity.
- Quality gating: Define and enforce thresholds on PDOP, C/Nâ‚€, fix status, and satellite count. Do not pass GNSS positions downstream to safety-critical functions unless all thresholds are met.
- Coasting and fallback modes: Define graceful degradation behaviour - how the system behaves when GNSS quality drops below acceptable thresholds - and test these fallback modes explicitly.
- Logging for post-event analysis: Record raw receiver output including individual satellite measurements, fix status, and quality indicators. Post-event analysis of failure cases is essential for improving system design.
The professionals who build the most reliable GNSS-dependent systems are not those who assume the technology will always work - they are those who have thoroughly studied how and why it fails, and have designed their architectures accordingly.