GNSS Record & Replay vs Simulation vs Field Testing: Which Method Should You Use?

GNSS Record and Playback vs Simulation vs Field Testing

Compare the source of the stimulus, the variables you can change and the system boundary you actually exercise. Repeatability describes how well an input can be repeated; controllability describes which parts can be varied independently.

Both replay and simulation can support regression. Neither guarantees identical DUT outputs across runs; preparation, oscillator state, internal noise, scheduling and measurement uncertainty still matter.

How Each GNSS Testing Method Works

RF record and replay: reuse a captured input

A recorder samples the signal passing through a defined antenna and RF chain within selected bands. Playback reconstructs those samples as RF for a receiver. The dataset can retain composite fades, multipath and interference that passed through the capture system, subject to its bandwidth, gain, quantization and continuity.

The recording is a reusable stimulus, not a guarantee that a field failure will recur. See the GNSS RF recording and playback workflow for capture, verification and replay responsibilities.

GNSS RF simulation: generate a defined scenario

A simulator computes RF signals from scenario settings and supported models. Engineers can construct nominal and stressed cases, vary a selected factor, use known scenario truth and supply real-time motion where supported. The model must represent the mechanism being investigated.

Real-time RF simulation delivers the stimulus in step with the bench timeline; closed-loop use also requires timely response to state updates. It does not mean live-sky reception. Use GNSS simulation fundamentals and the scenario design guide to define the inputs.

Field testing: exercise the installed system

Field tests include the installed antenna, housing, vehicle or platform, onboard electronics and operating procedures. They can reveal interactions outside a laboratory model. Satellite geometry, propagation and local activity may differ between runs, so use documented routes, environmental observations and suitable references.

Field A/B comparisons can be designed usefully, including simultaneous observations where practical. Document installation differences and changing conditions rather than assuming two trips present the same input. GPS.gov describes several real-world influences on user accuracy.^[5]

RF Samples Are Different from Receiver Logs and Route Files

Terminology varies. Safran’s GSG documentation, for example, describes a “Record and Playback” option that converts recorded NMEA messages into generated scenario, trajectory and event files.^[4] Confirm whether a proposed workflow replays sampled RF or regenerates signals from logged information.

For sample-data exchange, retain the format, sample rate, center frequency, real/complex representation, quantization, packing, byte order and time mapping. The ION GNSS SDR Metadata Standard provides a framework for describing sampled signal data; format compatibility with the chosen playback equipment still needs confirmation.^[1]

An estimated route can also contain receiver errors and latency. Validate it before using it as scenario truth. The GNSS receiver processing guide explains how observations and PVT are produced.

What Does a GNSS Recording Preserve—and Where Are Its Limits?

RF replay preserves the captured representation, not every physical condition around the vehicle. Qualify the capture chain before relying on a dataset.

I/Q precision and quantization are capture-design choices, not simply file-size settings.^[2] Keysight’s recorder documentation also illustrates the roles of gain records, dynamic range and replay-level controls. Those implementation details do not establish the capabilities of another product.^[3]

Changing playback power does not independently change every signal

Ordinary gain or attenuation applied to a composite recording scales its recorded signal, noise and interference components together. Additional bench and receiver noise also affects the result. Do not assume a 1 dB playback change produces exactly a 1 dB change in receiver-reported C/N₀, or that it independently edits one satellite’s power. Verify the delivered input and observed receiver response.

Conducted replay and OTA test different boundaries

The capture antenna’s response is embedded in the recording. Connecting the replay output to a DUT RF port bypasses that DUT’s present antenna and its surroundings. OTA testing can include an antenna, but its spatial, polarization and multipath coverage depends on the chamber and radiating architecture. Do not assume a single radiating source recreates the original multi-direction field.^[6]

Check storage rate as well as capacity

For N equal-rate complex streams with b bits for each I and Q component, the uncompressed sample payload rate is:

R = N × sample rate × (2 × b) ÷ 8 bytes/second

Illustrative calculation: two streams at 25 million complex samples/second, with 8-bit I and 8-bit Q, produce 100 MB/s and 180 GB in 30 minutes, using decimal units. This excludes headers, padding and auxiliary data; actual formats, compression and packing change storage needs. These values are not SSR8000 or MZ product specifications.

Why Might the Same RF File Fail to Reproduce a Field Issue?

A negative replay result does not prove the field report was wrong. Check the experiment before drawing a receiver conclusion.

1. Missing input: the relevant band, antenna path, correction stream or inertial input was not captured.
2. Capture damage: clipping, unsuitable quantization, a clock problem or sample gaps changed the stimulus.
3. Different RF delivery: gain mode, cable loss, attenuation, noise or receiver input configuration differs.
4. Different DUT state: firmware, retained navigation data, reset method, filter state or assistance differs.
5. Insufficient lead-in: starting just before the event does not recreate the receiver’s earlier acquisition and filter history.
6. Epoch mismatch: recorded GNSS time conflicts with current assistance, corrections or time assumptions.
7. Different system boundary: power, thermal, antenna, platform or application behavior caused or contributed to the field failure.

Use the original recording epoch when aligning truth and supporting streams. Keep archived correction data synchronized and valid for that epoch, or deliberately define an unaided test. Check segment and loop boundaries rather than assuming continuous time and motion.

Once the bench input is validated, a repeatable failure shows that the tested input and DUT conditions are sufficient to reproduce the observed behavior. It does not, by itself, identify a unique physical cause.

Choose the Method by the Engineering Question

Requirements or applicable procedures may prescribe a particular setup. Method selection alone does not establish certification or compliance. Use the receiver validation test plan to connect the requirement, test case and evidence.

A Practical Field-to-Lab Validation Example

Suppose a vehicle loses a valid GNSS solution near a building at t=420 seconds in a 900-second drive. The following is an illustrative investigation workflow, not a measured customer case.

1. Field discovery: preserve the RF capture, DUT outputs, event interval, installation details and independent truth. Retain correction and inertial streams if the system uses them.
2. Capture validation: verify required bands, sample continuity, overload status, metadata and the mapping between RF time and logs.
3. Replay comparison: start A/B runs from the same declared capture point with sufficient lead-in and matched preparation. Compare the event using frozen validity and error rules; retain unsuccessful reproductions too.
4. Controlled hypotheses: use simulation to vary suspected masking, multipath or interruption conditions separately. A simulated match supports a mechanism under the model; additional evidence is needed to attribute the field cause.
5. Regression and field confirmation: retain the useful capture and simulation cases, then test the revised installed system on representative routes.

This sequence can run in either direction. A development program may establish simulation baselines before field discovery. The important link is traceability between the field observation, the replay dataset, the controlled hypothesis and the final decision.

Keep the Measurement Method Consistent

Define receiver initialization, accepted solution modes, truth, timestamps, event windows and failure handling before comparing results. Use the same metric definitions across methods while stating differences in conditions and measurement uncertainty.

For replay accuracy, compare the receiver’s reconstructed route with truth from the original capture interval, not the physical location of the laboratory bench. A DUT’s own position log is an output under evaluation, not independent truth. Repeating one recording measures behavior conditional on that captured input; those repeats are not independent samples of different field environments.

Separate first tracking return, first valid PVT and recovery meeting an accuracy or dwell requirement. Retain timeouts, missing outputs and failed preconditions alongside successful trials. Report error distributions and threshold availability where relevant, rather than only averages. The GNSS accuracy metrics guide defines the main quantities.

Match the Test Method to the Right System

Use the test boundary to choose a product family. Confirm current signals, RF architecture, interfaces, models and data formats against the project brief.

NSG2000

Consider for focused civil-signal receiver development, debugging and portable bench workflows. Confirm the required signals, trajectory method, models and integration options.

Review NSG2000 →

NSG8000

Consider for broader multi-constellation/frequency scenarios and advanced HIL architectures. Confirm independent RF views, timing requirements and optional functions for the selected configuration.

Review NSG8000 →

SSR8000

Consider for laboratory acquisition, stored RF datasets and replay-based receiver regression. Confirm simultaneous bands, sampling, storage, replay levels and reference interfaces.

Review SSR8000 →

For portable route capture, compare MZ302P for a single antenna path with MZ303P for two synchronized antenna paths. Timing synchronization alone does not establish the relative-phase performance needed by every heading or array test; confirm the intended multi-antenna measurement.^[6]

Explore the recording and playback product family, GNSS simulation systems and simulator selection guide. For integration planning, use the receiver development and HIL solution.

What to Confirm Before Selecting a Test System

For recording and replay

Provide the event or route objective; DUT and firmware; exact signals; antenna paths; required bands and usable bandwidth; expected duration; and supporting data. Confirm sample format and precision, gain/dynamic-range requirements, sustained storage rate, capture integrity indicators, replay compatibility, RF levels and timing references.

Include initialization and lead-in needs, historical epoch handling, independent truth and synchronized corrections or sensors. State which inputs must be replayed and which system functions remain live.

For generated simulation

Provide the exact signal set, scenario epoch, motion source, required models and deliberate parameter changes. Specify independent RF views, DUT connections, truth/logging and automation. For HIL, add protocol, coordinate frame, units, timestamps, update cadence, timing target and late-input policy.

For field confirmation

Define representative routes and operating conditions, installed hardware, reference quality, event logging, repeat procedure and how weather, sky visibility, traffic or platform changes will be recorded. Set the acceptance basis before reviewing results.

GNSS Record, Replay and Simulation FAQs