GNSS RF coexistence review is the engineering step that asks whether the radios, power electronics, antennas, cable path and receiver installed on one platform can be documented and evaluated together before an anti-jamming configuration is discussed. It is useful for mobile, industrial, marine and OEM platforms where GNSS is only one part of a larger RF and control system.
The review does not certify an installation or guarantee positioning availability. It turns a broad concern about “interference” into a bounded set of inputs: what is installed, when it operates, which GNSS and non-GNSS signals share the platform, what the receiver reports, how the controller reacts and what evidence is needed to make a selection decision.
For the wider system context, start with the ResiNav Technology Centre. For a record of the platform RF path, see the GNSS RF path documentation guide.
When the question is specifically about nearby emissions, harmonics, spurious outputs or installation inputs close to the receiver, use the GNSS adjacent-band interference review to define the narrower evidence package.
1. Define the coexistence question before choosing hardware
A useful review begins with a decision that can be tested or documented. Examples include whether a GNSS antenna location conflicts with another antenna, whether a radio duty cycle coincides with a loss-of-position event, whether a receiver status can reach the platform controller, or whether a proposed RF path needs an engineering review before procurement.
Do not begin with a promise that a platform “will be protected.” Instead, state the platform role, operating area, GNSS receiver, required navigation or timing outputs, installed emitters, expected operating modes and the consequence if GNSS data becomes stale, invalid or unavailable. This makes it possible to distinguish a configuration question from a field-performance claim.
2. Build an installed-RF inventory
Coexistence problems are often discovered late because a platform list only names the GNSS receiver and antenna. The review should also include equipment that transmits, switches power, produces high-speed digital activity or changes state near the GNSS installation. An item on the list is an input to investigate, not proof that it causes interference.
| Review item | What to document | Why it matters to the engineering review |
|---|---|---|
| GNSS antenna and receiver | Model, bands, mounting zone, receiver firmware, relevant status outputs and intended use. | Establishes the configuration being reviewed. |
| Co-located antennas and radios | Radio type, frequency range, antenna location, transmit modes, duty cycle and known simultaneous-operation cases. | Identifies potential coupling and operating overlap to investigate. |
| RF path | Cable type and length, connectors, inline components, routing, grounding or shielding notes and change history. | Provides a traceable path between the antenna and receiver input. |
| Power and electronics | Supply architecture, converters, motors, drives, cameras, compute hardware and switching conditions near the GNSS system. | Defines platform conditions that should be considered during diagnosis or validation. |
| Control response | Validity flags, age or timeout rules, alarms, source-selection logic, fallback state and return-to-service condition. | Connects receiver observations to an operational decision. |
Receiver manufacturers describe in-device and adjacent-band interference as an integration issue: nearby transmitters, amplifiers, digital electronics and RF path choices can affect receiver behavior. The u-blox RF-interference guidance and NovAtel’s co-located LNA integration note are useful examples of questions to investigate. They do not establish performance for a ResiNav product or a particular platform.
3. Map the RF and information paths separately
The RF path and the information path answer different questions. The RF path starts at the antenna and includes cable, connector, inline component and receiver input. The information path starts at the receiver output and includes message formats, timing, network or serial interfaces, controller handling, alarm presentation and any fallback logic. A configuration can have a well-documented RF path but still fail to give a controller a usable status indication.
Record the receiver interface and the platform’s interpretation of its outputs before assuming that an alarm, validity flag or position message supports a safety or operational decision. The GNSS receiver compatibility guide explains why receiver, interface and platform responsibilities must be reviewed together.
4. Choose observable conditions and evidence
The purpose of a coexistence review is not to label every anomaly as “jamming.” It is to define what can be observed during the conditions relevant to the platform. Depending on the integration question, the evidence may include receiver status, satellite or signal metrics exposed by the receiver, time-aligned platform events, radio transmit state, controller source selection, timestamps, configuration identifiers and a record of installation changes.
Use an agreed time base. Describe each event in sequence: a platform mode or RF condition begins, the receiver reports a state, the interface delivers an output, the controller reacts, and the platform reaches a defined next state. If the available information is not sufficient to establish causation, record the result as inconclusive rather than attributing a source without evidence.
A controlled, lawful test method may be appropriate when the engineering question requires it. Rohde & Schwarz describes repeatable GNSS/interference scenarios for receiver assessment, including recovery behavior after a simulated condition. Such material supports the value of controlled evidence; it is not a specification, certification method or performance promise for a ResiNav solution.
5. Keep mitigation, detection and recovery as separate decisions
Detection answers what the receiver or platform reports. Mitigation concerns measures intended to reduce susceptibility or manage a condition. Recovery concerns how the system returns to an approved operating state after its inputs again meet the platform’s rule. These terms should not be collapsed into one checkbox.
For example, a receiver may expose an indication while a controller has no defined handling rule. A platform may have a fallback state while the installation record lacks the conditions required to leave it. Conversely, a change to antenna location, cable routing, power hardware or firmware can make prior evidence non-comparable. Documenting those boundaries protects procurement and engineering teams from treating a component choice as a complete system conclusion.
6. Prepare a supplier-facing review package
A supplier can provide a more useful engineering response when the request distinguishes published facts from platform-specific questions. Begin with the published product catalogue, then provide the platform information that still needs review. If the decision is between a published configuration and custom integration, the published product versus custom integration guide can help frame the distinction.
Coexistence review checklist
- Platform type, operating environment and GNSS-dependent function.
- Receiver, antenna, bands, firmware and relevant configuration identifiers.
- All nearby antennas, radios, switching electronics and operating states to be reviewed.
- RF path drawing or documented cable, connector, inline-component and mounting constraints.
- Power, grounding, shielding and packaging conditions that affect the installation boundary.
- Required receiver outputs, controller inputs, timing reference and fallback or alarm logic.
- The engineering question, permitted validation method and evidence expected after review.
For an installation-oriented record, review the GNSS installation documentation checklist. To prepare a scoped request, use the ResiNav RFQ form and include the items above. Product compatibility, performance and deployment suitability require confirmation for the exact platform and current product documentation.
For a reusable record of the installed RF environment, receiver observations, controlled evidence and follow-up questions, download the GNSS RF interference review worksheet (PDF) or the editable XLSX worksheet. The tool supports preparation; it does not establish product compatibility, certification or platform performance.
Frequently asked questions
What is a GNSS RF coexistence review?
It is a documented engineering review of the GNSS installation alongside other platform RF, power, electronics and control-system conditions. Its purpose is to define inputs, questions and evidence before a configuration or test decision is made.
Can anti-jamming hardware solve every interference problem on an integrated platform?
No. A component choice does not replace review of antenna placement, RF path, receiver configuration, platform electronics, interfaces or controller response. The appropriate configuration and its suitability must be evaluated for the specific platform.
Which platform systems should be included?
Include the GNSS system, nearby antennas and radios, power conversion, motors or drives, cameras or compute hardware, cable routing and any operating mode that may coincide with a GNSS event. Inclusion identifies a review input; it does not prove causation.
Does a documented review prove field performance?
No. It provides a traceable basis for engineering decisions and validation planning. Field conditions, installation changes, firmware, receiver settings and operating policy can change the observed result.
What should be attached to an RFQ?
Provide the platform role, receiver and antenna information, RF path and mounting constraints, co-located equipment, interfaces, expected receiver or controller outputs, operating conditions, engineering question and evidence required for acceptance.
Engineering references
- NIST: Responsible Use of Positioning, Navigation and Timing Services
- Rohde & Schwarz: GNSS coexistence and interference testing
- u-blox: reducing RF interference impact on GNSS receiver performance
- NovAtel: interference from a co-located LNA
Next step
If the platform has a documented receiver, RF path and control question, request a ResiNav engineering review. Include the intended application and the evidence needed for the decision; do not assume that a generic configuration establishes platform performance.
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.