A filtered GNSS antenna, an inline RF filter and receiver interference suppression are not interchangeable purchases. For an adjacent-band problem, shortlist the option that acts before the vulnerable stage while preserving the signals the receiver needs. A filter selected only by its connector or a claim of “high rejection” is not enough.
This guide separates those buying decisions from the installation record needed to assess them. For the wider platform investigation, use the RF coexistence guide; for equipment and operating-state capture, use the interference-environment checklist. A nearby transmitter is a lead to investigate, not proof of cause.
1. Choose where filtering belongs
When the antenna amplifier is the vulnerable stage: consider an antenna with documented preselection ahead of its low-noise amplifier (LNA), rather than assuming an extra box at the receiver solves the problem. Calian describes strong out-of-band signals driving antenna amplifiers into nonlinear operation, and prefilters protecting those stages. Its design discussion also identifies a trade-off: filter loss before amplification increases noise figure. These are design principles, not measured ResiNav characteristics. See Calian’s filtering explanation.
The receiver dynamic-range explanation separates analogue compression, ADC clipping and quantization before comparing gain changes or digital mitigation.
When the antenna output remains usable but a downstream receiver stage needs protection: an inline filter is a candidate. Its position matters: a filter after an already overloaded antenna amplifier cannot undo distortion created upstream. Do not buy the downstream filter as a substitute for protecting that first stage. Review the antenna’s own filtering before deciding where an additional component belongs.
When the interference is narrowband or near the receiver’s passband edge: investigate supported receiver filtering before automatically replacing the antenna. NovAtel documents notch filtering for a narrow frequency range and bandpass filtering at GNSS band edges; it warns that notch width affects retained signal power. Availability and configuration are receiver-specific. This is an example of a purchase option, not a claim that ResiNav implements those receiver functions or is compatible with those models. See the OEM7 Interference Toolkit.
When the unwanted energy occupies the required passband: an ordinary bandpass filter does not distinguish wanted and unwanted signals at the same frequency. Do not treat out-of-band rejection as a general anti-jamming rating. For a spatial-mitigation option, use the antenna and terminal architecture comparison to identify the processing hardware included in the purchase, then screen the published ResiNav configurations. Element count alone does not establish suitability for the interference or installation.
2. Compare the filter offer, not just the rejection number
For two otherwise plausible offers, compare attenuation at the identified interfering frequency and insertion loss across every wanted signal band. A larger rejection number at an unrelated frequency does not resolve that comparison. Keep the response curve and the intended filter position together in the purchase description; “GNSS filter” alone leaves both ambiguous.
For example, suppose an active antenna feeds a receiver and a quotation offers an inline filter at the receiver connector. If the suspected overload is inside the antenna, reject that quotation as a complete remedy for the stated problem; it may still have a separate downstream role. If the antenna stays linear and the blocker reaches the receiver, retain it as a candidate for that downstream role. This is a conditional selection example, not a diagnosis or a ResiNav test result. The underlying filter-before-LNA principle is illustrated on page 8 of the u-blox RF interference white paper.
If a component is described only as “L1,” use the GPS L1 and GLONASS G1 coverage guide to distinguish an antenna range, an RF passband and a terminal signal declaration before treating it as a G1 match.
3. Build an adjacent-band input record
The record should include both the GNSS installation and equipment that can change the RF or electrical environment. Listing an item does not assign causation; it ensures that a relevant input is not omitted when the installation, receiver configuration and operating modes are discussed.
| Input to document | Questions to capture | Evidence useful to the review |
|---|---|---|
| GNSS receiver and antenna | Which receiver, antenna, signal modes, firmware and receiver outputs are in use? | Published documentation, configuration identifier and receiver status records. |
| Nearby RF equipment | Which radios, antennas, amplifiers or wireless links operate nearby, and in which modes? | Equipment list, operating schedule, antenna locations and known transmit states. |
| Digital and power equipment | Which clocks, converters, motors, drives or compute loads change state near the installation? | Platform mode record, wiring diagram and time-aligned event data. |
| RF and cable path | What sits between antenna and receiver, and what has changed? | Cable type and length, connectors, inline components, route and change record. |
| Controller response | How does the platform interpret validity, alarms, stale data and source changes? | Interface description, timeout rule, fallback logic and acceptance evidence. |
The GNSS RF path documentation guide is useful for recording cable, connector and inline-component changes. The receiver compatibility guide covers the separate interface and platform-responsibility questions that should not be hidden inside an RF discussion.
4. Separate RF observations from platform behavior
An RF installation record and a control-system record answer different questions. The RF side follows the antenna, cable, connector and receiver input. The platform side follows receiver outputs, message timing, network or serial interfaces, controller decisions, alarms, source selection and fallback behavior. A technically tidy cable record does not by itself demonstrate that a controller receives a usable warning; a controller rule does not by itself explain the RF condition that preceded it.
For each observed event, retain the timestamps, configuration identifier, receiver indications exposed by the receiver, platform operating mode and the state of relevant nearby equipment. Do not label every change “jamming.” The point is to preserve enough evidence to decide whether the next action is a configuration review, an installation check, a controlled test or a broader engineering investigation.
5. Plan controlled evidence before changing hardware
Hardware changes made before a baseline is captured can make later comparison difficult. First agree what will be observed, under what lawful and controlled condition, who records it and what decision the evidence is intended to support. The required evidence may include receiver-status records, signal or satellite metrics that the receiver exposes, radio or platform mode, controller state, timing information and a record of installation changes.
A receiver assessment is not the same as a platform acceptance decision. The receiver evaluation guide explains how controlled receiver observations and recovery questions can be framed. The platform team must still decide how its interfaces, alarms and fallback logic are interpreted for the intended operation.
6. Prepare a supplier-facing engineering request
Start with the published product catalogue and the available product documentation. Then separate published information from platform-specific questions that still require confirmation. A supplier can give a more useful response when the request identifies the receiver and antenna, installed RF path, adjacent equipment, interfaces, platform operating modes, mechanical constraints and evidence expected before acceptance.
Supplier confirmation checklist
- Published configuration under consideration and current documentation reference.
- Receiver model, relevant signal modes and available status or interface outputs.
- Antenna location, cable path, connector and inline-component information.
- Nearby radios, power electronics, digital equipment and operating modes to review.
- Platform controller handling for stale, invalid or unavailable GNSS information.
- Engineering question, controlled-evidence method and decision needed after the review.
For help comparing what a supplier response does and does not establish, see the GNSS anti-jamming supplier-proposal comparison guide. When the inputs are ready, request a ResiNav engineering review. Include the platform boundary and evidence required; do not assume that a generic configuration proves suitability for an unreviewed installation.
When the review needs a structured record of nearby emitters, adjacent-band observations, installation changes and acceptance evidence, use the adjacent-band review input worksheet (PDF) or the editable XLSX version. It identifies questions and evidence to review; it does not attribute cause or prove a configuration.
Frequently asked questions
What is a GNSS adjacent-band interference review?
It is a documented engineering review of nearby RF, electrical and installation conditions that may need investigation alongside a GNSS receiver. It defines the inputs, observations and evidence needed before a configuration, test or procurement decision is made.
Does adjacent-band interference always come from another radio?
No. The review can include radios and antennas, but also power conversion, digital electronics, cable routing, inline RF components and operating-mode changes. Their inclusion identifies potential review inputs; it does not prove that any one item causes an observed result.
Can a receiver test replace a platform integration review?
No. Receiver observations are useful evidence, but the platform decision also depends on antenna installation, RF path, data interfaces, controller handling and the intended operating conditions.
What should be recorded when a GNSS event is observed?
Record the receiver indication available to the platform, timestamps, platform mode, relevant nearby-equipment state, installation or configuration identifier and the controller response. The available fields depend on the receiver and platform; do not infer data that the system does not expose.
What should be included in an RFQ?
Include the platform role, receiver and antenna information, RF and cable path, nearby equipment, interfaces, operating modes, installation constraints, engineering question and the evidence needed for the decision. Compatibility and performance require confirmation for the exact platform and published configuration.
Engineering references
- NIST: Responsible Use of Positioning, Navigation and Timing Services
- u-blox: reducing RF interference impact on GNSS receiver performance
- NovAtel: interference integration guidance
- Rohde & Schwarz: GNSS coexistence and interference testing
Next step
If the platform has a defined adjacent-band question, a documented receiver and a known installation boundary, request an engineering review. State the evidence needed for the decision so that published product information and platform-specific requirements remain clearly separated.
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.