Use a published GNSS product as the next step when its documented role and the project’s known constraints line up. Start a Custom/OEM integration discussion when the answer depends on platform-specific details that public product information does not establish. This is not a choice between a “better” and a “worse” path. It is a way to keep an engineering evaluation honest: use published information for what it proves, and make project-dependent questions visible early.
For engineering teams and technical buyers, a GNSS anti-jamming purchase rarely begins with a single product attribute. The decision usually crosses the installed platform, the GNSS receiver, the RF path, mechanical space, interfaces, power, operating environment and the project stage. Public product pages are useful because they establish a documented starting point. They cannot, by themselves, confirm every installation or system outcome.
This guide gives a practical route-selection framework. It helps a team decide whether to continue from the published ResiNav product directory into a model-specific evaluation, or to move directly to a Custom OEM GNSS Integration discussion. Once the route is clear, use the GNSS anti-jamming RFQ checklist to prepare the detailed information request.
Start with the decision, not the product name
The first question is not “Which model is best?” It is “What decision does this review need to support?” A team may only need to establish whether a published configuration deserves a closer look. Another team may already know that the installation, receiver or physical constraints require project-specific confirmation. Treating those two situations as the same creates avoidable back-and-forth.
- Published-product evaluation: appropriate when the product’s documented type and listed information address the known project boundary well enough to continue to a model-specific review.
- Custom integration discussion: appropriate when the answer depends on a platform-specific signal, RF, mechanical, interface, power or environmental detail that is not established by public information.
- Requirements-first pause: appropriate when the project team cannot yet describe the platform role, receiver boundary or intended operating context. Document what is known before asking anyone to recommend a configuration.
The distinction is intentionally conservative. An unlisted field is not evidence that a configuration supports it, and it is not evidence that the configuration cannot be considered. It is simply an open engineering question. ResiNav’s guide to reading published GNSS anti-jamming product data sheets explains how to preserve that evidence boundary during a comparison.
What a published product page can establish
A published product page is useful when it states a product’s role and provides model-specific information that can be compared with a documented requirement. It gives a buyer something concrete to review: the formal model, the published product type, and only the details that are actually shown for that configuration. It is also the right place to identify which questions still need to be put into an RFQ.
For example, the published RN-8AT-FULL-KGR-34V page is a terminal product record, while the published RN2512-AJS-16CH-DPA page is an anti-jamming and anti-spoofing system record. Those pages can help establish which product family should enter a review. They should not be used to infer unlisted receiver interfaces, installation methods, environmental ratings, delivery commitments or project outcomes.
A published-product evaluation is usually the right next step when
- the required product role is clear enough to map to a published terminal or system family;
- the buyer can identify the intended platform and operating scenario;
- the available product documentation covers the facts needed for an initial comparison;
- remaining questions are limited and can be stated as project-confirmation items; and
- the team is ready to compare a specific model against the receiver, RF and installation boundary.
This route does not mean that integration is already approved. It means a published configuration is a reasonable evidence-led starting point. The next action is to open the relevant model page, record the documented facts, and state the remaining questions clearly.
When a Custom/OEM discussion is the more useful route
Move to a Custom/OEM discussion when public product information cannot answer the question that decides the project. The reason may be physical, electrical, RF or procedural. What matters is not the label “custom”; it is whether the project boundary has an unresolved dependency that a general catalog comparison cannot close.
The U.S. Coast Guard Navigation Center notes that GNSS discrepancies can arise from integration factors such as the host vehicle, embedded systems, power, antenna orientation and output formats. That is why a product-only comparison is not enough when those factors are central to the decision. Navigation Center guidance on GPS incidents and anomalies is useful context; it does not prove the suitability of any particular product.
Start the engineering discussion when any of these questions is decisive
- Which GNSS constellations or frequency bands must be reviewed for this receiver and operating requirement?
- What is the actual RF boundary between antenna, cable path, receiver and platform equipment?
- What installation space, mounting position or cable route is available on the platform?
- Which interface and power details must be confirmed with the host system?
- Which environmental or mechanical constraints are project requirements rather than assumptions?
- Is the project at concept, prototype, evaluation or repeat-order stage, and which requirements are already stable?
These questions do not imply that every option is available, or that a project will be accepted. They create a structured starting point for the engineering conversation. The Applications section can help frame the platform context before that discussion begins.
A fact-safe decision framework
The two routes can be evaluated with the same four inputs. The purpose is to make unknowns explicit—not to convert a preliminary comparison into an implied technical commitment.
| Review input | What the buyer should establish | Published-product route | Custom integration route |
|---|---|---|---|
| Product role | Whether the project is evaluating a terminal, a system or an unresolved architecture question. | A published product family gives a credible first comparison. | The needed role itself depends on the project architecture or unconfirmed boundary. |
| Published evidence | Which facts are shown on the relevant model page or released document. | The stated facts cover the initial comparison. | A decisive requirement is absent, unclear or only project-dependent. |
| Integration constraints | Receiver, RF, physical space, power, interface and operating-context inputs. | Open questions are limited and can be documented for confirmation. | One or more constraints must be resolved before a model can be responsibly compared. |
| Next action | Who owns the next decision and what information is needed. | Review a model-specific product page and prepare a focused RFQ. | Document requirements for a Custom/OEM engineering discussion and then prepare an RFQ. |
Common mistakes that slow an engineering review
Using a product name as a requirements document
A product model identifies a published configuration; it does not describe the buyer’s entire platform. Keep the platform’s own requirements, drawings, receiver data and installation constraints in a separate project record.
Assuming an absent public detail is confirmed
Do not infer an interface, connector, environmental capability, installation method or performance result from a product name, image or product-family label. Put it on the question list. This protects both the buyer and the supplier from an inaccurate comparison.
Starting an RFQ before the decision owner is clear
Procurement, platform engineering and GNSS or RF owners may each hold part of the information. An RFQ becomes more useful when the team identifies who can confirm the platform scenario, receiver boundary, RF path and mechanical constraints. Unknown fields can be added later; they should be marked as unknown rather than filled with guesses.
Treating the product directory and Custom/OEM page as competing destinations
They are complementary paths. The directory helps a buyer find current published configurations. The Custom/OEM page is the right next step when the public record cannot resolve an integration dependency. Both paths lead to a better documented RFQ discussion.
Prepare the next conversation in three short steps
- State the platform context. Identify the equipment or platform, its operating scenario and the technical owner for the GNSS integration question.
- Separate facts from open questions. Keep model-specific published facts distinct from receiver, RF, physical, interface and environmental items that still require confirmation.
- Choose the route and document it. Continue to a published product evaluation when the evidence supports it; otherwise start a Custom/OEM discussion. Then use the RFQ checklist to share the information that is already known.
For broader context, GPS.gov’s spectrum and interference guidance explains that interference can have multiple origins. That is another reason to document the actual operating environment instead of asking a model name to answer every system-level question.
Next step: start with the clearest available evidence
If a published configuration appears relevant, browse the GNSS anti-jamming products and keep the model-specific facts attached to the evaluation record. If the project depends on unresolved platform, signal, RF, space, interface, power or environment constraints, begin with Custom OEM GNSS Integration. In either case, submit the known information through the engineering RFQ; information can be completed in stages when the project is still being defined.
Frequently asked questions
Does a published product page confirm that a configuration will fit my platform?
No. A product page provides documented information for an initial comparison. Platform fit, receiver compatibility, RF integration and installation conditions remain project-specific questions unless they are confirmed for the actual application.
Should we start with the catalog or a Custom/OEM discussion?
Start with the catalog when a published product role and its documented facts give you a credible first comparison. Start a Custom/OEM discussion when an unresolved platform, RF, physical, interface, power or environmental constraint determines the decision.
What if some engineering inputs are not available yet?
Share the information that is known and mark the rest as open. A useful early discussion distinguishes documented facts, buyer requirements and questions that still need an owner; it does not fill gaps with assumptions.
Is a Custom/OEM discussion a commitment to a special configuration?
No. It is a structured way to document project-specific requirements and identify points that need technical confirmation. It does not promise a design, performance result, certification, delivery schedule or project outcome.
Continue learning: Browse all GNSS Engineering Insights, review Applications, or request an engineering RFQ.
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.