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.

By Linfinity GNSS | 6 min read

Most engineers think of GNSS as a positioning technology. You put a receiver in a device, it figures out where it is, and you use that location for navigation or tracking. Simple enough.

But there’s an entire class of GNSS receiver that doesn’t care where it is at all. Its only job is to know exactly what time it is — to within nanoseconds (only using 1 satellite).

These are timing GNSS receivers, and they underpin more of modern infrastructure than most people realise.

Why GNSS is a Time Technology First

Here’s something that surprises a lot of people: GNSS is fundamentally a timing system. Every satellite in a GNSS constellation carries an atomic clock and continuously broadcasts a timestamped signal. Your receiver calculates its position by measuring the tiny differences in arrival time between signals from multiple satellites (TOA) — and from those differences, computing where in space it must be for those delays to make sense.

Position is derived from time. Not the other way around.

This means a GNSS receiver with a known, fixed position can skip the positioning calculation entirely and focus entirely on extracting the most precise time signal possible. That’s exactly what a timing receiver does.

What Makes a Timing Receiver Different?

A standard GNSS receiver and a timing receiver might use the same satellite signals, but they’re optimised for completely different outputs.

The most important output of a timing receiver isn’t a coordinate — it’s the 1PPS signal: a single electrical pulse fired precisely on the second, every second, aligned to UTC. That pulse is what other systems lock onto.

What is 1PPS and Why Does It Matter?

A 1PPS (one pulse per second) signal is a hardware output — typically a 3.3V or 5V TTL pulse on a coaxial connector — that fires at the exact turn of each UTC second. The leading edge of the pulse is aligned to within tens of nanoseconds of true UTC.

Systems that need to be precisely synchronised — whether that’s two base stations in a telecom network or two sensors in a test range — can lock to the same 1PPS source and know they’re operating on the same timebase.

Think of it as a heartbeat for your infrastructure.

Where Are Timing GNSS Receivers Used?

The range of applications is broader than most people expect:

Telecommunications Mobile networks (4G/LTE, 5G) require base stations to be synchronised to within microseconds of each other. Timing receivers provide the UTC reference that keeps the whole network coherent. Without them, handoffs between cells fail and data packets collide.

Power grids Synchrophasors — devices that measure voltage and current phase across a power grid — must be timestamped with sub-microsecond accuracy to be useful. GNSS timing receivers provide that reference across geographically distributed substations.

Financial trading Regulatory frameworks (MiFID II in Europe, for example) require financial transactions to be timestamped to 100-microsecond accuracy or better. Trading systems use GNSS timing to comply and to resolve disputes about trade sequencing.

Test and measurement When you’re testing RF systems, radar, or communications equipment across multiple sites, you need a shared time reference. Timing receivers let distributed test equipment correlate measurements that were taken kilometres apart.

Data centres and distributed computing Accurate timestamps matter for database consistency, log correlation, and security certificate validation. GNSS timing feeds into network time infrastructure (PTP/IEEE 1588 or NTP) to keep server clocks honest.

Defence and SIGINT Direction finding, time-difference-of-arrival (TDOA) localisation, and electronic warfare all require precise time synchronisation across sensor networks.

The Role of the Oscillator

A timing receiver doesn’t just output 1PPS and leave it there. In most professional deployments, it also disciplines an oscillator — typically a temperature-compensated crystal oscillator (TCXO), oven-controlled crystal oscillator (OCXO), or Rubidium atomic clock.

Why? Because GNSS signals can be interrupted — by jamming, multipath, or simply a blocked sky view. When the GNSS signal is lost, the disciplined oscillator holds over, maintaining the timing reference using its own stability until GNSS is reacquired.

The quality of that holdover — how long the system can maintain accuracy without GNSS — is a critical spec for any resilient timing deployment. A basic TCXO might drift by microseconds within minutes. A Rubidium oscillator can hold nanosecond-level accuracy for hours.

Vulnerabilities: Timing Receivers and Spoofing

Because timing receivers are often fixed-position and deeply embedded in infrastructure, they present a specific spoofing risk that’s worth understanding.

An attacker who can spoof a timing receiver doesn’t need to move it — they just need to shift its time reference. Even a few microseconds of error injected into a telecom network’s timing can cause widespread service degradation. A few hundred microseconds can take down synchronised trading systems.

Unlike navigation spoofing (where position jumps are detectable), timing spoofing can be extremely subtle — shifting time gradually over hours to stay below alarm thresholds.

Mitigations include:

• Multi-constellation, multi-frequency receivers (harder to spoof all signals simultaneously)
• Galileo OS-NMA authentication
• Cross-checking against PTP grandmaster clocks or Caesium references
• Monitoring for abnormal signal characteristics even when the fix appears healthy

Choosing a Timing Receiver: Key Specs to Check

If you’re specifying or integrating a timing GNSS receiver, here are the parameters that matter:

• Time accuracy (RMS and peak): How close is the 1PPS to true UTC under normal conditions?
• Holdover performance: How does the system behave when GNSS is lost? What oscillator is used?
• Multi-constellation support: GPS only, or GPS + Galileo + GLONASS + BeiDou? More constellations means better accuracy and resilience.
• Frequency output: Does it also output a 10 MHz reference signal? Useful for disciplining lab instruments.
• Form factor: Rack-mount, DIN rail, or embedded module?
• Anti-spoof/anti-jam features: Especially important for infrastructure deployments.

Common platforms include the u-blox LEA-M8F and ZED-F9T modules at the embedded end, and rack-mount units from Microsemi (now Microchip), Trimble, and Meinberg at the infrastructure end.

The Bottom Line

A timing GNSS receiver is not a navigation device. It’s a precision time source — one that keeps telecoms networks running, power grids stable, financial markets compliant, and distributed sensor systems coherent.

If your system depends on accurate timestamps, synchronised measurements, or any form of distributed coordination, you almost certainly have timing GNSS receivers somewhere in your stack. Understanding how they work — and how they can fail — is increasingly essential engineering knowledge.

If you’re integrating, testing, or securing a timing-dependent system and need expert support, we’re here to help.

Talk to a GNSS timing expert → (AI) or send us an email to:

info@linfinityGNSS.com

Linfinity GNSS is a Cambridge-based team of precision positioning and timing engineers with 20+ years of hands-on experience. We support organisations across telecoms, defence, maritime, and autonomous systems.

Written by Linfinity GNSS | in GNSS Technical Articles 5 min read | June 2026

If you work with GNSS-dependent systems — whether in maritime navigation, autonomous vehicles, surveying, or critical infrastructure — you’ve probably heard both terms thrown around. But jamming and spoofing are fundamentally different threats, and confusing them leads to the wrong mitigation strategy.

Here’s what every engineer needs to know.

What is GNSS Jamming?

Jamming is a denial-of-service attack on your GNSS receiver. A jammer broadcasts radio frequency noise across the GNSS frequency bands (L1, L2, L5, etc.), overpowering the legitimate satellite signals. Your receiver can’t hear the satellites anymore — it simply loses its fix.

Key characteristics of jamming:

• Your receiver knows something is wrong. It reports a loss of signal or poor signal quality.
• It’s relatively unsophisticated — cheap jammers are widely available and are often used by truck drivers trying to defeat fleet tracking systems.
• The effect is local (typically a radius of a few hundred metres to a few kilometres depending on power).
• Detection is straightforward: a sudden drop in C/N₀ (carrier-to-noise ratio) across all satellites simultaneously is a classic jamming signature.

Real-world impact: A jammed system fails visibly. Navigation stops. Systems fall back to dead reckoning or raise an alert. It’s disruptive — but at least you know about it.

What is GNSS Spoofing?

Spoofing is far more dangerous. Instead of blocking satellite signals, a spoofer replaces them with counterfeit signals that your receiver accepts as legitimate. The receiver calculates a position — it’s just the wrong one.

Key characteristics of spoofing:

• Your receiver thinks everything is fine. It reports a healthy fix with good signal quality.
• The attacker has full control over where your receiver thinks it is — and can move that position gradually to avoid triggering alarms.
• Detection requires either multi-constellation/multi-frequency receivers, inertial sensor fusion, or cryptographic signal authentication (e.g. Galileo’s OS-NMA service).
• Sophisticated spoofing attacks can fool entire fleets simultaneously.

Real-world impact: Spoofed systems fail silently. A vessel navigating into the wrong shipping lane, a drone being redirected to a hostile location, a timing signal in a power grid being shifted — none of these trigger an obvious alarm. That’s what makes spoofing so serious.

A Quick Comparison

Where Are These Threats Happening Right Now?

Jamming and spoofing incidents have grown dramatically in recent years:

• The Baltic Sea and Eastern Europe have seen widespread GPS jamming affecting commercial aviation and maritime traffic, traced to military activity near conflict zones.
• The Black Sea has been an ongoing hotspot for GNSS spoofing since at least 2017, with vessels reporting false positions placing them at Sochi airport.
• The Middle East sees routine spoofing around certain airports, disrupting commercial flight management systems.
• Urban environments increasingly deal with low-level jamming from personal privacy devices (PPDs) — illegal in most jurisdictions but widely used.

This is no longer an edge case. If your system operates anywhere near geopolitical friction or high-density urban areas, you need to assume you will encounter both threats.

What Should Engineers Do?

For anti-jamming:

• Use a high-quality multi-band antenna with good ground plane isolation
• Monitor C/N₀ values in real time and log anomalies
• Implement automatic gain control (AGC) monitoring — a sudden AGC drop is an early jamming indicator
• Consider a multi-constellation receiver (GPS + Galileo + GLONASS + BeiDou) — jamming all bands simultaneously is harder

For anti-spoofing:

• Enable Galileo’s Open Service Navigation Message Authentication (OS-NMA) if your receiver supports it
• Fuse GNSS with an IMU — inertial data is impossible to spoof remotely
• Monitor for inconsistencies: signal level too high, too many satellites with perfect SNR, position jumps that disagree with velocity — these are red flags
• Use a receiver with built-in spoofing detection (some u-blox and Septentrio modules include this)
• For timing-critical applications, cross-check against an independent time source

The Bottom Line

Jamming is a blunt instrument. It causes obvious failures and is relatively easy to detect and mitigate. Spoofing is a precision weapon — it exploits your system’s trust in GNSS and can cause failures you won’t notice until serious damage is done.

Both threats are real, both are growing, and both require different engineering responses.

If you’re unsure how resilient your system is to either threat, that’s exactly what we’re here to help with. Our team has 20+ years of hands-on GNSS experience, from hardware integration through to live environment testing.

Talk to one of our experts →

Linfinity GNSS is a Cambridge-based team of precision positioning engineers specialising in GNSS integration, anti-jam, and anti-spoof systems. We work with organisations across maritime, defence, and autonomous systems.