Spirent circle logo

Testing infinity: how to build a realistic GNSS test scenario


A holistic understanding of simulation components and their requirements for realism in GNSS lab-based testing is critical for choosing the right test platform in order to launch successful GNSS-enabled devices to market.

In the world of positioning, navigation, and timing there are infinite circumstances that can affect performance. Accounting for these factors in your testing is critical to bring products to market that are ready to perform in the real world. And having the capability to generate these scenarios can help you to save time and money in your testing by shifting a greater balance of your development regime into the lab.

What realism means in lab-based testing is the ability to access state-of-the-art simulated GNSS test environments which represent an optimal replication of the real-world environment, delivering heightened fidelity and realism. This optimal replication depends on the level of detail and performance in both digital and analogue domains. The characteristics of the signal are modelled in software in the digital domain, before being converted into analogue radio frequency (RF) signals that are transmitted on the appropriate frequency by the system hardware.

Identifying the array of considerations affecting the realism of lab-based simulation is key to having a holistic understanding of the requirements for this form of GNSS testing. These include:

  • Signal modeling

  • Constellation modeling

  • Space weather and atmospheric effects

  • Local environments

  • Vehicle modeling

Signal modeling

In GNSS testing, all simulation starts with the digital re-creation of the GNSS signals. If the signals are not accurately modeled in the simulator software, it may introduce inaccuracies into the test results. Each constellation’s interface control document (ICD) describes how the signal should be seen by the receiver, while accounting for real-world factors such as atmospheric interference, clock bias and ephemeris errors. A state-of-the-art simulator, however, will account for the fact that the parameters set out in the ICD may not always be “real” enough for the requirements of a particular test scenario. To learn more about signal modelling, read the blog Testing Infinity: Achieving realism in the lab through optimum simulator performance.


A state-of-the-art simulator… will account for the fact that the parameters set out in the ICD may not always be “real” enough for the requirements of a particular test scenario.

ICD implementation and constellation modeling

The implementation and maintenance of the most up-to-date details of the ICD is where realism becomes systematically layered into simulation. Staying current with ICD updates means the simulator is always generating signals that accurately reflect the real-world or planned operation of the constellation in question. This approach is suitable for the vast majority of cases, but not all. For example, orbital navigation data is typically populated in the simulator directly from the satellite motion definition in the ICD, and more complex test scenarios may expose limitations in this approach. In some cases, a more computationally intensive curve-fitting approach produces more ‘realistic’ results, by allowing users to see ephemeris and clock errors that are highly representative of those observed under live sky conditions.

Space weather and atmospheric effects

GNSS signals are subject to a variety of space weather and atmospheric interference effects. While ICDs provide mathematical models for simulating the impact of space weather and atmospheric interference, these cannot provide true realism since the real space weather environment is largely unpredictable and always changing. As a result, some test scenarios may require greater realism than is possible with standard simulator control software. In scenarios like these, the ability to model and simulate space weather and atmospheric effects more realistically in the lab lowers the cost of field testing and accelerates time to market.

Local environments

Numerous variables in the local environment impact a GNSS receiver’s performance, but not all simulators can model them in a realistic fashion. Key areas for consideration include:

Multipath and obscuration: Multipathed signals and signal blockages caused by structures in the environment occur differently everywhere and must be accounted for. Simulation software usually relies on statistical modeling to create multipath and obscuration effects for a generic ‘downtown location,’ but the patterns do not correspond to any real-world location. Using 3D environment modeling and ray tracing software to emulate the signal environment in geo-realistic locations, or specific places, helps bridge that gap in realistic simulations.

Multipathed signals and signal blockages caused by structures in the environment occur differently everywhere and must be accounted for.

Interference: A range of interference types impact receiver performance. This includes deliberate jamming and spoofing to out-of-band emissions from radio, TV, and cellular transmitters. Simulating these interference effects realistically in the lab provides critical insights into how to harden the receiver against real-world threats. Any comprehensive testing strategy for interference should include a continually updated library of observed jamming waveforms to incorporate in simulations.

Vehicle modeling

A new set of factors must be taken into account for receivers destined for use in a vehicle. The more realistically the vehicle’s array of unique characteristics and dynamics are incorporated into the simulator, the more accurate and insightful the test results will be. Key areas for consideration include:

  • Vehicle structure: GNSS signals may be blocked or multipathed by elements of the vehicle body in relationship to where the antenna is placed in or on the vehicle. Accurately modeling the overall characteristics of the vehicle – the receiver carrier – be it car, aircraft, spacecraft, or human, in relation to the antenna, provides a critical testing framework to help identify any potential issues.

  • Motion and trajectory: GNSS testing strategies must consider how the receiver performs when the vehicle is conducting numerous maneuvers. Simulated signals must keep pace with vehicle dynamics in scenarios such as quick acceleration and rapid changes of direction (jerk). The faster the simulator’s update rate, the more accurately it can plot the attitude and position of the vehicle. This is especially important for highly dynamic test scenarios.

  • Hardware-in-the-loop: To achieve realistic measurements when testing with hardware-in-the-loop (HIL), signal simulation must stay in sync with the motion and trajectory data generated by the hardware under test. Elevated levels of variance between the simulated signal and the trajectory of the vehicle as interpreted by the other elements in the HIL configuration will reduce the accuracy of the measurements, potentially producing misleading results.

Additional considerations in lab-based GNSS testing: Record & playback

Traditionally, record & playback is the primary method of bringing realism into the lab. In many ways, it represents the best of both worlds, combining the richness of the real-world environment with the repeatability needed for scientific lab testing. Capturing recordings of the real environment in various locations can significantly cut down on drive testing costs and timescales. Record & playback can also be extremely useful for testing devices designed to operate in one specific location.

As with simulation, the realism of a record & playback test configuration is governed by the performance and build standard of the RPS (record & playback system). To find out more about bringing realistic testing into the lab with record & playback, see our blog.

Choosing the right state-of-the-art – and scalable – test platform with the technology capable of addressing all the requirements outlined in this blog is the key to success for new GNSS launches.

To learn more about realism in GNSS testing, read Spirent’s eBook – Testing Infinity: How to create a realistic GNSS test environment.

Like our content?

Subscribe to our blogs here.

Blog Newsletter Subscription

Romain Zimmermann
Romain Zimmermann

Product Line Manager

Romain Zimmermann has worked on various aspects of PNT testing at Spirent, from product management to business development. He is currently responsible for Spirent’s inertial sensor simulation portfolio and has a particular interest in new PNT challenges brought by the development of applications such as autonomous vehicles, robots and 5G. Prior to his work at Spirent, Romain worked in mobile telecommunications as a product manager within network equipment manufacturers and service providers. Romain holds a MSc in Telecommunications Engineering from Telecom SudParis, in France.