Receiver compatibility is often treated as a connector check. For a GNSS anti-jamming integration, that is not enough. The engineering review should also establish the supported signals, RF boundary, antenna power, timing outputs, data interfaces, cable path and platform responsibilities.
This guide explains what evidence to collect before asking an antenna, terminal or receiver supplier to confirm compatibility. It is a documentation framework, not a claim that a particular configuration is suitable for every platform.
Where the review also involves nearby emitters, converter activity or adjacent-band observations, the adjacent-band interference review identifies the platform inputs to document alongside the receiver interface.
Decision rule: a matching connector is only a mechanical clue. Treat compatibility as an open engineering question until the RF path, electrical supply, GNSS signals, control and status behavior, and installation constraints have each been checked against the selected versions and then exercised on a bench.
1. Compatibility starts with the receiver interface
Begin with the exact receiver manufacturer, model, hardware revision and firmware version. Similar product names can hide different RF ports, supported signals or interface behavior. Record the information from current receiver documentation rather than assuming that one family member represents another. The selected anti-jamming device and platform controller also need named revisions and an explicit owner for each interface.
Keep the GNSS receiver, or keep the computer and application?
For an external RF-output protection device, first establish whether the receiver has a supported GNSS antenna input. If the existing equipment has no accessible input, retaining its computer and application may still be possible by selecting a different position source. That is a receiver-change purchase, not protection of the original built-in receiver.
A Bluetooth connection describes a data link; it does not establish where GNSS RF can enter. For example, Trimble’s Ranger 7 documentation rules out an external antenna for its integrated GNSS receiver while describing external-receiver options. Conversely, the Eos Arrow Gold+ specification lists both Bluetooth and an SMA antenna connector. These are examples of different interface arrangements, not confirmation that either product works with a ResiNav terminal.
- Keep the receiver when a documented external GNSS RF input is available. An external protection device can enter the shortlist for that RF path. Compare required signals, RF levels, impedance and the remaining interface-matrix requirements below. The receiver remains responsible for producing position data for the host; adding an RF device does not itself change the host’s data protocol.
- Keep the computer, but change the position source when its built-in receiver has no usable RF input. If the application can accept a suitable external receiver, compare a receiver-inclusive purchase: the new receiver, any separately required RF protection, and the connection or software integration that delivers its data to the existing application. The original embedded receiver is no longer the position source being protected. Bluetooth pairing alone is not proof that the application consumes the required messages and status.
- Keep both fixed only if there is a supported integration route. If the receiver cannot change and its manufacturer provides no usable RF input or approved integration route, do not treat an external RF-output terminal as a qualified retrofit. A Bluetooth or USB data adapter does not create an antenna input. This constraint stops that RF-retrofit option; it is not a claim that every receiver-side mitigation option is unavailable.
For the first branch, RN-S65-4CH-SNB provides a published GPS L1 / BeiDou B1 signal record and RF-output specifications to compare with the retained receiver. Other signal requirements belong in the product catalogue comparison; Bluetooth is not a ResiNav compatibility filter. For a receiver-change purchase, use the receiver interface guide to define the data handoff separately. Record in the quotation whether the existing receiver is retained or replaced, not merely that the existing computer is retained.
Receiver and anti-jamming interface matrix
Use the matrix as a comparison worksheet, not as a specification for a ResiNav product. Enter values only from the receiver manual, the selected device documentation and the platform design. Mark any missing value confirm in engineering review; a shared connector name or product label does not close an open row.
| Boundary | Receiver-side evidence | Anti-jamming device and platform evidence | Decision to record |
|---|---|---|---|
| Interface role | Identify each antenna/RF input and its intended source. | Identify the selected device output, terminal function and downstream owner. | Confirm that output and input roles match; do not infer an architecture from a product name. |
| RF ports and connectors | Document connector type, port count, impedance and input limits from the receiver revision. | Document output ports, connector transitions, impedance and the planned path. | Confirm both the physical connection and the electrical RF boundary. |
| GNSS signals and bands | List required constellations, bands, signals and antenna-port requirements. | Check the selected device’s documented output and supported signal path. | Record each required signal as confirmed or confirm in engineering review. |
| RF level and dynamic range | Record documented input level limits and receiver assumptions. | Record documented gain, loss, output level and dynamic-range limits where available, including cable loss. | Review the complete RF budget; do not invent a margin or performance result. |
| Bias and power | Record antenna-bias voltage, current limit, protection and monitoring behavior. | Identify device supply, bias pass/block behavior and any injector or external power path. | Name the power owner and confirm no conflicting supply arrangement. |
| Timing | Record 1PPS, event inputs, time messages, level, polarity and latency requirements. | Document relevant device timing behavior and the platform’s reference and logging needs. | Confirm the timing boundary and evidence required by the platform. |
| Navigation data and update behavior | Record UART, RS-232, RS-422, CAN, Ethernet or USB interfaces as applicable, plus protocol, messages and output rate. | Document terminal outputs if present and the controller’s accepted format, rate and startup behavior. | Confirm that the intended data consumer can process the documented interface. |
| Control, status and faults | List receiver status, validity flags, alarms and configuration controls. | List device monitoring/control interfaces and platform timeout or fallback requirements. | Assign fault detection, stale-data handling and recovery ownership. |
| Cable and mechanical path | Record receiver location, cable type, length and connector transitions. | Record mounting envelope, routing, insertion loss, strain relief and service access. | Confirm the installed path against drawings and documented limits. |
| Environment and revisions | Record hardware, firmware, temperature and other applicable operating limits. | Record selected device version, enclosure, grounding, vibration and ingress constraints where applicable. | Carry all open limits and version assumptions into the engineering review. |
2. Separate antenna, terminal and receiver responsibilities
The word system can refer to several architectures. An anti-jamming antenna may provide a processed RF output to an external receiver. A terminal may combine antenna processing, receiver functions and platform interfaces. The receiver may also provide antenna bias, timing outputs or monitoring data. The exact boundary must come from the selected product documentation.
Document ownership for RF conditioning, antenna power, receiver configuration, navigation output, timing, diagnostics and fault handling. This prevents an interface from being assumed to belong to both components—or to neither. For the broader architecture, see the antenna–receiver–platform integration guide.
3. Build a receiver compatibility evidence package
- Identify the receiver precisely. Record manufacturer, model, hardware revision, firmware version and the applicable datasheet revision.
-
List required GNSS signals—and separate passage from protection. A band reaching a receiver is not necessarily a band protected against interference. Compare the RF bands passed by the offered configuration with the bands explicitly covered by its anti-jamming function. A broad antenna range or a receiver’s tracking list cannot supply the missing protection claim.
For example, infiniDome’s SunStone product record separates selected protected bands from two additional customer-selected GNSS bands that pass through without protection. This is a stated feature of that manufacturer’s configurations, not a description of ResiNav hardware.
Hypothetical quotation comparison—not measured hardware: both offers pass GPS L1 and L2 to an external receiver.
- Offer A: documents L1 protection and unprotected L2 passage.
- Offer B: documents protection for both L1 and L2.
If the order requires documented protection on both bands, A does not meet that scope; B remains a candidate for the remaining interface and evaluation checks. If the order requires L1 protection while retaining ordinary L2 reception, A addresses that narrower band requirement. B’s additional protection is not automatically necessary. Neither offer proves that the receiver will maintain a valid solution under unspecified interference.
For a ResiNav shortlist, start with the named signals in the published product records. Do not relabel those entries as protected-versus-passthrough maps or infer such a map from an RF output frequency. Carry the required protection scope into the selected model’s enquiry; you can begin with what is known. For signal names and frequency-path matching, use the signal-coverage guide.
- Provide the RF interface diagram. Show every port, connector, adapter, splitter, cable and power-injection point.
- Define timing and data outputs. Include electrical levels, polarity, protocols, baud rates, message sets and update requirements.
- Document power and grounding. Identify power sources, voltage ranges, current limits, grounding points and any monitoring behavior.
- Describe the installation. Record cable routing, cable length, enclosure location, nearby emitters and environmental constraints.
- State the review objective. Separate compatibility confirmation, integration design, documentation delivery and any later verification activity.
4. Use a staged compatibility review
A practical review can proceed in five stages: confirm the required signals; verify the RF and power boundary; verify timing and data interfaces; review the cable and installation context; then record every open item and its evidence owner. A connector match should not close the review when the supported bands, bias behavior or message interface is still unknown.
If the platform team cannot yet provide all information, label each unknown explicitly. An unknown field is safer than a guessed value because it gives the engineering team a defined item to resolve.
5. Common compatibility gaps
- The connector type is known, but the required GNSS bands are not confirmed.
- Antenna bias voltage is listed, but current limits and monitoring behavior are missing.
- 1PPS is requested without electrical level, polarity, reference edge or latency expectations.
- A serial interface is named without protocol, baud rate or required messages.
- Cable length is provided without cable type, insertion loss or connector transitions.
- The receiver model is known, but its hardware or firmware revision is not.
- Anti-jamming and anti-spoofing are treated as interchangeable capabilities without defining the required product version and review scope.
6. Validate the interface on a bench before installation
Documentary compatibility narrows the candidates; it does not establish integrated behavior. Freeze the receiver, anti-jamming device, firmware, cabling and platform interface configuration for each run. Record a clean baseline first, then use only controlled and lawful adverse conditions appropriate to the test facility. The Resilient GNSS Receiver Evaluation guide provides a fuller test-planning path.
- At baseline: record receiver status, required signals, navigation and timing outputs, device status, supply conditions and time-aligned logs.
- During a controlled disturbance: observe alarms, validity flags, data age, output continuity and the platform’s timeout or fallback behavior; do not infer these from connector fit.
- During recovery: record the sequence from disturbance removal to receiver reacquisition, stable status, interface delivery and approved return-to-service criteria.
- Across repeat runs: retain configuration identifiers, event times and raw observations so an engineer can distinguish a reproducible interface result from an assumption.
A bench record applies only to the tested configuration and conditions. It is not a field-performance, certification or compatibility guarantee for another receiver or platform.
7. Product and documentation path
Use the published ResiNav product catalogue to identify a candidate configuration, then compare its documented interfaces with the matrix above. A product family or element count alone does not establish receiver compatibility. The engineering Resources hub groups the related evaluation, integration and procurement guides; the Technology overview explains the broader antenna–receiver–platform boundary. Request the current product documentation for the exact version under review rather than assuming a specification from a different model.
Prepare an engineering review or RFQ
- Which receiver model, hardware revision and firmware version will be used?
- Which GNSS constellations and frequency bands must remain available?
- Who supplies antenna power, and what voltage and current constraints apply?
- Which RF, timing, navigation-data and diagnostic interfaces are required?
- What cable type, length, routing and connector transitions are planned?
- Which drawings, interface-control documents or test records must be delivered?
Use the GNSS anti-jamming RFQ checklist to combine these receiver questions with platform, installation and documentation inputs. Include the interface matrix with each row marked confirmed, open or not applicable, and identify the document owner for open items.
Frequently asked questions
Does a matching connector confirm receiver compatibility?
No. The review should also confirm the RF bands, impedance, power or bias behavior, signal levels, port count and any documented input limits.
Should antenna power always come from the receiver?
Not necessarily. The selected architecture may use receiver bias, a terminal power path or a separate injector. Record the actual source, voltage, current limit and monitoring behavior.
Are 1PPS and navigation messages interchangeable?
No. 1PPS is a timing signal, while navigation messages carry data. An integration review should document both interfaces and how the platform uses them.
Can anti-jamming and anti-spoofing be reviewed as the same function?
No. They are different scopes. Identify the required product version, receiver behavior, interface responsibility and evidence expected for each function.
Next step: discuss the information you have
Compare the published products or request an engineering review or quotation with the model or application, estimated quantity and requirements you already know. You do not need a completed interface matrix or full drawing package for first contact. Mark missing receiver or interface details as “to be confirmed” and develop them using the checklist above during subsequent discussions. Confirming compatibility still requires the relevant receiver, signal and interface evidence; an initial enquiry is not compatibility approval.
Where receiver behavior must be considered alongside nearby transmitters and the installation RF path, use a platform-level GNSS coexistence planning record before an engineering review.
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.