Direct answer: a field observation should not be treated as proof that a GNSS product, receiver or installation is unsuitable. Before a team changes hardware or reaches a supplier conclusion, it should preserve the observation, identify the installed configuration, compare the available record with the intended review question, and then choose the next action: repeat the observation under documented conditions, request clarification, or open a focused engineering discussion.
This guide is for engineering, integration and procurement teams that need to turn an unexpected GNSS-related observation into a reviewable record. It does not diagnose interference, spoofing or product failure from one symptom. It provides a fact-safe way to decide what can be concluded now and what must still be confirmed.
Start with the decision, not the suspected cause
Teams often begin with a conclusion: a receiver lost availability, a position looked unusual, or a platform behaved unexpectedly. Those observations may be important, but they do not by themselves establish cause. Start by writing the decision that the record needs to support. For example: should the team repeat an observation, request a missing configuration detail, compare a published product configuration, or begin a project-specific discussion?
NASA systems-engineering guidance separates the expected result, the conditions of the activity and the recorded discrepancy. That distinction is useful for GNSS integration: a documented observation can be reviewed without claiming why it occurred. NIST likewise explains that a measurement result depends on a documented process and supporting context, not simply on the presence of an instrument.
Define the observation boundary
A useful observation record identifies what was actually seen and where the boundary of the record begins and ends. Keep platform behaviour, receiver status, RF path, power and data interfaces distinguishable. If a fact is not available, mark it as unknown instead of filling the gap with an assumption.
- Observation: what the operator, platform log or receiver output showed.
- Time window: a start and end time, time source where available, and whether the sources are aligned.
- Operational context: the platform state, route, task or operating phase relevant to the observation.
- Installed configuration: the identifiable antenna, receiver, RF path, power path, software or configuration references available to the team.
- Open questions: facts that are missing, unverified or need a supplier or integration-owner response.
Build a record another reviewer can understand
The goal is not to collect every possible data point. It is to retain enough context for a second reviewer to distinguish an observation from an inference. Use a short evidence matrix before changing equipment or requesting a conclusion.
| Record area | Capture now | Do not infer | Useful next action |
|---|---|---|---|
| Observed behaviour | Timestamped receiver, platform or operator observation | That one symptom proves a specific GNSS cause | Preserve the original event reference |
| Configuration | Available model, revision, settings and installation references | Unrecorded interfaces, bands or environmental limits | Request the missing document or photograph |
| Test or operating conditions | Platform state, location context, power state and known changes | That conditions match a previous run unless documented | Repeat only with comparable conditions |
| Expected outcome | The requirement, procedure or operational expectation being reviewed | A pass/fail threshold that was never defined | Clarify the decision criterion |
| Disposition | Known facts, unknowns, owner and next review point | Root cause or product suitability without evidence | Repeat, clarify or discuss integration needs |
Keep the observation, condition and conclusion separate
Three short fields make a review record much safer. First, state the observation in terms that a log, photograph, operator note or receiver status can support. Second, state the conditions that were known at the time. Third, state the decision that remains open. This avoids the common pattern of treating an unverified explanation as part of the observation itself.
For example, “the platform log recorded an unexpected navigation-status transition between these timestamps” is an observation. “The available record identifies this receiver configuration and this installation reference” is context. “The team needs to determine whether comparable conditions can be recreated” is an open decision. None of those statements asserts that an external source, receiver fault, installation issue or product limitation caused the event.
This separation is valuable when several groups take part in the review. An operator can contribute the sequence of events, an integration team can identify the installed boundary, and procurement can ask for a documented clarification without merging those responsibilities into one unsupported conclusion.
Check whether the configuration is comparable
Before comparing observations from different days, vehicles or units, determine whether the records describe comparable configurations. A change in the receiver setting, cable path, power condition, antenna position, platform state or software version may be relevant to the review boundary. It is not necessary to declare that a change caused the observation; the record only needs to make the difference visible.
For a deeper installation record, see the GNSS installation documentation checklist. For cable and connector changes, use the RF-path documentation guide as a related reference.
Choose one of three fact-safe next steps
1. Repeat the observation
Repeat when the decision cannot be made because the first record lacks a clear time window, configuration reference or condition record. The repeat should use a documented objective and comparable conditions where practical. A repeat is an opportunity to improve the evidence; it is not a promise that the same outcome will occur.
2. Request clarification
Request clarification when a published page, data sheet, installed record or supplier proposal does not establish the needed fact. Ask a specific question: which configuration version was reviewed, which receiver interface is relevant, or which documented condition applies? This is more useful than asking a supplier to confirm an unsupported conclusion.
3. Start an engineering discussion
Move to an engineering discussion when the open items concern project-specific integration rather than a simple missing record. Examples include mechanical space, receiver and RF integration, required GNSS constellations and bands, power or interface constraints, operating environment, quantities and project stage. Review the published GNSS anti-jamming products first where their documented configuration is relevant; use Custom OEM GNSS Integration when the published information cannot resolve the project boundary.
Common errors that weaken a field record
- Changing several things before recording the initial state. This removes the comparison boundary needed for a later review.
- Combining fact and conclusion in one note. Write the observation first, then identify the conclusion that still needs evidence.
- Using a product name as a configuration record. Keep available version, installation and interface references alongside the name.
- Calling one observation a product verdict. A single event may justify another review step, not a universal suitability claim.
- Sending a broad RFQ without the known facts. A concise record helps the next engineering conversation begin with the actual project boundary.
Prepare a concise engineering handoff
A handoff can be short. Include the platform and operating scenario, the observed time window, available receiver and configuration references, RF and installation facts already known, what changed before or after the observation, and the specific decision that remains open. If some inputs are not yet known, say so. The purpose is to make the next review efficient without representing unconfirmed conditions as facts.
Give engineering and procurement the same decision record
Engineering and procurement do not need the same level of technical detail, but they do need the same decision boundary. A concise record helps procurement avoid asking for a broad assurance that a supplier cannot support with the available facts. It also helps engineering avoid receiving a commercial request that omits the platform, configuration or evidence needed to review it.
Use one shared summary with four statements: what is observed, what configuration or document references are available, what information is still missing, and what decision the team wants to make next. Attach source material only when it can be shared appropriately. A product page, document reference, version identifier, photograph of an installation boundary or exported log reference may help; a generic statement that the system “did not work” usually does not establish a reviewable question.
When the available facts already fit a published configuration, the next step may be to review the relevant product details and submit a focused RFQ. When the facts instead show unresolved integration constraints, the right outcome may be a Custom OEM discussion. In either case, the record should make clear which facts are known, rather than implying a requirement that has not been confirmed.
Use the Engineering Insights library for related integration guidance, review Applications for operating-context considerations, or request an engineering RFQ with the evidence currently available.
Frequently asked questions
Does an unexpected GNSS observation prove a product problem?
No. It is an observation that needs configuration, operating and evidence context before a cause or suitability conclusion is considered.
Should we change the installation before collecting evidence?
Record the available initial state first. If a change is necessary, document what changed so the later review has a comparison boundary.
What if the team does not know every receiver or RF detail?
Submit the known facts and list the unknowns. A useful engineering discussion can begin with a clear project boundary and specific open questions.
When should a supplier be asked for clarification?
Ask when an available document or published configuration does not establish the fact needed for the next decision. Keep the question tied to the actual project requirement.
When is Custom OEM discussion appropriate?
It is appropriate when published product information does not resolve project-specific mechanical, RF, receiver, signal, interface, power, environmental or project-stage questions.
Sources
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.