A resilient GNSS receiver evaluation should answer a narrow engineering question: under controlled and repeatable conditions, what does the receiver report, how does the connected platform react, and what evidence supports recovery after an adverse event? A bench test is not a field-performance guarantee. It is a documented comparison method for the exact receiver, antenna path, firmware, configuration, interfaces and platform logic under review.
NIST’s Foundational PNT Profile uses the Identify, Protect, Detect, Respond and Recover functions to frame responsible use of positioning, navigation and timing (PNT). The U.S. Department of Homeland Security Resilient PNT Conformance Framework is outcome-based and distinguishes resilience levels according to application need. DHS best practices also call for well-defined output observables, adversity reporting and recovery capabilities. These references support a risk-based test plan; they do not certify any ResiNav product or replace current product documentation.
1. Define the decision before choosing a test
Start with the platform decision the test must support. Examples include comparing two receiver configurations, confirming whether a controller recognises a receiver status change, checking whether an alarm reaches the operator interface, or documenting the conditions required before the platform returns to its normal navigation mode.
Write the acceptance question in observable terms. “The receiver is resilient” is not testable by itself. A useful statement identifies the input condition, the receiver output or platform response to observe, the time base, the permitted state transitions and the evidence that will be retained.
For interface responsibilities, review the GNSS receiver compatibility guide and the ResiNav Technology Centre.
2. Freeze the test article and configuration
A repeatable result needs an exact configuration record. Before the first run, identify the receiver model, hardware revision, firmware, enabled constellations and frequency bands, message set, update rate, dynamic model, elevation mask, time output, antenna, cable, connector, power supply, controller software and logging configuration.
Record every change between runs. If firmware, antenna gain, cable loss, interface rate or platform filtering changes, treat the result as a new configuration rather than combining it with the previous baseline. Store configuration exports where the receiver supports them and retain screenshots or command transcripts only when they do not expose credentials.
3. Establish a clean baseline
The baseline run shows whether the bench, cabling, power and logging system are stable before an adverse condition is introduced. Capture receiver status, tracked constellations and signals, reported solution state, time status, output message age, interface errors, power events and the platform’s selected navigation source.
Use a documented signal source or a lawful reception setup suitable for the facility. Note test-equipment calibration state, attenuation, distribution losses, clock reference and ambient RF conditions. A baseline that already contains resets, dropped messages or unstable power cannot be used to attribute later behaviour to the intended test condition.
4. Separate receiver observables from platform conclusions
DHS best practices recommend that PNT user equipment expose adequate observables and state information for test and evaluation, including detected anomalies or threats where the equipment supports such reporting. Capture the receiver’s documented outputs without inventing meanings for undocumented fields.
- solution type, validity and integrity-related status;
- tracked signals, measurements or reported RF power indicators where available;
- message age, sequence and update interval;
- time status and 1PPS relationship where used;
- receiver alarms, resets and reacquisition states;
- serial, Ethernet or other interface errors;
- platform source selection, mode, alarm and operator notification.
A platform alarm is evidence of a platform decision, not proof of the RF cause. Likewise, a receiver status field does not prove that the controller consumed or acted on it correctly.
5. Build one time-aligned event record
Recovery cannot be measured reliably when the signal source, receiver, controller and operator interface use unrelated clocks. Define the test time scale, timestamp resolution and synchronisation method before collection. Retain the original time stamps and document any later alignment or resampling.
Place event markers at the beginning and end of each controlled condition. Correlate them with receiver status, message delivery, controller decisions, complementary sensors and operator alarms. If the platform uses GPS time, UTC, a local clock or a network time source, document the conversion and known offsets.
6. Use controlled, lawful adverse conditions
GPS.gov states that intentional use of jamming devices is unlawful in the United States, and similar restrictions apply in many jurisdictions. Never radiate an unauthorised jammer or spoofing signal in an open environment. Conduct RF adversity testing only in an authorised, controlled facility using compliant signal-generation, shielding, conducted injection or approved simulation methods.
Adverse conditions should be traceable and repeatable. Examples may include a documented signal interruption, attenuation profile, interface disconnection, power event, invalid or delayed message sequence, or simulated input defined by an approved test vector. The selected condition must match the engineering question; not every receiver or platform should be exposed to every scenario.
7. Measure detection and response separately
Detection is the interval between the defined event marker and a documented receiver or platform indication. Response is the subsequent action, such as rejecting the input, changing source, limiting operation, notifying the operator or entering a safe state.
Report both intervals with the associated configuration and observation method. Do not publish a single timing number as a universal product specification. The value can depend on signal condition, receiver settings, message rate, interface latency, controller logic and the platform’s own persistence filters.
8. Define recovery before running the test
Recovery is more than the first valid coordinate after an event. DHS guidance describes recovery as restoration to nominal operation and performance after an adverse event. For a platform test, define the receiver and platform conditions that must be satisfied before normal use resumes.
- receiver status and time state;
- stable message delivery for a specified observation period;
- interface health and absence of repeated resets;
- agreement with complementary sensors where the system uses them;
- controller source-selection and mode state;
- alarm acknowledgement and retained event evidence.
Record reacquisition, stabilisation and platform re-entry as separate events. This prevents a short-lived output from being mistaken for a controlled return to service.
9. Create a bench-test evidence matrix
| Evidence group | Record for every run | Question answered |
|---|---|---|
| Configuration | Receiver, firmware, antenna, cable, bands, interfaces and platform build | Can the setup be reproduced? |
| Baseline | Signal source, receiver state, time status, power and interface health | Was the bench stable before the event? |
| Adverse condition | Authorised method, event markers, level or profile and duration | What input condition was actually applied? |
| Detection | Receiver fields, platform alarms and timestamps | When was the condition recognised? |
| Response | Source selection, control mode, operator notice and safety action | Did the platform follow its approved logic? |
| Recovery | Reacquisition, stable observation, alarm clearing and return criteria | Was return to service controlled? |
10. Compare runs without overstating the result
Use the same configuration, event profile, timing reference and acceptance rules for repeated runs. Report the distribution of observations, not only the best run. Keep failed and inconclusive runs with their reason codes. If a run is excluded, document the exclusion before reviewing the outcome.
A bench comparison supports an engineering review for the tested configuration. It does not establish performance for another antenna position, cable, receiver, firmware, platform, RF environment or operating policy. Field verification remains necessary for the target installation.
11. Convert results into integration and RFQ inputs
Provide the receiver model and documentation, constellations and bands, antenna and cable constraints, power and interfaces, required messages, time outputs, platform mode logic, acceptance questions and evidence format. State whether the need is an antenna, terminal or system-level integration review.
Browse the ResiNav product catalogue, then use the RFQ form to request an engineering review. Product compatibility and deployment suitability must be confirmed against the current product documentation and the target platform.
Frequently asked questions
Does a successful bench test prove field resilience?
No. It documents behaviour for the tested configuration and controlled conditions. Installation, RF environment, firmware, receiver settings and platform logic can change the result, so field verification remains necessary.
Should recovery time be measured from the end of interference to the first position output?
Not by itself. Record receiver reacquisition, stable status, interface delivery, platform source selection and the approved return-to-service condition as separate events.
Can an open-air jammer be used for receiver testing?
No unauthorised jamming or spoofing signal should be radiated. Use a lawful, controlled facility and an approved conducted, shielded, simulated or test-vector method.
What should an OEM provide for a receiver evaluation?
Provide the receiver and firmware, constellations and bands, antenna and cable, power and interfaces, required observables, platform logic, authorised test conditions, acceptance questions and the required evidence format.
Engineering references
- NIST: Responsible Use of Positioning, Navigation and Timing Services
- NISTIR 8323 Rev. 1: Foundational PNT Profile
- DHS: Resilient PNT Conformance Framework
- DHS: Best Practices for Resilient PNT
- GPS.gov: Information About GPS Jamming
Next step
To review receiver, antenna, interface and evidence requirements for a controlled evaluation, request a ResiNav engineering review.
NEXT STEP
Turn available platform information into an engineering review.
Use the Technology centre to frame the discussion, review relevant application scenarios, then send the available platform and receiver details for confirmation.