Resilient GNSS Receiver Evaluation: Bench Tests for Interference and Recovery

Before commissioning a GNSS evaluation, check what is actually connected. A receiver-only demonstration does not validate a disconnected antenna. Choose the test scope for the item you intend to buy, then use the repeatability and recovery method below.

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.

Before selecting test equipment, separate anti-jamming, RTK receiver processing and correction delivery so that the evaluation covers the function being purchased.

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.

When commissioning the signal source, compare RF record and replay with generated GNSS scenarios to decide which capture, playback and scenario-generation functions the evaluation actually needs.

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.

When comparing mitigation configurations, examine measurement bias as well as tracking availability and the required position or timing output.

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. Choose a test that includes the item you are buying

A receiver-only demonstration cannot validate a physical anti-jamming antenna that was not in the test path. Before paying for an evaluation, identify the device under test (DUT) and the point at which simulated signals enter it. “Conducted” and “over-the-air” describe different test boundaries, not two interchangeable grades of the same result.

Keysight’s CRPA testing explanation distinguishes cable-fed testing that bypasses the physical antenna from radiated testing that includes it. Safran’s GNSS testing-services brochure separates conducted CRPA-electronics testing, standard-receiver testing and over-the-air testing of antenna-plus-electronics assemblies in its comparison on PDF page 3.

These are alternative scopes, not three tests every buyer must purchase. For a receiver-status integration task, the first scope may address the immediate decision. For an assembled antenna purchase, a receiver-only result leaves the antenna question unanswered. A chamber label alone is not sufficient either: the quoted setup must include the intended hardware and relevant conditions. None of these test-service examples establishes that ResiNav owns the facilities, supplies the service or has a report for a particular model.

Consider two hypothetical offers for the same assembled product. Offer A demonstrates a navigation receiver through a cable while the proposed antenna remains disconnected. Offer B tests the named antenna-and-electronics assembly under an agreed chamber scenario. A may answer receiver questions, but it cannot substitute for B’s antenna-inclusive scope. B is not automatically a pass or a field guarantee. Compare the test boundary first; price and the result come after that. No supplier quotation or ResiNav test result is represented by this example.

For a shortlisted item from the ResiNav catalogue, identify the exact configuration from its public datasheet and ask whether the proposed evaluation includes that item, which parts are bypassed, and what report is actually available or separately quoted. An absent public test report remains unknown, not a failed test.

Never radiate an unauthorised jammer or spoofing signal in an open environment. Use an authorised, controlled facility and an approved test method. Keep the adverse condition traceable and repeatable, and apply the baseline, observation and recovery rules below only to the hardware and conditions actually tested.

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. Separate startup, tracking and recovery evidence

A demonstration that maintains navigation after interference begins does not establish that the same configuration can start navigating with that interference already present. Compare the order of events, not just the final position display. Recovery after interference is removed is also different from reacquiring signals while it continues.

ESA-hosted Navipedia’s receiver-operations explanation distinguishes signal acquisition, which searches for a satellite signal, from tracking, which refines the estimates after detection. In the typical channel flow it describes, losing lock returns the channel to acquisition. A channel’s signal acquisition is not itself a usable navigation solution: the receiver must also have enough suitable measurements to produce the required output.

NovAtel’s interference explanation explicitly identifies acquisition as more sensitive to interference power than tracking. That supports comparing the two operating states separately; it does not supply a universal threshold, acquisition time or performance claim for a ResiNav configuration.

Hypothetical quotation comparison: an integrator’s equipment may be powered on at a location where interference already exists. Offers A and B name the same assembly, receiver, firmware, bands and controlled RF condition. A only shows a clean-start solution continuing when interference begins. B additionally includes a startup run with that condition already present and a separately defined interruption/reacquisition run. A addresses continuity, but leaves the required startup case unanswered. B covers a broader evaluation scope, not an automatic pass. If its reacquisition run removes interference first, that still leaves reacquisition during continuing interference unanswered. The buyer can select the missing test scope rather than treat the offers as equivalent or demand every test for every installation.

Cold, warm and hot start labels describe available prior information in the Navipedia explanation; they do not specify the interference condition. Record that condition separately. Detector initialization is another issue: NovAtel OEM7 spectral detection uses a startup calibration reference based on an interference-free assumption. Its calibration procedure or a quiet warning display is not a navigation-acquisition result.

For minimum-signal specifications, compare acquisition and tracking sensitivity with their test endpoints and time limits rather than substituting one threshold for the other.

Recovery remains 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, retain the conditions required 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.

For carrier-phase continuity events, distinguish cycle slips, loss of lock and ambiguity re-fixing before assigning a recovery time to the receiver.

The current RN2501 configuration provides PVT outputs; that output capability does not establish startup, continuity or recovery under any particular interference condition. Apply the hardware boundary in section 6 to whichever configuration is being considered. You can begin an enquiry with the operating sequence and information already available; detailed evaluation scope can follow during quotation discussions.

9. Create a bench-test evidence matrix

Minimum log package

• Test case identifier, date, operator and authorised facility
• Receiver model, serial number, firmware and configuration checksum or export
• Antenna or terminal model, RF path diagram, cable and attenuation record
• Signal source, scenario identifier and controlled disturbance profile
• Receiver raw messages, navigation outputs, timing outputs and status flags
• Test-equipment level and event timestamps
• Platform-controller data age, mode, alarms, fallback state and return-to-service state
• Power events, resets, configuration changes and operator annotations
• Expected result, observed result, deviation and disposition

Common test-plan errors

• Changing firmware, cables or configuration between runs without recording the change
• Comparing receiver output without recording the applied signal or interference condition
• Looking only at position while ignoring time, validity, output cadence and data age
• Using a screenshot instead of time-aligned machine-readable logs
• Calling a reacquired fix “recovery” before the platform’s return conditions are met
• Applying a generic pass limit that is not tied to the platform requirement
• Treating a controlled bench result as proof of field performance

10. Match anti-jamming evidence to a moving platform

A stationary anti-jamming demonstration does not establish performance during vehicle turns. For a moving platform, compare evidence covering changes in interference direction relative to the installed antenna, not only a suppression figure at one fixed orientation. A fixed emitter can remain in the same place while its bearing relative to a turning vehicle changes.

Manufacturers identify dynamic operation separately. NovAtel describes the GAJT-710ML’s adaptive nulls and dynamic multi-jammer scenarios. Mayflower’s NavGuard 720 Rev. 3 datasheet, page 2, separately names high dynamics and rotor-blade modulation. Those are statements about those manufacturers’ products; they do not qualify a ResiNav model or establish a universal motion limit.

Hypothetical quotation comparison: an integrator needs navigation continuity during a vehicle turn. Offers A and B cover the same named antenna-and-electronics assembly, receiver, bands and interference level. A demonstrates one fixed orientation. B also includes an agreed turning sequence and time-aligned receiver outputs. B covers an additional required condition; it is not automatically a pass, and a larger stationary dB figure in A would not replace that missing scope.

To see why the conditions differ, assume a stationary vehicle rotates its antenna assembly by 90° in yaw while a distant emitter’s bearing remains fixed, with no translation. The emitter’s relative azimuth changes by 90° in the opposite direction. That geometric example explains the transition to represent; 90° is not a required test angle, a recommended turn rate or a ResiNav specification. The actual sequence and success criterion belong to the intended application.

For a candidate from the published ResiNav range, keep model selection separate from operating qualification. The vehicle integration guide provides the product-screening path; this section identifies the additional evidence needed when motion changes the requirement. An unpublished dynamic test result remains unknown, not a demonstrated failure. You can start an enquiry with the operating condition and information already available; the detailed evaluation scope can be agreed afterwards.

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.

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.