Use a supplier test report for a procurement decision only to the extent that it covers the item, conditions and result your decision requires. A genuine report can still be insufficient for a different receiver, firmware, installation or acceptance criterion. Missing detail is a request for clarification—not proof that the product failed.
This guide is for engineering leads and technical buyers reviewing a GNSS supplier’s documentation before approval. The aim is to determine what the available evidence supports now, rather than demand every possible document. It does not claim that ResiNav holds or will supply a particular report, certification or project result.
If the purchase scope is still unclear, first use the published-product versus custom-integration guide. Once a configuration is identified, the review below helps separate a relevant document from a sufficient basis for approval.
A product record, a drawing and a test report answer different questions
A product record identifies published characteristics. An applicable drawing or interface document can define connections and physical boundaries. A test report describes observations under stated conditions. One does not automatically stand in for another: a product photograph is not a mounting drawing, and a test summary does not necessarily define the delivered wiring or configuration.
Start with the formal model and the documents actually available. Capture the revision when shown; otherwise use the filename, source and access date. Do not assume a webpage is newer than a PDF, or that a newer document applies to an older sample. When sources conflict, ask which controlled record applies to the proposed supply.
Decide whether test evidence applies to the purchase
This is a suggested review method, not a universal certification checklist. It can be applied to a report, a summary supplied with an offer, or evidence produced during a buyer’s evaluation.
| Evidence boundary | What to compare with your purchase | What a mismatch or omission means |
|---|---|---|
| Tested item | Model and identifiable hardware, firmware or enabled configuration; whether the quoted item is the same configuration. | A similar family name is not enough to transfer the result. Resolve identity before relying on the report. |
| System boundary | What was inside the test: antenna or terminal, receiver, RF path and any controller whose behavior is claimed. | A component result does not by itself establish the end-to-end platform result. Limit the approval to what was actually observed. |
| Conditions and method | Relevant operating mode, environment, test duration and whether observations were controlled, recorded/replayed or live-sky. | Different conditions may answer a different question. Ask for the method and an explanation of applicability, not just a pass label. |
| Metric and acceptance rule | Definition, units, reference, statistic or percentile, observation interval and the criterion used to declare success. | Do not rank unlike metrics or treat a limit without a defined measurement as a directly comparable performance result. |
| Traceability and exclusions | Report identity, result scope, configuration references, stated exclusions and supporting observations sufficient for the decision. | A missing report section may limit confidence or scope; it is not a measured failure. Request the decision-critical clarification. |
Spirent’s receiver-selection guide illustrates why manufacturer figures need context: accuracy statistics can differ, and cold-start and warm-start conditions answer different acquisition questions (pages 4–7). These are general receiver-evaluation examples, not ResiNav product specifications.
Example: a recovery summary can support less than the buyer needs
Hypothetical procurement example—not a ResiNav test: a supplier summary says that a named receiver recovered a valid navigation solution after a disturbance. It identifies the firmware but gives no output log or controller observation. The buyer’s requirement is that the platform recognize invalid data during the disturbance and accept fresh data after recovery.
The summary may be relevant to receiver recovery, but it does not establish the controller’s handling of invalid or stale data. It also does not show the recovery interval unless the start and end events and timestamps are defined. The buyer should not record “platform recovery passed” on this evidence alone.
A focused next request is to identify which outputs were observed and whether the available record supports the stated recovery result. If the controller was outside the test, retain that exclusion and evaluate the missing system behavior separately. Do not discard useful receiver evidence merely because it does not prove the entire platform.
Use the receiver evaluation and recovery guide to plan testing, and the data-validity monitoring guide for output and controller behavior. This document review decides what an existing report supports; it does not replace those test methods.
Do not convert unaligned results into a model ranking
Before comparing two reported values, establish that they describe the same quantity under relevant conditions. A typical figure and a stated limit are not interchangeable. Neither are different accuracy statistics, a single observed recovery and a defined repeated-test result, or a receiver output measurement and a controller-level observation. Request clarification rather than inventing a conversion or declaring the smaller number the winner.
Configuration detail can matter even within one product family. NovAtel’s OEM7 RF selection note, for example, documents different supported input-gain ranges for different firmware generations. It supports checking the version tied to a result; it supplies no RF limit or compatibility evidence for a ResiNav model.
Keep the rest of the document package proportionate
Review a mechanical drawing when installation space or access determines selection; an RF or electrical definition when connections and operating boundaries determine it; and an interface record when the receiving equipment needs particular outputs. Request only the material that can close a decision-critical gap. Published dimensions, images or family labels cannot fill an unlisted field.
The RN-8AT terminal record and RN2512 system record provide model-specific starting points. Review the actual public documents through ResiNav’s data-sheet directory; ask whether additional drawings or applicable test material can be provided. Public availability of a data sheet does not imply availability of every other document.
Record a bounded approval, clarification or pause
Proceed with a defined evaluation when the item is identifiable and the evidence supports that stage. Record any excluded system behavior so that a sample-evaluation decision is not mistaken for complete integration approval.
Request clarification when one missing field or method definition decides applicability. For example: “Does report R apply to the firmware and configuration in this offer, and does its recovery result include the controller output?” This is a suggested question, not a reference to an actual report.
Pause the affected approval when the item cannot be identified, conflicting documents remain unresolved or the evidence does not address a required acceptance condition. State which decision is paused; do not turn an unresolved document question into a claim that a product is incapable.
Keep the approval scope with the document identities, evaluated configuration and outstanding conditions. Later replacements or firmware changes belong in the configuration-change review, rather than silently inheriting this approval.
Frequently asked questions
Is a data sheet enough to approve a GNSS supplier?
Usually not by itself. A data sheet can support early screening, but the approval decision should match the project stage and identify any mechanical, RF, electrical, interface, installation, configuration or version questions that remain decision-critical.
Do all suppliers need to provide the same documentation package?
No. The needed material depends on the item, platform, project stage and decision being made. The useful discipline is to identify the item, document what is known and request only the material needed to resolve the current decision boundary.
When should missing documentation pause approval?
Pause when the team cannot identify the configuration under review, cannot state the conditions of approval, or cannot relate a sample or evaluation result to the item that would later be supplied. Otherwise, record the gap and request focused clarification.
How is this different from an RFQ checklist?
An RFQ checklist helps the buyer prepare project inputs. This guide evaluates the supplier-side documentation package after a route has been chosen, so the team can decide whether to proceed, request clarification or pause an approval.
Ask about the evidence needed for your purchase
Identify the published model and the specific decision the available material cannot yet support. Ask whether the relevant document or clarification is available; do not assume it is part of the supply.
Review product recordsRequest a focused clarification