Introduction
"GNSS behaviour changes when the receiver is moving."
Most GNSS receiver specifications are derived from static or low-dynamic testing. When a receiver is mounted on a moving platform - a road vehicle, agricultural robot, unmanned aerial vehicle, or industrial automated guided vehicle - the physical dynamics of motion introduce additional challenges that stress signal tracking loops and can cause significant performance degradation. Understanding how receiver dynamics affect GNSS performance is essential for engineers developing navigation solutions for any mobile system.
How Motion Affects Tracking
A GNSS receiver tracks satellites using internal feedback loops: a Delay Lock Loop (DLL) for code phase and a Phase Lock Loop (PLL) for carrier phase. These loops are designed to follow the changing signal parameters - code delay, carrier frequency, and carrier phase - as both the satellite and receiver move. In a static receiver, the dominant source of change is the satellite's orbital motion, which is slow and predictable. In a dynamic receiver, the receiver's own motion introduces additional, potentially rapid changes in the Doppler frequency and code delay of each tracked signal.
The tracking loop must be designed with sufficient bandwidth to follow these changes. A narrow loop bandwidth provides good noise rejection but slow response to dynamics; a wide bandwidth responds quickly to dynamics but accepts more noise into the measurement. This fundamental trade-off means that no single fixed loop configuration is optimal across all dynamic conditions, which is why adaptive and assisted tracking architectures have become the focus of considerable research and commercial development.
Acceleration, Jerk, and Vibration
Three categories of dynamic loading challenge GNSS tracking in vehicles and robots:
- Steady-state acceleration: Sustained acceleration in a fixed direction (e.g., cornering at constant speed, or a vehicle on a banked road) creates a persistent frequency offset in the carrier-phase tracking loop. Third-order PLLs are insensitive to constant velocity and acceleration but respond to jerk (the rate of change of acceleration). Platforms with high and variable jerk - such as vehicles navigating in stop-start urban traffic - stress even third-order loops.
- Sinusoidal vibration: Mechanical vibration from engines, road surfaces, or rotating machinery modulates the oscillator frequency, introducing periodic phase errors in the PLL. The effect is amplified when vibration frequencies coincide with the loop filter bandwidth.
- Random vibration: Of all dynamic load types, random broadband vibration produces the greatest frequency jitter and has the most severe impact on tracking stability. Vehicles traversing rough terrain, UAVs in turbulent air, and industrial robots on vibrating factory floors all exhibit this type of loading. Random vibration causes the greatest frequency deviations of the receiver's reference oscillator, which directly translates to tracking instability.
Rapid Signal Environment Changes
Dynamic platforms do not only introduce mechanical stress - they also move through environments where signal visibility changes rapidly. A vehicle travelling at 60 km/h passes a building obstruction in less than a second. The receiver must reacquire and integrate new satellites, recalculate geometry, and resolve carrier-phase ambiguities, all while tracking remaining satellites through rapid Doppler changes. In urban environments, this creates a continuously changing satellite constellation that conventional scalar tracking architectures handle less effectively than vector tracking approaches.
Vector Tracking Loops (VTLs) couple the tracking of all satellites through a shared navigation filter rather than tracking each channel independently. This coupling means that if most channels are tracking well, they can assist a temporarily degraded channel - preventing loss of lock that would occur in an equivalent scalar system. Research has confirmed that VTL-based receivers maintain tracking through dynamics that cause scalar tracking systems to lose lock and require re-acquisition periods of several seconds.
Real-Time Constraints
Dynamic navigation applications impose strict latency requirements. A vehicle control system typically requires position and velocity updates at 10–100 Hz with latencies of less than 100 milliseconds. Standard GNSS position output rates of 1–10 Hz are often insufficient, and the computational overhead of advanced processing algorithms must not introduce unacceptable latency.
IMU-aided GNSS is the standard architecture for high-rate dynamic positioning. The IMU provides high-frequency inertial measurements that propagate the position solution between GNSS updates, while GNSS corrections prevent IMU drift from accumulating. The tightness of the integration - from loosely coupled (position-level fusion) to tightly coupled (measurement-level fusion) - determines how well the system performs during partial GNSS outages.
Practical Design Considerations
For engineers deploying GNSS in dynamic systems, the following principles apply:
- Select receivers with adaptive tracking loop bandwidth or vector tracking architectures for high-dynamic applications
- Characterise the vibration spectrum of the platform and verify that the receiver's oscillator vibration sensitivity does not degrade performance in the dominant vibration bands
- Use a tightly coupled GNSS/IMU integration to maintain positioning through brief satellite outages and high-dynamic manoeuvres
- Ensure the GNSS antenna is mounted rigidly and with vibration isolation if necessary to minimise mechanical coupling of platform vibration into the antenna element and cable
- Validate tracking stability through field testing under representative dynamics, not just static bench tests
- Monitor PLL lock status and C/Nâ‚€ variation in real time - both indicate tracking stress before full loss of lock occurs
The performance gap between a GNSS receiver on a static tripod and the same receiver on a dynamic mobile platform can be substantial. Treating dynamic deployment as a simple extension of static performance is a common engineering error with significant consequences for system reliability.