Direct answer: When a GNSS-dependent platform shows an unexpected navigation, timing or interface condition, first preserve a shared time window and the installed configuration. Then collect receiver, RF-path and platform records without assigning a cause. A concise evidence packet lets the responsible engineering team decide whether to inspect, test, escalate or update the configuration record.
Keep the engineering boundary clear
An observed condition is not, by itself, proof of interference, spoofing, receiver failure, an RF problem or a platform-control problem. This checklist helps teams retain the information needed to review the event. It does not replace an operator’s approved safety procedures, a receiver manufacturer’s instructions, or a controlled test plan.
For a broader risk-management context, the NIST PNT Profile describes risk-informed use of positioning, navigation and timing services. It is not a product specification or performance endorsement.
1. Freeze a common event window
Record when the condition was first noticed, when it ended or changed, and which clock supplied each record. Preserve the time zone, synchronization source and any known uncertainty in the time record. If the receiver, platform controller and logging system do not share one exact clock, document that limitation instead of forcing a false alignment.
Also retain the operating phase: commissioning, maintenance, normal operation, a configuration change, or another documented activity. This creates a review boundary without claiming that the activity caused the condition.
2. Preserve the installed configuration before interpreting it
Capture the receiver configuration identifier, available software or firmware version identifiers, antenna or terminal role, cable and connector record, power arrangement, interface map and platform revision. Use the identifiers already present in the project records; do not infer missing values from photographs, labels or a generic webpage.
Configuration control matters because a later replacement, repair or settings change can make a useful comparison impossible. The existing RF-path documentation guide explains how to retain cable and connector history without treating a change as a performance conclusion.
3. Export receiver evidence as observations
Save the receiver status that is actually available to the project: time and validity indicators, reported signal or solution state, alarm or event messages, interface status, and the unedited export where permitted. Label every item as an observation. Do not rewrite an alert into a root-cause statement.
The GNSS integrity monitoring guide gives a deployment-oriented logging framework. During triage, use the same record names and time basis where possible so that the event can be compared with the planned monitoring record.
4. Keep RF and installation context alongside the logs
Attach the current RF-path manifest, antenna or terminal installation record, cable route, connector changes, known maintenance activity and relevant photographs or drawings already held by the project. Identify their document version and capture time. A missing document is a review finding; it is not evidence that an RF condition occurred.
Do not modify hardware, settings or files solely to make the event easier to explain. If a controlled inspection or test is required, the responsible team should define it separately and preserve the pre-change state.
5. Correlate platform, power and interface events
Collect the platform controller’s state, power events, communications errors, maintenance actions and operator observations that fall within the event window. Keep the original system names and timestamps. A correlation can indicate what should be reviewed next, but it does not establish that one record caused another.
For interfaces and timing boundaries, compare the retained material with the project’s receiver interface-control record. The receiver ICD guide is a useful reference for the types of interface, timing and configuration information that should be versioned.
6. Separate facts, unknowns and requested decisions
Prepare three short lists:
- Observed facts: timestamped records, configuration identifiers and approved operator notes.
- Unknowns: missing logs, uncertain clock alignment, unrecorded maintenance, unavailable configuration versions or unreadable exports.
- Review decisions: whether the next action is a document review, a controlled inspection, a controlled bench evaluation, a supplier question or an update to the configuration baseline.
This separation prevents a useful triage packet from becoming an unsupported technical conclusion.
7. Create an escalation packet that another team can replay
Give the packet an event identifier and include a short chronology, the source files or export references, configuration identifiers, the three lists above, and the responsible contact for each system record. Use immutable copies or the project’s established document-control method. Remove personal data that is not required for engineering review.
If a controlled test becomes necessary, link the event packet to a separate test definition. The bench-test evidence guide explains why a test article, baseline, inputs and observations must be defined before results are compared.
8. Close the loop through configuration control
After the responsible team completes its review, record the decision and any approved configuration change in the same evidence chain. Do not replace the original event packet with a summary. The original record supports later maintenance, acceptance and supplier discussions even when the final decision is simply that more evidence is needed.
For a project-specific engineering discussion, provide the current evidence packet through the Request a Quote form rather than selecting a model from an incident description alone.
Frequently asked questions
Does an event packet prove the cause of a GNSS condition?
No. It preserves observations and configuration context so that the responsible engineering team can determine what needs review. It does not prove interference, spoofing, hardware failure or any other cause.
Should a team repeat an acceptance test after every observed condition?
Not automatically. The packet should first show what is known, what changed and what is missing. A responsible team can then decide whether a controlled inspection or a separately defined test is appropriate.
Why are configuration identifiers important during triage?
They let reviewers distinguish the recorded installation from later repairs, replacements or settings changes. They do not establish that a particular version caused the event.
Can an incident description be used to select a product?
No. A product or configuration discussion needs verified receiver, RF, installation, platform and project requirements. An incident record can identify questions for that review, but it is not a selection result.
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.