GNSS Simulator vs GNSS Emulator: What Is the Difference?

What Do GNSS Simulator and GNSS Emulator Mean?

In an RF receiver laboratory, a GNSS signal simulator normally generates satellite-like navigation signals from a defined scenario. The receiver processes those signals through its own RF and navigation chain. In software development, GNSS simulation can also mean generating measurements or position estimates without generating RF.

GNSS emulator needs the supplier’s definition. It can describe RF test hardware, a simulated receiver connection or another substitute for part of a navigation system. It is not a reliable standalone specification of the output interface.

Official documentation shows why the labels overlap

• RF hardware called an emulator: Keysight describes its PNT emulator hardware as generating RF signals, with simulation software controlling scenarios.^[1]
• Receiver-output playback called an emulator: Trimble Access documents a GNSS emulator that simulates a receiver connection using prerecorded receiver outputs, with limits on responses to real-time commands.^[2]
• Non-RF modeling called GNSS simulation: MathWorks documents a GNSS sensor model that produces position and velocity readings.^[3]

These examples show that the label does not establish a consistent RF-versus-software boundary. Compare the documented outputs and supported workflows of the specific tools.

Compare the Output and Injection Point

Work backward from the function you need to evaluate. Injecting data after a processing stage bypasses that stage in the DUT, even if the test model includes a mathematical representation of it.

IF = intermediate frequency; I/Q = in-phase and quadrature samples; PVT = position, velocity and time. A receiver must expose a compatible input for data injection; a serial connector alone does not establish that capability.

GNSS-SDR’s documentation illustrates the distinction between raw sample input and later acquisition, tracking, observable and PVT processing blocks.^[4] See how a GNSS receiver works for the processing chain.

The same data format can have different roles

An NMEA position file can be a trajectory input to an RF simulator, which then generates satellite signals. NMEA messages can also be injected directly into an application as substitute receiver outputs. The file extension does not identify which path is used: ask what is connected to the DUT.

Likewise, an I/Q file can contain synthesized samples or a captured RF event. Its origin and its playback interface are separate questions. Reconstructing RF from I/Q needs suitable playback hardware and calibration; an I/Q file is not itself an RF output.

Example: Two Tests Called a “GNSS Outage”

Consider a navigation application that must handle a temporary loss of usable GNSS. The following illustrative tests answer different questions; neither is a product specification or a measured result.

Test A: substitute receiver messages

A message source supplies valid positions, then marks fixes invalid for a defined interval, then resumes valid output. This can test whether the application recognizes the validity fields, displays the required state and restricts dependent functions. A separate case can stop messages to test timeout behavior.

The physical receiver’s reception and navigation processing are bypassed. The result supports an application-interface claim, rather than a receiver reacquisition or RF-sensitivity claim. Include realistic timestamps and quality/status fields, rather than changing latitude and longitude alone.

Test B: interrupt the RF stimulus to a real receiver

A conducted RF setup provides a defined GNSS signal scenario, removes the specified signals for the event and restores them under documented conditions. The real receiver decides what to output during the interruption and recovery; the test logger observes its fix status, timestamps, measurements and application response.

Define which signals disappear, what aiding or other sensors remain available, the receiver’s starting state and the recovery criterion. A GNSS/INS unit may continue to output a fused position while satellite signals are absent. Valid-looking PVT alone does not prove GNSS tracking has recovered.

Detailed event timing belongs in the scenario design guide; repetitions, thresholds and reporting belong in the receiver validation test plan.

Does “Emulator” Mean Hardware-in-the-Loop?

No. Software/hardware implementation, the DUT interface and feedback architecture are separate properties. A software-based signal-generation engine can use RF hardware to stimulate a physical receiver. A hardware message source can still bypass that receiver entirely.

Separate scripted input, live input and closed-loop feedback

• Scripted or open-loop execution: follows a prescribed scenario without DUT/controller response changing the subsequent simulated motion.
• Real-time external motion input: accepts live states from another model. This alone does not establish feedback from the DUT.
• Closed-loop HIL: DUT/controller outputs affect the model, which changes later states and the stimulus delivered back to the hardware.

A GNSS simulator can participate in any supported architecture. USB/Ethernet remote control, an API or trajectory-file import does not by itself establish real-time closed-loop performance.

Define the timing boundary

For a live-motion interface, specify when a state is valid, when it must arrive and when the corresponding stimulus applies at the DUT input. Confirm update cadence, latency, jitter, clock mapping and late/missing-packet behavior. A stated update rate is not a latency specification.

Safran’s Skydel HIL documentation provides an implementation example involving timestamped motion data, a common time reference and configured RF-generation latency.^[5] The required values must come from your system timing budget and the proposed configuration.

For sensor fusion, also define the inertial or other sensor interfaces, errors, reference points and synchronization. Generating GNSS RF does not automatically supply IMU data, correction messages or a vehicle model. Use the GNSS HIL testing solution to map those responsibilities.

Six Questions to Ask About a GNSS Simulator or Emulator

1. What output will my DUT receive? Identify RF, digital samples, observables, PVT or a proprietary protocol, including the physical connector and data specification.
2. Which parts of my DUT remain under test? Name the real RF front end, tracking loops, navigation estimator, fusion software and application components. Mark every bypass.
3. Which inputs and effects are controllable? Request exact GNSS signals/components, motion, signal levels and applicable error models. Distinguish generated parameters from logged diagnostics.
4. How does time and feedback work? Specify offline versus real-time execution, state epochs, deadlines, feedback path and evidence for the required timing performance.
5. What configuration and external equipment are required? Identify licenses, RF paths, references, sensor/correction sources and integration work. Multiple connectors or channels do not prove independent or phase-coherent antenna views.
6. What demonstration supports my acceptance claim? Agree a representative case, stimulus checks, DUT logs, reference truth and scoring method before treating the advertised capability as project coverage.

Specialized requirements need their own evidence. RTK testing needs consistent reference/rover and correction conditions; carrier-phase heading needs the appropriate antenna views and relative phase; interference/spoofing testing needs defined stimuli and suitable source coordination. Neither product label confirms those capabilities.

Use how to choose a GNSS simulator for the full equipment-selection checklist. Keep this terminology comparison as the first step in defining the test boundary.

Choose the Next Step from Your Test Requirement

If the objective is to reproduce a captured field event, compare RF record/replay, simulation and field testing. Replaying receiver messages, replaying captured RF and rerunning a synthesized scenario are different operations.

GNSS Simulator vs Emulator FAQ