Checking RTCM interoperability between GNSS equipment
Test message content, signal support and reference information when combining a base, caster and rover from different systems.
Start with the complete combination
RTCM is widely used to exchange GNSS information, but the presence of the acronym on two products is not a complete interoperability test. A base can output several message combinations and a rover can support only part of them. Document the exact base configuration, transport path, rover model and firmware. The combination is the unit being tested, rather than two independent claims of standards support.
Define the intended use first. A stream carrying observations for conventional RTK is different from a stream designed for another correction method. The rover must understand both the format and the meaning of the delivered information. A successful network connection demonstrates data transport; it does not demonstrate that the receiver can use every message required for the intended positioning result.
Continue learning RTCM messages: checking correction compatibility
Inventory the supported observations
Compare the constellations and signals observed at the source with those supported by the rover. Useful common observations are what matter to relative processing. A long list of source signals provides little benefit if the rover cannot track or decode them. Obtain the manufacturer guidance for the actual firmware versions and avoid assuming that capabilities listed for a newer version apply to the unit in the field.
Where the equipment allows configuration of message families or rates, begin with a documented supported combination. Keep a record of changes made during testing. Do not reduce or add messages at random simply because the bandwidth appears high. A stream can be small and incomplete or large and still incompatible. The goal is an appropriate, usable set of information delivered reliably to the receiver.
Continue learning Selecting a site for a continuously operating GNSS reference station
Keep transport and content separate
Data may travel by radio, a direct cable or an NTRIP service. A transport problem can prevent good RTCM content from reaching the rover, while a content problem can remain after the connection is restored. Inspect both layers. Confirm that bytes or messages are arriving, then inspect the receiver diagnostics to determine whether the data are accepted for positioning rather than merely received by an application.
A caster generally distributes the stream supplied to it; it should not be assumed to repair missing reference information or convert every message into a rover compatible form. If a conversion service is deliberately used, document it as another component. Preserve its configuration and version where relevant. That extra stage may explain why a direct base connection works while a relayed connection behaves differently.
Continue learning Pairing RINEX observation and navigation files correctly
Verify reference information
Confirm how the source coordinate and antenna information are represented in the chosen output. A rover using the correct observation messages can still produce an offset if the base coordinate is wrong or interpreted under an inappropriate reference definition. Keep a base setup record outside the transmitted stream so the office can verify what the operator intended the source to represent.
Check units, coordinate reference frame, epoch where applicable and antenna height conventions. These topics are often less visible than the connection screen but can have greater consequences for the final dataset. When a mixed equipment setup disagrees with control, do not immediately blame the standards implementation. A shared coordinate or antenna setup mistake can mimic an interoperability failure while the messages themselves are being decoded correctly.
Continue learning Evaluating a GNSS receiver for your actual field workflow
Run a controlled field trial
Use an open site with suitable check points and the same communications arrangement planned for production. Record the time to a usable solution as an operational observation, without treating one trial as a guaranteed product specification. Compare coordinates at more than one point and repeat important checks after a fresh initialization. Keep failed attempts in the test record because they describe the limits of the combination.
Test the relevant work conditions, including the expected separation from the base and any difficult communications locations. A bench test can confirm basic decoding but cannot establish field performance across the project. Note which environments remain untested. The resulting approval should describe a configuration and a working envelope, not a blanket statement that all equipment carrying the same standard will behave identically.
Continue learning RTCM messages: checking correction compatibility
Diagnose incompatibility with evidence
If usable data arrive but the rover does not achieve the required state, compare the stream with the receiver documentation. Use approved monitoring tools or the receiver diagnostics to inspect message availability. Preserve a short sample where permitted, along with timestamps and configuration. Give equipment support a precise description of what was transmitted and what the rover reported instead of only saying that RTK did not work.
Change one variable at a time. Testing a known working rover against the same source, or the suspect rover against a known working source, can narrow the issue. Keep the coordinate system and check point procedure consistent during these comparisons. Otherwise, a change that appears to solve decoding may simply have introduced a different reference arrangement that is no longer comparable to the first test.
Continue learning Selecting a site for a continuously operating GNSS reference station
Approve and maintain the tested setup
Create an approved configuration record listing devices, firmware, output messages, transport settings and check results. Keep this record accessible to the crew while storing access credentials privately. When firmware, a base output profile or a caster path changes, decide which parts of the trial need repeating. An interoperability approval is tied to the tested arrangement and should not silently expand to untested revisions.
Include the approved mixed equipment workflow in training. Operators should know which preset to use, what normal diagnostics look like and when to stop collection. The benefit of a standards based workflow is practical flexibility, but reliable flexibility depends on verification. A documented combination that passes meaningful field checks is far more useful than an undocumented promise that any base and any rover will automatically work together.
Continue learning Pairing RINEX observation and navigation files correctly
A reproducible compatibility matrix
For a project using several equipment combinations, maintain a small matrix rather than a single statement that RTCM works. Rows can identify source profiles and columns the rover and firmware combinations. Each approved cell should point to a test record with the message configuration, communications path and coordinate checks. An untested cell should remain visibly untested even when a similar receiver worked with the same source on another day.
When an update changes one component, the matrix helps select the tests that need repeating. It also prevents an operator from assuming that a successful direct radio trial approves an untested relayed stream. Preserve representative test logs where the project permits them, and keep the exact output profile available for restoration. This approach makes interoperability practical: the team can choose among verified arrangements while retaining a clear boundary between observed compatibility and a possibility suggested only by a standards label.
Continue learning Evaluating a GNSS receiver for your actual field workflow
Practical checklist
- Record the exact base, messages, transport and rover versions.
- Verify coordinate and antenna information separately from decoding.
- Retest important combinations after firmware or output changes.
Plan your GNSS setup
Compare the EQ10 and EQ20 receiver specifications, then discuss the configuration and support your project needs.
Compare GNSS receivers
