A repeatable GNSS installation baseline is a buyer-owned record of what was actually installed on a reference unit before the same configuration is introduced across multiple units. It does not prove performance, certify a configuration or replace project-specific review. It gives engineering, procurement and integration teams a shared way to identify the configuration, capture its physical boundary and keep any deviations or unknowns visible as the rollout grows.
This guide is for teams moving from one reference installation to a small fleet, a series of machines or several similar platforms. If all details are not yet available, start with the information that is known and mark the rest for confirmation. The useful outcome is not a perfect form; it is a repeatable record that prevents one unit’s assumptions from quietly becoming another unit’s undocumented differences.
Why the first installation needs a baseline
A first installation is often a learning exercise: drawings may be incomplete, a mounting position may be selected around available space, and some interface or environmental details may still require clarification. That is normal. The risk begins when the next units are described as “the same” without a stable way to show what “the same” means.
A baseline creates a reference point for decisions. It distinguishes published information from observations made on a particular unit, and it separates confirmed details from items that still need project review. This supports disciplined conversations when a unit is later found to differ in layout, harness routing, available space, receiver integration or project documentation. It does not identify the cause of a GNSS symptom by itself, and it should not be used to infer anti-jamming or anti-spoofing performance.
Define the boundary before recording details
Start by deciding what the baseline covers. For a GNSS-related installation, that boundary commonly includes the configuration being evaluated, the platform context, the physical installation location and the handoff information used by the teams involved. It should be practical enough to use for every unit, but narrow enough that it does not become a substitute for an entire project design file.
Keep three kinds of information separate
- Published facts: the model identifier, public documentation and the declared product configuration that can be cited without interpretation.
- Unit-specific observations: the unit identifier, installation reference, available space, routing reference and photographs or drawings that the project is permitted to share.
- Open items: questions about interfaces, power, signal requirements, environment or acceptance conditions that have not been confirmed. An open item is not evidence of a defect.
For an initial catalogue comparison, start with the published GNSS anti-jamming products. Where the published page does not resolve a required integration condition, use the Custom OEM GNSS Integration path to document the question rather than assuming an answer.
Use a repeatable unit record
The following matrix is intentionally evidence-led. It does not prescribe any particular connector, band, mounting method, environmental rating or acceptance method. Record only information that is available to the project, and keep the next clarification visible.
| Record area | Capture for the reference unit | Capture for every additional unit | Do not infer | Next action when incomplete |
|---|---|---|---|---|
| Configuration identity | Product model, published page or document reference, and project revision reference. | Unit identifier and the configuration record used for that unit. | Unpublished features or suitability. | Ask for a project-specific clarification. |
| Installation boundary | Platform area, drawing or photograph reference, and the agreed location description. | Whether the unit follows the reference or has a documented physical deviation. | That a similar position is mechanically or electrically equivalent. | Record the difference and review it with the responsible team. |
| RF, receiver and electrical context | Known receiver, RF, power and interface references supplied for the project. | Known changes, unavailable details and applicable document versions. | Connector types, power values or signal support that are not published. | List the information needed before a conclusion is made. |
| Project conditions | Intended application, integration stage, quantity range and validation objective. | Any unit-specific constraint that changes the review context. | Performance results or project acceptance. | Define the condition to be reviewed or retested. |
| Evidence package | Record owner, date, source links and open-item status. | Link to the unit record and a concise deviation log. | That missing evidence confirms equivalence. | Assign an owner and a confirmation step. |
Use stable identifiers rather than informal labels such as “the left-hand unit” or “the latest setup.” A configuration label, the unit identifier and the source document date are usually enough to make a later discussion traceable without exposing proprietary drawings in an article or a public RFQ.
Choose a reference without claiming every unit behaves identically
A reference unit is a documentation anchor, not a promise that every future installation will have the same result. The role of the baseline is to make relevant differences discoverable. If a subsequent unit has a different available location, mechanical constraint, receiver context, RF path or project condition, record it as a deviation and decide whether more clarification is needed.
For example, a published product such as the RN-8AT-FULL-KGR-34V product page can identify a model considered by a project. Its public page should remain the source for product facts. The unit record should only state how that candidate is being considered in the project and which integration details remain to be confirmed. Do not turn a model name into an assumption about a platform, installation or outcome.
A practical decision path for the next unit
- Identify the starting record. Confirm which reference configuration and documentation revision apply.
- Compare the installation boundary. Note whether location, available space or project routing context differs from the reference.
- Mark unknowns instead of filling gaps. Keep interface, power, RF, environmental and acceptance questions separate from verified facts.
- Decide the next conversation. If the published configuration and documented unit boundary are sufficient for the project stage, continue with the relevant product discussion. If they are not, move the open items into a documented engineering conversation.
- Preserve the result. Link the unit record to the evidence used, the decision made and the questions that remain open.
This path complements, rather than replaces, a detailed GNSS installation documentation checklist. That checklist helps record an installation; this guide explains how to use a shared reference record before the installation process is repeated across units. If a proposed configuration later changes, review the change separately with the configuration-change evidence guide.
Common mistakes that make a multi-unit record less useful
- Copying the first unit’s notes without a unit identifier. The copied record can no longer show what was actually checked for the next unit.
- Turning an unknown into a default value. A blank or confirmation-needed field is more honest and more actionable than an invented interface, frequency, power or environmental condition.
- Mixing published facts with site observations. Keep product documentation distinct from project evidence so reviewers can see the source of each statement.
- Using the baseline as a pass/fail test. A baseline is not a test result, certification or deployment approval.
- Waiting until a later issue to collect evidence. A minimal record made at the time of installation is usually easier to interpret than recollection after several changes.
When to ask for clarification or start a Custom OEM discussion
Move to a focused clarification when the project cannot establish a required condition from published material and the current unit record. Examples include an unresolved integration boundary, a non-standard physical constraint, an interface or power question, an uncertain GNSS requirement, or an environmental condition that needs project-specific review. This is not a claim that a custom solution will be available; it is the point at which the project should make the question explicit.
ResiNav’s Applications page provides the broader engineering path from platform context to a published-product or Custom OEM conversation. Before asking for a quote, assemble the reference record, state what is documented and identify the questions that remain. A concise record helps the next discussion begin with project facts rather than assumptions.
Prepare a documented engineering discussion
Share the intended platform, published product references, reference-unit record, known differences and unresolved integration conditions. Information can be provided in stages; state what is known and what needs confirmation. Discuss your GNSS requirements or explore engineering insights.
Frequently asked questions
Is an installation baseline the same as an acceptance test?
No. An installation baseline records the configuration, boundary and evidence used for a unit. It does not create a test result, certification or performance conclusion.
What should we do when a detail is unknown?
Mark it as unknown or requiring confirmation, state why it matters to the project and assign a clarification step. Do not replace the missing detail with an assumed value.
Can one baseline be reused for every platform?
It can provide a common structure, but each unit needs its own identifier and a comparison to the reference boundary. Platform-specific differences should be recorded rather than hidden.
Does a documented reference unit prove later units are equivalent?
No. The record supports comparison and traceability. It does not establish mechanical, electrical, RF or operational equivalence without the relevant project evidence and review.
When should a team submit an RFQ?
Submit an RFQ when the project can share the known platform context and published-product references, together with the open integration conditions that need discussion. Information can be added in stages.
Sources used for the baseline approach
The recordkeeping principles in this article are informed by the configuration-baseline discussion in the NASA Systems Engineering Handbook and the baseline-configuration concepts in NIST SP 800-171 Rev. 3. They are used here as general engineering-record principles, not as a claim of compliance or certification.
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.