Compare GNSS anti-jamming supplier proposals against the same buyer-owned requirements, not against each other’s marketing language. For every requirement, record the proposal’s documented answer, its source, the project condition it depends on, and any clarification still needed. This approach does not rank suppliers or predict performance. It gives engineering and procurement teams a shared way to decide whether a published configuration can move forward, whether a focused clarification is needed, or whether the project should begin a Custom/OEM discussion.
This guide is for system integrators, engineering leads and technical buyers who have more than one GNSS anti-jamming response to review. It is deliberately fact-safe: a supplier’s model name, a short data sheet or an attractive feature list does not fill an unknown interface, mechanical, RF, power or environmental boundary. The practical output is a controlled comparison record that can be reviewed by the people who own the platform, receiver, RF path and commercial decision.
Start with one decision question
Before comparing rows in a spreadsheet, state the decision the team needs to make now. Examples include: whether a published configuration merits a technical evaluation; whether a sample request is sufficiently defined; or whether a platform constraint requires a Custom/OEM discussion. These are different decisions, so they need different evidence.
A useful comparison is not a universal supplier scorecard. It is a requirement-to-evidence matrix built around the project at hand. NASA’s systems-engineering guidance uses traceability and verification matrices to connect a requirement to its source and the evidence used to verify it. Here, the same discipline is a practical working method: make the buyer requirement visible, identify the source of a supplier answer and preserve what remains unresolved.
Start from the platform and integration boundary, then use the Applications overview and the published product catalogue to frame a first pass. A product page can support screening when it documents the relevant configuration. It should not be treated as proof of a project-specific fit.
Define the comparison boundary before opening proposals
Give every proposal the same review boundary. Record the intended platform or equipment role, the receiver or RF boundary known to the team, the GNSS constellations and bands the project needs to discuss, the available mechanical envelope, power and interface constraints, environmental conditions to be confirmed, and the project stage. If an input is not known, enter it as an unknown rather than inserting a preferred answer.
This matters because two responses can look comparable while answering different questions. One may identify a published model; another may describe a project-specific path; a third may omit the configuration identity entirely. The comparison can still proceed, but the matrix must show that those are different evidence states—not equivalent entries.
Use four evidence states
- Documented: a source identifies the item or answer, such as a current public page, drawing, interface document or supplier response. Record the title, revision or delivery reference where available.
- Clarification required: the requirement matters to the present decision but the available response does not establish it. Turn it into a precise supplier question.
- Project decision: the buyer or platform team must choose the condition; a supplier cannot infer it from a model name.
- Not required at this stage: the item is not decision-critical yet. Record why, so that it can be revisited when the project moves to the next stage.
These labels reduce a frequent source of delay: a missing fact quietly becomes an assumption, then later appears as a contradiction between procurement, integration and test teams.
Build a GNSS supplier-proposal comparison matrix
The following matrix is a working framework, not a required industry form and not a test plan. Its purpose is to make comparable questions visible across every response. Keep each row short enough that the owner, source and next action remain clear.
| Buyer requirement or question | What to record from each proposal | Evidence source | Do not infer | Next action |
|---|---|---|---|---|
| Configuration identity | Supplier name, formal model, stated product role, document title and revision or date when supplied. | Quoted response, current product page or identified supplier document. | That two similar names describe the same hardware, firmware or quoted configuration. | Ask which exact configuration and document set apply to the evaluation or quotation. |
| GNSS and RF discussion boundary | Only the constellations, bands, RF inputs or outputs explicitly stated for the item being reviewed. | Identified public specification or supplier technical response. | Unlisted signals, frequencies, receiver compatibility or RF behaviour. | Ask for the definition needed by the receiver and RF review. |
| Mechanical and installation boundary | Published dimensions, mass, drawings, mounting information or stated space assumptions only when documented. | Drawing, data sheet or supplier clarification. | Installation suitability, service access, mounting method or cable routing from an image alone. | Compare the documented boundary with the platform team’s available space and installation concept. |
| Power and interface boundary | Only listed voltage, connector, data or interface information, plus any stated dependency. | Interface document, drawing or written response. | Connector type, pinout, protocol, power behaviour or compatibility that is not stated. | Request the interface definition required for the current design review. |
| Environmental and operating conditions | Conditions explicitly published or a supplier statement of what needs project confirmation. | Current document or written clarification. | That a candidate satisfies the project environment because it resembles another product. | Record the platform condition and ask which requirement can be addressed at the current stage. |
| Evaluation and decision evidence | What the team can review now, what a sample would represent, and what remains open. | Buyer evaluation plan and the identified proposal documents. | Performance, approval or delivery readiness from an incomplete response. | Continue, request targeted clarification, or begin a Custom/OEM discussion. |
The value of the matrix is not the number of filled cells. A blank cell can be the most useful result if it reveals a decision-critical question early enough to resolve it responsibly.
Compare evidence, not implied capability
When a proposal includes a specification, record exactly what the source says and the context in which it says it. Do not promote a single field into a broader conclusion. For example, a channel count is not a complete performance specification; different architectures may use terminology differently, and the count does not by itself establish element count, supported bands, null count, anti-jamming behaviour, interface compatibility or suitability for a specific platform. The same rule applies to a product photograph, a general product category or a feature phrase.
Use the element and channel count selection guide when the team must clarify what a count means in a documented architecture. Use the data-sheet review guide when a field is present but its scope needs to be read carefully. This article starts after that work: it lets a buyer compare the evidence state of several responses without pretending that every row is already equivalent.
Normalize the delivered scope before comparing the price
Two prices are comparable only when they buy the same decision-ready scope. Separate the quoted hardware from the items that make an evaluation usable: cables, power accessories, mounting parts, software rights, external services and any agreed engineering work. These categories are questions for the quotation, not a statement that ResiNav supplies them all.
| Scope line | What makes the offers comparable | How to handle an unanswered item |
|---|---|---|
| Hardware supplied | Exact model and revision, unit quantity and included accessories; identify buyer-supplied equipment separately. | Do not treat an antenna, a terminal and a receiver-equipped kit as equivalent packages. |
| Cable, power and mounting items | Part numbers, quantities and whether each is included, separately priced or buyer-supplied. | Keep an unpriced required item open; do not enter zero cost. |
| Software or external services, where relevant | Enabled features, duration, start date and renewal basis for the selected equipment or service. | Distinguish a perpetual right from a trial or subscription. Do not assume every GNSS product needs a licence. |
| Evaluation and support work | The specific agreed task, output and exclusions, rather than a general “technical support included” label. | Ask for the quoted scope; do not assume testing, site work or a report is included. |
| Commercial comparison basis | Same quantity, currency, quotation validity and identified freight/tax treatment; record proposed delivery timing separately. | Use written quote terms. Public product availability is not a confirmed delivery date. |
Worked quotation example: a lower unit price can leave a larger gap
Fictional comparison, not a ResiNav price or offer: assume the same technically acceptable evaluation hardware is offered at USD 1,000 under Offer A and USD 1,150 under Offer B. A separately prices the required cable at USD 120 and power accessory at USD 80; B explicitly includes both. On that limited, like-for-like scope, A totals USD 1,200 and B USD 1,150. Neither figure includes any unspecified tax, freight or additional work. If B’s inclusion is not written down, its comparable total is still unknown—not automatically USD 1,150.
This arithmetic does not choose the supplier. Apply it only after the technical requirement and quoted configuration are aligned. Keep unresolved technical conditions separate from commercial totals, and do not disguise a mandatory missing answer inside a weighted score.
Official manufacturer material shows why scope lines matter. Septentrio lists the components of its mosaic-go X5 evaluation kit; NovAtel separately documents OEM7 feature authorizations and subscriptions. These are examples of how those manufacturers define their own offers, not claims that ResiNav uses the same kit contents, licensing or compatible hardware.
For the shortlisted ResiNav configuration, attach the exact public datasheet and request a line-item quotation showing what is included, optional and not yet priced. Keep any installation, service or evaluation deliverable explicitly subject to the supplier’s response.
Use published configurations as evidence-led starting points
A published configuration can be a useful starting point when the current page identifies a product role and documents fields relevant to the decision. For example, the RN-8AT-FULL-KGR-34V product page is an English public configuration page that can be placed in a review record with its source URL and date. That does not establish project-specific mechanical, RF, electrical, interface or environmental fit beyond what the page expressly documents.
If published information and the platform requirements line up sufficiently for the current decision, proceed to a documented product evaluation. The guide When to Evaluate a Published GNSS Product—and When to Start a Custom Integration Discussion explains that route choice. If the comparison exposes unresolved physical, signal, RF, electrical or system-boundary questions that cannot be answered from public material, move those questions into a Custom/OEM GNSS integration discussion. That is a request for clarification, not an assumption that any unlisted capability exists.
Keep the decision record usable after the quotation changes
Record which offer revision was compared and the conditions behind the decision. If an accessory, enabled feature or quoted configuration changes, revisit the affected comparison rows rather than assuming the old total or technical conclusion still applies. Keep the agreed technical reviewer and commercial decision-maker visible in the record.
Turn the comparison into the next engineering conversation
At the end of the review, choose one of three explicit outcomes. Continue with a published configuration when the available evidence supports the current evaluation decision. Request clarification when one or more decision-critical rows lack an identified source. Start a Custom/OEM discussion when the buyer’s platform boundary cannot be responsibly mapped to a published configuration.
Share the matrix with the relevant platform, receiver, RF and procurement contacts, along with the known project context. The GNSS integration documentation-package review can then help the team determine whether the returned material is controlled enough for the next approval step. Keep the record alongside the project rather than treating it as a one-time email exchange.
NEXT STEP
Start an evidence-led GNSS engineering discussion.
Bring the available proposal references, platform constraints and open questions. It is acceptable to begin with incomplete information when the unknowns are clearly identified.
Frequently asked questions
Should procurement score every GNSS supplier proposal?
Only after the team agrees on the requirements and evidence that matter to the current decision. A score can be useful as a decision aid, but it should not conceal unanswered technical questions or convert an undocumented field into a capability claim.
What should be compared first?
Start with configuration identity and product role, then compare the project’s decision-critical boundaries: GNSS and RF context, mechanical space, power, interfaces, environmental conditions and the evidence needed for the current project stage.
Does a public product page prove integration compatibility?
No. It can identify a published configuration and its expressly documented fields. Compatibility with a specific platform, receiver, RF path, installation and operating condition requires the relevant project evidence and, where needed, supplier clarification.
When should the team request a Custom/OEM discussion?
Use that route when a decision-critical physical, signal, RF, electrical, interface or system boundary cannot be resolved from the published configuration and the available project information. Describe the open boundary rather than assuming an unlisted capability.
Can incomplete information still support an RFQ?
Yes. Record the known context, identify the unknowns and ask focused questions. An RFQ discussion can progress in stages as long as the team does not represent open assumptions as confirmed requirements or documented product facts.
Sources and engineering context
- NASA Systems Engineering Handbook: Appendix D, Requirements Verification Matrix —general traceability and verification-matrix context; not a mandatory commercial GNSS form.
- NASA Systems Engineering Handbook —general requirements-management and traceability context; not a product-performance source.