GNSS Simulation Scenario Design for Repeatable Receiver Testing

What Is a GNSS Simulation Scenario?

The RF stimulus combines scenario time, satellite geometry and navigation data, receiver motion, enabled signals, power, propagation and scheduled disturbances. DUT reset commands, external aiding, truth files and scoring rules belong to the wider test setup; they are not all encoded into the GNSS RF signal.

Keep three records distinct: what was configured, what the bench actually delivered, and how the DUT responded. A saved scenario file alone does not prove that the RF level, receiver state or event timing was correct during a run.

For background, see what GNSS simulation does. For repetitions, reporting and program-level acceptance, continue to the receiver validation test plan.

Define the Required Inputs Before Building the Scenario

Start with One Test Objective and a Controlled Comparison

Write a question that identifies the change and the observable outcome: “After a 10-second complete GNSS outage, does this firmware regain a qualified GNSS position within the declared recovery window?” This is more actionable than “test urban performance.”

Build a clean baseline first. For a paired open-loop comparison, hold the epoch, prescribed trajectory, navigation data, RF path, DUT preparation and scoring method fixed, then change the intended factor. Record every deliberate difference.

When adding a constellation or removing satellites, the available geometry and solution population can change. Report those changes; do not claim that DOP remained constant merely because the route was unchanged. In closed-loop tests, DUT response may change the subsequent path, so preserve external conditions and record the actual trajectory.

Design the Trajectory, Dynamics and HIL Timing

Choose static, file-driven or real-time motion

Use a static point for initial acquisition and isolated RF-event checks. Use a prescribed trajectory for repeatable turns, climbs, acceleration and regression. Use a real-time motion interface when an external model supplies the state during execution.

Supply the fields required by the chosen interface. Some models derive velocity or acceleration from waypoints; others accept timestamped state vectors. Attitude, angular rates and antenna lever arms matter when the antenna model, multiple antennas or integrated navigation requires them. They are not mandatory inputs for every static receiver test.

Check frame, units, monotonic timestamps and interpolation. Plot speed, acceleration and jerk as well as the map trace, and confirm that supplied derivatives describe the same motion. Trajectory-generator documentation illustrates how interpolation and constraints affect the resulting path and dynamics.^[1]

Separate timestamps, transport and RF applicability

A real-time stream is not automatically a closed loop. The loop closes when DUT or controller response influences subsequent simulated motion or environment.

For HIL, distinguish the epoch when a motion state is valid, packet arrival, processing deadlines and the epoch of the corresponding RF output. Specify the common time reference, update cadence, interpolation or extrapolation limits, and missing, late or out-of-order packet policy. Safran’s Skydel documentation provides one implementation example; its policies and timing values are not specifications for other simulators.^[2]

Specify Exact Signals, Delivered RF Power and Visibility

Name signals such as GPS L1 C/A, GPS L5 I/Q or Galileo E1 B/C, including the components required by the test. Confirm that the DUT, simulator configuration and licenses support the same set. Use the signals, bands and codes guide and constellation comparison when preparing the brief.

Specify power at a named reference plane, preferably the DUT RF input, and state whether a value applies per satellite signal or to a composite. Account for cables, splitters, attenuators and active components. A receiver’s reported C/N₀ is a diagnostic observation, not a universally exact substitute for a calibrated RF power setting.

Useful profiles include steady nominal power, gradual attenuation, short dips and per-satellite changes. For visibility events, identify the satellites, azimuth/elevation mask, antenna/body mask or obstruction model involved. A low elevation mask alone does not create a complete urban multipath environment.

Add Error and Environment Models in Controlled Stages

After validating the nominal baseline, introduce an isolated stressor, then a combined operational case. Keep the model name, version, parameters and event schedule with the scenario.

• Atmosphere: identify ionospheric and tropospheric models and the receiver’s corresponding correction settings.
• Orbit, clock or range faults: define the affected satellite, fault magnitude, step or ramp, onset and restoration. Keep truth, broadcast navigation data and correction streams consistent with the intended fault; coherent changes can otherwise hide it.
• Multipath: define reflected-path delay, relative power, phase evolution and whether line of sight remains. Preserve stochastic settings where used.
• Obscuration and outages: specify partial versus complete removal, affected ports, RF suppression and restoration behavior.
• Integrated navigation: declare which inertial, odometry or correction inputs continue through a GNSS outage, with their synchronization and error models.

For the underlying error mechanisms and budget assumptions, use the GNSS error sources and error-budget guide.

Worked Example: A 300-Second Test with a 10-Second GNSS Outage

This engineering example isolates recovery after a complete RF interruption. The times, power and thresholds below are illustrative design choices, not measured results, universal acceptance limits or NSG product specifications.

Common configuration for baseline A and outage B

• Reference: 300 seconds beginning at 2026-10-01 00:00:00 GPST. Use one frozen navigation dataset valid for that epoch and archive its identity.
• Motion: static WGS84 geodetic latitude 22.5431°, longitude 114.0579°, ellipsoidal height 50 m. The truth point is the simulated antenna reference point.
• Signals: GPS L1 C/A only; use the same saved satellite selection and 5° elevation-mask configuration in both runs. Verify adequate nominal geometry before execution.
• RF path: one conducted DUT input, calibrated to −130 dBm per enabled satellite signal at that input. Use a bench configuration capable of delivering and verifying this level.
• Models: retain the same documented nominal propagation settings; disable added multipath, injected faults and stochastic stressors.
• DUT: apply the same receiver-documented cold-reset procedure before each run and record the state checks. Disable external assistance, corrections, inertial and odometry inputs. This example does not score TTFF.
• Logs: request 10 Hz measurement-epoch-tagged PVT, validity/solution mode and satellites-used information, plus tracking diagnostics, simulator truth and RF event records.

Save A and B as separate scenario revisions. The intended difference is that A remains at nominal RF power, while B mutes all enabled simulated GNSS signals during 120 ≤ t < 130 seconds. Scenario time continues. Do not reset the DUT during the interruption.

Define “qualified recovery” before running

For this example, each qualifying output must be a receiver-valid 3D GNSS solution using at least four GPS satellites, with horizontal error ≤2.5 m against epoch-aligned truth. Exclude dead-reckoned or propagated-only modes. Map these conditions to the DUT’s documented status fields.

Score in measurement time. Require output age at reception to be ≤0.2 seconds using an independently aligned logger clock. A qualifying sequence must span at least 2.0 seconds at the requested 10 Hz cadence, with no missing scheduled output and no inter-epoch gap above 0.15 seconds. Any nonqualifying output breaks the sequence. Apply these output conditions to the pre-outage window as well.

Record three separate milestones: first tracking return, first fresh receiver-valid PVT, and completion of the qualified recovery dwell. Only the last milestone decides this example’s recovery pass/fail.

Before interpreting the DUT result, verify RF suppression, restoration timing and log coverage against declared bench tolerances. If the stimulus or evidence is invalid, mark an input/setup failure rather than a receiver recovery failure.

Map Each Scenario Event to a Measurable KPI

Check each log’s timestamp meaning rather than using host packet arrival as the measurement epoch. NovAtel’s documentation, for example, distinguishes measurement-based synchronous logs from other timestamp conventions.^[3] Reacquisition also needs a declared restoration event and valid-navigation endpoint.^[4]

Use the GNSS metrics guide for metric definitions and the receiver processing guide to distinguish tracking, observations and PVT.

Save a Reproduction Package and Validate the Inputs

Retain more than the scenario filename

Archive a manifest with scenario ID/version; start epoch and time scale; frames, units and reference points; configuration and trajectory files with checksums; exact signals and navigation data; event definitions; model settings; and simulator hardware, software and license versions.

Include RF routing and calibration, DUT firmware and preparation records, external aiding settings, truth, raw receiver logs, timing records, run status and the scoring-script version. Preserve random algorithm and seed settings where available. A fixed seed reproduces a particular model realization; a declared seed set provides broader stochastic coverage. Seeded sensor-model documentation is an implementation example, not evidence that every RF simulator exposes the same controls.^[5]

Separate scenario acceptance from DUT acceptance

1. Validate imported data: frames, height convention, units, time scale, timestamp ordering and state consistency.
2. Validate signal delivery: enabled signals, navigation-data validity, per-signal RF level, path losses and actual event transitions.
3. Validate timing and evidence: truth coverage, log cadence, missing samples, timestamp mapping and HIL packet handling.
4. Confirm DUT preparation: reset success, retained data, aiding/corrections and preconditions.
5. Then score receiver behavior: apply the frozen KPI rules and retain setup failures, precondition failures, timeouts and successful trials with separate counts.

Repeatable scenario inputs do not guarantee bit-identical DUT outputs. Receiver oscillator state, internal noise, scheduling and preparation can still vary. Preserve the experiment controls and measure that variation through the declared trial plan.

Example GNSS Simulation Scenario Matrix

Use these families to organize coverage. Each row needs its own input manifest, event schedule and acceptance rule; the matrix itself is not an executable configuration.

Match the Scenario to the Simulator Configuration

Turn the scenario brief into a configuration review. Start with the exact signals, required models, independent RF views, trajectory interfaces and evidence outputs; choose the platform after those requirements are clear.

NSG2000 · Compact Receiver Engineering

Consider NSG2000 for portable bench work, receiver debugging and focused repeatable tests. Check the required civil signals, trajectory workflow and environment models against the selected configuration.

Confirm optional closed-loop or differential functions separately, together with interface and logging requirements.

Review NSG2000 configuration details →

NSG8000 · Advanced Scenario and HIL Workflows

Consider NSG8000 for broader constellation/frequency requirements, advanced receiver development and HIL test architectures.

Confirm independent RF outputs, per-output motion, timing performance, optional integrated-navigation functions and the required signal configuration for the project.

Review NSG8000 configuration details →

Product selection does not establish test-method compliance or certification. Confirm the current configuration, calibration, applicable procedure and evidence requirements. Compare the GNSS signal simulation products, read how to choose a GNSS simulator, or explore the receiver development and HIL solution.

If the test also needs captured field environments, compare RF record/replay, GNSS simulation and field testing. Browse industry applications to connect the scenario brief with its operating context.

GNSS Scenario Design FAQ