Industrial robots and automated vehicles often consume GNSS data as one input among several. An acceptance test therefore should not ask only whether the receiver reports a position. It should show how the complete platform behaves before, during and after a defined signal disturbance—and whether the resulting evidence is sufficient for the intended operating conditions.
NIST describes resilient use of positioning, navigation and timing (PNT) as a risk-management problem: organisations should identify systems that depend on PNT, detect disruption or manipulation, respond and recover. CISA’s federal PNT acquisition guidance similarly connects operating requirements, resilience levels and contract evidence. These frameworks do not certify a particular robot or receiver. They provide a useful structure for deciding what an engineering acceptance record should contain.
1. Define the acceptance question before the test
Start with the platform decision that the evidence must support. Examples include:
- whether GNSS timing remains aligned with the robot controller and sensor logs;
- whether the platform detects an invalid, degraded or unavailable navigation input;
- whether the control system transitions to the documented safe or alternate-navigation state;
- whether GNSS data returns in a controlled, observable way after the disturbance ends;
- whether an engineer can reproduce the result from the recorded configuration and logs.
Record the robot model, GNSS receiver, antenna, cable, connector, firmware, enabled constellations and frequency bands, interface protocol, update rate, test software and time reference. A result without this configuration context should not be treated as transferable to another installation.
For interface preparation, see GNSS Receiver Compatibility for Anti-Jamming Integration and the ResiNav product catalogue.
2. Capture a clean baseline
Before introducing a controlled disturbance, collect a baseline under a documented signal environment. The baseline should include the same data channels that will be reviewed during the event:
- receiver navigation solution and validity/status fields;
- satellite and signal observations made available by the receiver;
- time output, 1PPS or serial-message timing where used by the platform;
- controller timestamps and sensor-log timestamps;
- interface errors, dropped messages and reconnect events;
- robot operating mode, navigation-source selection and safety state;
- antenna location, cable routing, power condition and nearby emitters.
NIST’s NASCTN GPS receiver work used measurable receiver outputs such as carrier-to-noise density, position error, timing error, satellites in view, time to first fix and time to first reacquisition. An industrial-robot test does not need to copy that research programme, but it should select observable metrics before testing rather than choosing them after seeing the result.
3. Verify timing as a system property
If the robot uses GNSS for time, validate more than the presence of a 1PPS signal. Document:
- the reference time source and traceability appropriate to the test;
- the electrical and protocol path from receiver to controller;
- the relationship between 1PPS, serial time messages and application timestamps;
- the normal offset and variation measured during the baseline;
- the alarm or validity indication when GNSS time becomes unreliable;
- the platform behaviour while GNSS time is unavailable;
- the conditions required before the platform accepts recovered time.
Do not infer timing accuracy from a receiver label or nominal interface description. Measure the behaviour at the point where the robot consumes the time information.
4. Use a controlled and authorised disturbance method
Radio-frequency tests must comply with the applicable law, site rules and spectrum controls. Do not radiate a jamming or spoofing signal in an open environment. Use an authorised laboratory method such as a shielded enclosure, conducted injection, approved GNSS simulator or another controlled facility selected by qualified personnel.
The test plan should define:
- the disturbance type and permitted test method;
- start and stop markers visible in both RF and platform logs;
- controlled variables and step sequence;
- receiver and platform observations at every step;
- abort criteria that protect people, equipment and surrounding systems;
- the method for returning the platform to its verified baseline.
NIST notes that PNT signals and data can be affected by natural, manufactured, intentional and unintentional events. The acceptance report should therefore describe the tested condition precisely and should not generalise one laboratory scenario into a universal field-performance claim.
5. Record detection and platform response
For each test step, correlate the receiver event with the platform response. Useful evidence may include:
- the first receiver indication of degraded or invalid data;
- the first platform alarm or diagnostic event;
- changes in navigation-source selection;
- changes in control mode or safe-state behaviour;
- continuity and ordering of serial or network messages;
- operator notifications and event timestamps;
- any data that remains stale after its validity flag changes.
The robot’s safe response is an application-level engineering decision. A GNSS terminal alone cannot define the correct motion-control or functional-safety response for every platform.
Review the Industrial Robotics and Automation application page for the integration questions that should be resolved before selecting an antenna or terminal.
6. Define recovery before measuring it
“Recovered” must have a written definition. It might require all of the following:
- the disturbance has ended and the test setup confirms a normal input condition;
- the receiver reports a valid solution using the expected configuration;
- timing and navigation outputs remain within the project’s approved limits for a defined observation period;
- the platform clears or acknowledges alarms according to its documented logic;
- the controller resumes the permitted navigation mode without an unexplained jump, stale message or timestamp discontinuity;
- the full evidence chain is present in the exported logs.
Record reacquisition and recovery times as results of the specific test configuration. Do not convert them into a general product guarantee without a verified specification covering the same conditions.
7. Build an acceptance matrix
| Test phase | Required evidence | Example acceptance question |
|---|---|---|
| Configuration | Receiver, antenna, cable, firmware, interfaces, enabled bands and platform software | Can another engineer reproduce the setup? |
| Baseline | Position/status, timing, signal observations, message integrity and platform state | Is normal behaviour documented before the event? |
| Detection | Receiver validity/alarm changes and correlated timestamps | Does the system recognise the defined disturbance? |
| Response | Platform mode, source selection, safety action and operator indication | Does the robot follow its approved response logic? |
| Recovery | Reacquisition, stable observation period, alarm clearing and output continuity | Is return to service controlled and auditable? |
| Report | Raw logs, plots, configuration files, deviations and approvals | Is the decision supported by retained evidence? |
8. Retain an engineering evidence pack
The final pack should include the approved test plan, configuration manifest, photographs or diagrams of the setup, calibration/reference information where applicable, raw receiver logs, platform logs, event markers, analysis method, deviations, unresolved observations and the names or roles of the reviewers.
Keep raw data separate from interpreted charts. If a value has been filtered, resampled or aligned, document the transformation. This supports later investigation when firmware, antenna placement, cable routing or the robot controller changes.
Frequently asked questions
Does this test prove that an industrial robot is safe in every GNSS interference environment?
No. It documents behaviour under the defined setup and test conditions. Functional safety, spectrum compliance and deployment suitability require the responsible platform engineers and relevant authorities.
Which recovery time should be specified?
Specify the event and endpoint first: receiver reacquisition, valid navigation output, timing stability, platform alarm clearing or return to an approved control mode. These are different measurements and should not be combined into one undefined number.
Can open-air jamming be used for acceptance testing?
Do not perform unauthorised radiated interference tests. Use a legally compliant, controlled method selected by qualified personnel, such as a shielded or conducted laboratory setup.
What should be sent with an RFQ?
Provide the platform type, receiver, constellations and bands, antenna and cable constraints, interfaces, power, environment, installation drawings, required logs and the acceptance questions the project must answer. Use the ResiNav RFQ form for an engineering review.
Engineering references
- NIST: Responsible Use of Positioning, Navigation and Timing Services
- NISTIR 8323 Rev. 1: Foundational PNT Profile
- NIST NASCTN: Impact of LTE Signals on GPS Receivers
- CISA: Federal PNT Services Acquisitions Guidance
Next step
To discuss a repeatable acceptance plan for your receiver, antenna and industrial platform, 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.