Choose the GNSS/INS coupling architecture by the information your receiver can supply and the operating condition the navigation solution must handle. Loose coupling uses computed GNSS position and velocity. Tight coupling uses satellite observations inside the fusion process. If an existing receiver exports only a navigation solution, keeping it is a candidate for a supported loosely coupled integration—not evidence that it can feed a tightly coupled system.
The practical purchase is the receiver, inertial equipment and enabled fusion function that work together. An anti-jamming antenna or terminal addresses another part of the system: GNSS reception. Buying that equipment does not, by itself, change the coupling architecture.
What the two architectures actually consume
SBG Systems’ INS explanation distinguishes fusion of receiver navigation outputs from integration of raw satellite measurements. It also identifies access to raw measurements as a limitation when integrating an external receiver. The names describe a data boundary, not the tightness of a cable connection.
PVT means position, velocity and time. Satellite observations can include pseudorange, Doppler and carrier phase, depending on the algorithm. Recording a PVT message as unmodified bytes does not turn it into those observations. The receiver interface guide explains how to identify the fields and transport required by the intended software.
When keeping the existing receiver is a useful starting point
If the receiver already provides the navigation outputs needed by a supported fusion product, start by comparing that integration. Changing to a receiver-inclusive GNSS/INS assembly solely because its brochure says “tight coupling” can change more of the installation than the task requires.
There are two separate questions: does the proposed fusion system accept the receiver’s actual output, and does the resulting configuration meet the intended navigation requirement? A correct answer to the first does not establish the second. Conversely, the presence of a serial or Ethernet connector does not establish the first.
For a PVT-only receiver that must remain unchanged, exclude an offer whose required input is raw observations and whose scope includes no supported route to obtain them. That is an incomplete offer for this configuration, not a claim that the receiver is defective. If changing the receiver is allowed, keep a receiver-inclusive solution in the comparison and include that replacement in the quotation boundary.
What partial satellite visibility changes
VectorNav’s GNSS/INS primer explains why individual pseudorange and Doppler measurements can aid a tightly coupled filter even when a complete GNSS fix is unavailable. It also cautions that restricted-sky advantages depend on outlier rejection and filter tuning; the architecture label is not a universal accuracy ranking.
A blocked sky and a completely absent GNSS input are different conditions. In the first, useful satellite observations may remain. In the second, there are none to contribute a GNSS update. Tight coupling does not create measurements from a signal that is not received.
OxTS provides a concrete manufacturer example in its GNSS and IMU tight-coupling explanation: its processing can use individual satellite observations in restricted visibility. That example belongs to OxTS. It is not a ResiNav feature, a transferable urban-navigation result or proof that every tightly coupled product rejects every reflected signal.
If the requirement is to use partial observations while travelling past obstructions, compare evidence for that condition and the selected configuration. If the requirement is navigation through a fully blocked interval, use the GNSS outage-planning guide to define the duration and separately supplied aiding. Changing a coupling label alone does not answer the full outage requirement.
A quotation comparison that changes when the receiver must stay
Consider a hypothetical integrator retaining a PVT-only receiver. Offer A adds an inertial unit and an enabled fusion function documented to accept that receiver’s navigation stream. Offer B supplies an integrated GNSS/INS assembly with its own receiver and observation-based fusion.
If retaining the original receiver is mandatory, A remains a candidate for the defined integration. B is a replacement proposal, not an equivalent add-on. If receiver replacement is permitted and the operating requirement includes partial-satellite updates, compare B’s documented capability against that condition. A is not automatically a failure, and B is not automatically the better-performing product.
Now consider Offer C: an IMU, a raw-observation input requirement and no identified observation source or enabled fusion software. C does not yet describe the complete working integration. Its hardware price cannot be compared as the total price of A or B. The missing purchase items are specific: the required data source and the processing function, not a generic request to “confirm compatibility.”
For a fair comparison, name the receiver being retained or replaced, the inertial equipment, fusion software or enabled option, and who delivers the navigation output. Keep an operational real-time output separate from a trajectory calculated after the mission. NovAtel’s Inertial Explorer is an example of GNSS/INS post-processing with loose and tight modes; a post-mission trajectory is not the live input a controller needed earlier.
Add reception protection for the part of the order that needs it
When interference protection is also required, first identify the GNSS reception path in the chosen architecture. Use the ResiNav product catalogue to compare the published signals and product roles for that portion of the purchase.
For an existing receiver path requiring GPS L1 and BeiDou B1, RN-S65-4CH-SNB has a published signal and RF-output record to screen. That is a reception-protection comparison, not an offer of fusion software, inertial hardware or compatibility with a named GNSS/INS product.
The approved RN2501-AJS-4CH-DPA configuration provides PVT through HDMI without a separate GNSS receiver to obtain those outputs. That fact does not establish a raw-observation feed, an INS function or acceptance by an external fusion system. Use the RN2501 product record only when that documented PVT role matches the enquiry.
You can start with the receiver you intend to keep, the output it exposes and the navigation condition that matters. Follow the selected product’s existing enquiry route for the GNSS protection portion. The coupling decision tells you which additional receiver or fusion scope belongs in the order; it does not require buying every function from one supplier.
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.