A GNSS anti-jamming product data sheet is the starting point for a selection review, not a substitute for the project requirements. Use it to identify what a supplier has published for a configuration, then separate missing or project-dependent details into questions for a documented RFQ discussion. This simple distinction prevents teams from treating an absent interface, environmental condition, signal statement or integration detail as an implied capability.
For a buyer, the practical question is not simply “Which product has the longest specification list?” It is “Which published facts address my requirement, and which integration details still need confirmation?” That question is especially important when antenna, receiver, RF path, platform and operating context are reviewed together.
This guide provides a repeatable comparison method for engineering teams, system integrators and technical procurement teams. It does not assign performance ratings, infer unlisted specifications or promise that one configuration is suitable for every platform.
Start with the decision you need to make
Before opening several data sheets, write down the decision that the review must support. A team selecting a published configuration may need to decide whether to continue to a product-specific RFQ. A team with an unresolved integration boundary may instead need a Custom/OEM discussion. These are different decisions, and they require different evidence.
- Published-product route: Use this when a documented configuration appears relevant and the open questions are limited to project confirmation.
- Custom/OEM route: Use this when the platform, required GNSS signals, RF boundary, physical envelope or interface needs cannot be confirmed from public product information.
- Hold-and-document route: Use this when the requirement itself is not yet stable. Record what is known before asking a supplier to compare products.
ResiNav’s GNSS anti-jamming product directory and verified product specifications are the appropriate places to begin a published-configuration review. The Applications pages help frame the platform context; Custom OEM GNSS Integration is the next path when the published information does not resolve the integration question.
Use a four-column product-documentation review
Compare each candidate against the same project requirement. The purpose is not to make documentation look more complete than it is. The purpose is to make the remaining questions visible early enough for the engineering and procurement teams to handle them together.
| Review column | What to record | Safe decision rule | Next action |
|---|---|---|---|
| Project requirement | What the platform, receiver, installation and operating context actually need. | A requirement belongs to the buyer; it is not proved by a product name. | Give the requirement an owner and a source, such as an interface document or platform drawing. |
| Published fact | A model-specific statement that appears on the relevant ResiNav product page or released document. | Use it only in the scope in which it is published. | Link or attach the exact source and revision used for the review. |
| Unlisted or unclear detail | An item that is absent, ambiguous or described only at a product-family level. | Do not convert silence into a “yes.” | Put the item on the RFQ question list. |
| Project confirmation | A detail whose answer depends on the actual platform or integration plan. | Do not use another product’s value as a substitute. | Discuss it through a documented engineering RFQ. |
Compare product type before individual fields
First decide whether you are comparing like with like. A product type establishes the integration boundary that the project must review. For example, the antenna-versus-terminal comparison guide explains why a product category cannot be selected by a single specification alone. A published model page, such as RN2512-AJS-16CH-DPA or RN-8AT-FULL-KGR-34V, should be reviewed as its own documented configuration.
Keep product type, model, element count, channel count, signal references and integration details in separate fields. In particular, do not use an element count as a proxy for a channel count, and do not infer a signal or interface from a model name. The separate element and channel count guide is useful when those two concepts need to be kept distinct.
Read signal references in their documented scope
GNSS constellation names and frequency-band codes should be copied exactly from the source record. They are technical identifiers, not marketing shorthand. If the project requires a particular constellation, band or receiver relationship, record the requirement first and then identify whether the relevant product page explicitly documents it.
Do not expand a short form, a product suffix or an umbrella term into a list of unlisted bands. Public GNSS documentation, such as the GPS interface-control-document resources, illustrates why signal identifiers are precise technical references. A product selection still depends on the published configuration and the project’s receiver and RF integration needs.
Make integration questions visible rather than assumed
Teams often need answers about installation space, mounting location, RF connection path, interfaces, input power, cable routing, environmental conditions and the receiver boundary. Some of these may be published for a specific configuration. Others may only be meaningful when the actual platform is known. Treat both cases differently.
- Mark the evidence source for every fact used in the comparison.
- Label a missing field as not published, rather than “not applicable” or “supported.”
- State the project consequence of the open field: fit, receiver integration, documentation review or engineering confirmation.
- Ask the question in the RFQ with the platform context that makes an answer possible.
This approach remains useful even when some project details are not yet available. The goal is not to delay a discussion until every parameter is known. It is to separate known inputs from open questions so that the next discussion is focused and traceable.
Use a comparison worksheet that does not overstate evidence
A compact worksheet keeps technical, procurement and program stakeholders aligned. It can be added to a sourcing file, internal design review or RFQ appendix.
| Requirement area | What the team knows | What to verify in published information | When to use the Custom/OEM path |
|---|---|---|---|
| Platform and application | Equipment type, operating context and installation owner. | Whether the documented product type is relevant to the integration boundary. | When the form factor or integration responsibility is unresolved. |
| GNSS signals and receiver | Required constellations, bands and receiver context. | Only the exact model-specific signal references that are published. | When the receiver or signal requirement cannot be matched from public information. |
| RF and mechanical boundary | Available space, routing constraints and known RF architecture. | Published dimensions, RF information or mechanical facts where present. | When a required RF, mounting or enclosure detail is unlisted. |
| Interface, power and environment | Known project constraints and acceptance conditions. | Only fields explicitly released for the configuration. | When an unlisted condition is necessary for the project decision. |
| Commercial planning | Prototype or estimated quantity, destination and project stage. | Whether a documented product can proceed to an inquiry. | When the project needs requirement clarification before a product-specific request. |
Common review errors to avoid
Using a model name as a specification
A model name identifies a configuration; it does not replace the model’s published technical record. Keep the name unchanged, but use the product page or released documentation for the facts you compare.
Borrowing an unlisted value from another model
Products in the same directory may be related without sharing every integration detail. A value on one published model page is evidence for that model only unless the supplier has published a broader statement.
Turning a missing field into a negative or a positive claim
An absent statement is not proof that a feature is excluded, included or irrelevant. It is an RFQ question. This is the most important discipline in an evidence-first comparison.
Starting with a product table instead of the project boundary
A comparison becomes more useful when the platform, receiver, signals and installation context are written down first. See the antenna–receiver–platform integration review guide for a broader framework.
Move from comparison to a documented RFQ
When a published configuration appears relevant, link your worksheet to the product page and list only the remaining questions. When the requirements cannot be confirmed from published information, use the Custom/OEM path rather than forcing a comparison to reach a premature answer. In either case, an RFQ can start with the information already available and be refined as the technical review develops.
Discuss Your GNSS Requirements
Frequently asked questions
Should we reject a product when a field is not listed on a public page?
Not necessarily. Record the field as unlisted and explain why the project needs it. The appropriate next step is a documented RFQ question, not an assumption about the answer.
Can we compare two models by their names alone?
No. Use the exact published model pages and documents. Keep product type, model, elements, channels, signals and integration conditions as separate review fields.
When should a team move from a published product review to Custom/OEM discussion?
Move to that discussion when the platform, GNSS requirement, RF boundary, physical envelope or interface condition necessary for the decision cannot be confirmed from published information.
Do we need every integration detail before sending an RFQ?
No. Send the known project inputs and identify open items. The RFQ can document questions that need technical confirmation as the project review progresses.
Why keep “not published” separate from “not applicable”?
They mean different things. “Not published” describes the evidence available to the buyer; “not applicable” is a technical conclusion that should only be made when the project and product information support it.
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.