By Linfinity GNSS | 7 min read
Spirent simulators are the gold standard for GNSS receiver testing. The GSS7000, GSS9000, and their predecessors have been used to qualify receivers for everything from consumer devices to defence-grade navigation systems. When used well, they give you repeatable, controllable test conditions that live-sky testing simply can’t match.
When used poorly, they give you false confidence — and receivers that pass the lab but fail in the field.
After 20+ years of GNSS integration and testing work, here are the mistakes we see most often.
1. Not Accounting for the RF Cable Loss Budget
This is the most common and most damaging mistake. GNSS signals arrive at your antenna at around -130 dBm — already extremely weak. The moment you introduce an RF cable between your Spirent output and your receiver under test, you’re attenuating that signal further.
Engineers frequently connect a Spirent output directly to a receiver via whatever cable is to hand, without measuring or compensating for the loss. A 5 dB loss in the cable means the receiver is seeing a significantly weaker signal than the simulator intended — your C/N₀ figures are wrong, your acquisition times are artificially degraded, and your test results don’t reflect the scenario you thought you were simulating.
Fix: Always measure your cable loss before running a test. Enter the measured loss into Spirent’s signal power offset so the simulator compensates. For longer cable runs, use a low-loss cable and a calibrated inline amplifier.
2. Ignoring the Antenna Gain Pattern
Spirent simulators output signals that represent satellites at specific azimuth and elevation angles. But most bench test setups feed that signal directly into the receiver’s RF input — bypassing the antenna entirely.
In the real world, your antenna has a gain pattern. A satellite at 10° elevation looks very different to your receiver than one at 80° elevation, because the antenna attenuates low-elevation signals. If your test doesn’t model this, you’re testing a receiver that sees all satellites equally — which never happens in deployment.
Fix: Either use Spirent’s antenna modelling feature (available on higher-end systems) to apply a measured antenna pattern to the simulation, or be explicit in your test report that antenna effects are excluded and account for this in your field validation plan.
3. Using Default Simulation Scenarios Uncritically
Spirent ships with a library of default scenarios. They’re very useful for getting started, but they’re not exactly a substitute for a scenario matched to your actual deployment environment.
The default scenarios typically simulate ideal open-sky conditions with a clean constellation. If your product is going into a maritime environment, an urban canyon, a forest canopy, or a high-dynamic aircraft, the default scenario tells you almost nothing about how it will actually perform.
Fix: Build custom scenarios that reflect your real operational environment. This means correct geographic location, correct time of year (constellation geometry varies), correct dynamics (static, pedestrian, vehicle, aircraft), and appropriate signal degradation (multipath, atmospheric models). Spirent’s SimGEN or MANIAC software gives you full control — use it.
4. Not Validating the Simulator Output Before Testing
Simulators are complex RF systems. Firmware updates, hardware faults, connector wear, and misconfiguration can all cause a Spirent to output something other than what you think it’s outputting.
We’ve seen test campaigns invalidated because nobody verified the simulator’s output with a known-good reference receiver before starting. The receiver under test was blamed for poor performance that was actually a simulator configuration error.
Fix: Before every test campaign, connect a known-good reference receiver to the Spirent output and verify that it acquires the expected constellation, reports the expected position, and shows healthy C/N₀ values across all channels. Log this as your baseline. It takes 10 minutes and has saved us from very expensive mistakes.
Also make sure you have the latest Spirent FW version that include all the required fixes
5. Overlooking Multipath Simulation
Real-world GNSS environments are full of reflected signals. Urban buildings, ship superstructures, vehicle bodywork, and ground reflections all create multipath — signals that arrive at the antenna via indirect paths, causing ranging errors.
A simulation without multipath will make almost any receiver look good. Add realistic multipath and the picture changes dramatically, particularly for low-cost receivers that lack robust multipath mitigation.
Fix: Use Spirent’s multipath simulation capabilities to add reflected signals at appropriate delays and power levels for your target environment. For maritime testing, model reflections from the vessel superstructure. For urban testing, use a ray-tracing model if available, or manually add reflectors at representative geometry.
6. Testing Only Steady-State Performance
Many test plans focus on steady-state accuracy — how well does the receiver perform once it has a stable fix under nominal conditions? This is important, but it misses the failure modes that matter most in deployment.
What happens during initial cold start? How quickly does the receiver reacquire after a signal outage? How does it behave during a high-dynamic manoeuvre? What happens at the edge of the visibility mask when satellites are rising and setting?
Fix: Structure your test plan around transitions and corner cases, not just steady/simple state. Include cold start, warm start, and hot start scenarios. Simulate signal outages of varying duration. Test at the boundaries of your operational envelope — maximum speed, maximum acceleration, minimum satellite visibility.
7. Not Testing Interference Scenarios
If your receiver will be deployed anywhere near RF-noisy environments — and most will — testing it in a clean simulation environment gives you an incomplete picture.
Spirent systems support the injection of interference signals: wideband noise, narrowband CW interference, chirp jammers, and (on appropriate systems) spoofing scenarios. Most teams don’t use these capabilities because setting them up takes more effort. That effort is worth it.
Fix: Define the interference environment your product will actually encounter. A maritime receiver needs to be tested against the RF environment of a working vessel — radar, AIS, VHF comms, satellite comms all coexist in a noisy RF environment. An automotive receiver will encounter LTE and 5G interference from nearby devices. Characterise the interference, model it in Spirent, and test against it.
8. Treating Lab Results as Field Validation
This is the overarching mistake that all the others contribute to. A Spirent simulation, however well designed, is a model of the world — not the world itself. It can’t capture everything: antenna installation effects, vehicle body shielding, local RF environment, real atmospheric conditions on a specific day, or the interaction between your GNSS receiver and the rest of your system’s electronics.
Lab results tell you your receiver is capable of meeting your requirements under controlled conditions. They do not tell you it will meet them in the field.
Fix: Plan for a structured live-sky validation phase after lab testing. Use the lab results to define what you’re looking for in the field — specific metrics, specific scenarios — and then go verify them. Treat discrepancies between lab and field results as data, not anomalies to be explained away.
Getting the Most from Your Spirent Investment
Spirent simulators are expensive and great pieces of testing equipment. The teams that get the most value from them are the ones that invest as much thought in test design as they do in the hardware itself — building scenarios that reflect reality, validating their setup before every campaign, and treating lab testing as one part of a broader validation strategy rather than the whole story.
If you’re planning a GNSS receiver test campaign and want to pressure-test your approach, or if you’re seeing results that don’t make sense, we’re happy to take a look.
Talk to a GNSS testing expert → (AI but you can also contact us:
info@linfinityGNSS.com
Linfinity GNSS is a Cambridge-based team of precision positioning engineers with 20+ years of hands-on GNSS integration and testing experience. We work with organisations across maritime, defence, automotive, and autonomous systems.
Leave a Reply