Keep an existing RTK receiver when it can use the observations and correction messages required by the job, and a suitable stream can reach its configured input. If the mismatch is the selected correction stream, change that stream before buying another receiver. If the required capability is absent from the receiver and cannot be added through a documented configuration or upgrade, changing the subscription alone will not provide it.
The labels multi-constellation, RTCM 3 and NTRIP are not enough to make that decision. Compare the receiver's supported correction inputs with the actual stream, including its constellation and signal content. This guide concerns observation-based RTK corrections from a local base or network. PPP and state-space correction services require their own compatibility assessment.
For the underlying positioning mechanisms, see how DGNSS, RTK and PPP use different reference information, and why a shared delivery protocol does not make their correction data interchangeable.
Start with the measurement set the job needs
A receiver may track several constellations without using all of them in the intended corrected solution. Begin with the required positioning mode and the signals that must participate in it. Then distinguish three questions: what the receiver measures, what the correction source supplies, and what the receiver can decode and use.
This changes the purchasing discussion. “We want to keep our GPS/Galileo RTK receiver and use both constellations with this service” is an actionable requirement. “Both products support RTCM” leaves the important choices unresolved.
Do not add an interference-mitigation device to solve a missing correction format. Satellite reception and correction delivery are separate paths. The existing GNSS anti-jamming versus RTK guide explains which function belongs in each purchase.
Match message content, not just the RTCM label
RTCM is a family of standardized messages, not one fixed payload. NovAtel's OEM7 documentation distinguishes older GPS/GLONASS observation messages from Multiple Signal Messages, or MSM. For example, RTCM 1074 is GPS MSM4 and 1094 is Galileo MSM4; 1077 and 1097 are their MSM7 counterparts. MSM4 carries code, phase and carrier-to-noise information, while MSM7 adds higher-resolution content and Doppler information. Station information is another part of the stream: messages 1005 and 1006 describe the reference antenna position, with height information in 1006. These examples are not a complete configuration recipe. See the manufacturer's RTCM message documentation.
For a purchase comparison, put the actual message types and required signals beside the receiver's input support for its installed firmware and enabled configuration. A specification describing what a base can output does not establish what a different rover can accept. Nor does a receiver's ability to output a message prove that it accepts that message as a correction input.
Choose the supported content needed for the job, not the largest message-number list. NovAtel's correction-output command documentation illustrates why this matters: its predefined RTCMV3, MSM4 and MSM7 selections produce different message sets. That is a documented OEM7 configuration example, not a universal setting for other manufacturers.
Select the right stream before replacing equipment
One correction-network account can expose several streams. A mountpoint identifies the selected source within an NTRIP service; it is not simply another name for the account. Trimble Access documents selecting a mountpoint and forwarding its base data to the connected receiver. A successful network login therefore establishes access, not that every available stream fits the receiver. See Trimble's NTRIP source-selection instructions.
There are real differences within a single network. Montana State Library lists NEMTVRSRTCM3 as an RTCM 3.1 stream for GPS and GLONASS, while NEMTVRS_MSM is listed with GPS, GLONASS, Galileo and BeiDou. This is an operator-published example of distinct choices, not a recommendation to use that regional service elsewhere. Its mountpoint and format table shows why buying “network access” and selecting suitable data are separate decisions.
If a suitable mountpoint is already included in the buyer's access, selecting it may remove the need for replacement hardware. If it is not included, the next quotation may be for different service access or base configuration. Neither outcome can be inferred from the subscription name alone.
Decide which part of the order should change
The order of these decisions matters: a transport problem does not by itself justify replacing the positioning receiver, and a new data service cannot add missing receiver hardware capability. Where documentation is incomplete, retain an unresolved compatibility item rather than converting it into either approval or proof of non-support.
Keep the complete stream within the delivery budget
A data connection must carry the selected content, not merely stay connected. Trimble's Alloy configuration documentation describes an RTCM bandwidth limit that reduces the number of satellites included when output would exceed the limit. That can change the data delivered, not just its size. This is a specific manufacturer implementation; see the Alloy port and RTCM output settings.
Consequently, a smaller stream is only a valid alternative when it still supplies the agreed observations and ancillary information at suitable rates. Do not silently remove the very constellation that motivated the purchase. If the receiver and source already agree on the content, compare delivery changes before treating the receiver as obsolete. The receiver interface control guide covers port capacity and message scheduling without duplicating that calculation here.
Worked purchase decision: a retained GPS/Galileo rover
Consider a hypothetical integrator who owns a GPS/Galileo RTK receiver. The next job requires both constellations, but the selected correction stream contains only GPS/GLONASS observations. This is an illustrative configuration, not a ResiNav product claim or customer case.
If the installed receiver is documented to accept and use the alternative stream's GPS/Galileo messages and signals, and the delivery path carries the complete stream, the first candidate order is a stream or configuration change. There is no basis in that mismatch alone to order a second receiver.
If the receiver can only use the older correction input and has no documented upgrade path for the required Galileo processing, the alternative stream does not solve the purchase requirement. The buyer must compare a capable receiver configuration or explicitly accept a reduced job specification. A communication adapter cannot manufacture missing satellite observations or positioning capability.
Before final acceptance, demonstrate the selected stream on the agreed receiver configuration: data arriving, messages decoded, required observations used and the intended positioning mode reported under the test conditions. Connection status alone is insufficient. Coordinate reference, service coverage and job-specific accuracy acceptance remain separate requirements; passing this compatibility screen does not guarantee a fixed solution everywhere.
Keep GNSS protection as a separate, defined purchase
Once the receiver and correction arrangement are selected, an additional GNSS interference-protection requirement can be evaluated against that retained signal path. Use the ResiNav product catalogue to compare published signal coverage, product form and model-specific output records, then continue through the selected product page's enquiry route.
ResiNav supplies its own-brand GNSS protection products. The catalogue is not an offer of an RTCM decoder, correction subscription or complete RTK integration service. This guide does not establish RTCM support in any ResiNav model. Its purchase outcome is more specific: keep equipment that can perform the required role, change the stream or configuration when that resolves the mismatch, and buy replacement hardware only for a capability the retained arrangement cannot supply.
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.