RTCM SC135: a common radio language for RTK

Two GNSS receivers can understand the same RTCM correction messages and still fail to communicate over radio. The base is sending useful data, the rover knows how to use it, and the radios may even be tuned to the same frequency. But the radio link has its own language: how a transmission starts, how data is packaged, and how errors are detected and corrected.

RTCM SC135 gives equipment manufacturers a shared specification for that link. For users of real-time kinematic positioning, or RTK, that creates a path toward more flexible equipment choices and more predictable correction delivery.

Our work with the SATEL-EASy+ has given us a useful perspective on this standard alongside the radio’s other protocol families. Many of SC135’s building blocks are familiar. Its appeal is how it combines them into a common radio transport designed for real-time GNSS applications.

The two meanings of “RTCM support”

An RTK base supplies observations and other information that help a rover calculate a precise position. A common way to represent that information is with RTCM correction messages. Getting those messages to the rover is a separate job.

SC135 is the committee name commonly used for the radio protocol. The published specification is RTCM 13500.1, Radio Layer for Real-Time DGNSS Applications, first published in September 2023. RTCM identifies incompatible vendor radio layers as the problem the standard addresses, even where the equipment already exchanges standardized correction messages. RTCM’s description of the standard.

This distinction matters when choosing equipment. Support for RTCM 3 corrections alone does not establish radio compatibility. Both radios also need a compatible transport and matching operating settings.

SC135 transports application data; it does not need to interpret each GNSS message it carries. This separation lets the correction format and radio implementation develop independently.

What SC135 brings to the link

Packet integrity as a baseline

A radio packet contains both the data being delivered and information that tells the receiver how to handle it. SC135 requires error-detection checks, known as cyclic redundancy checks or CRCs, on the packet header and the data it carries.

Protecting the header matters because a damaged length or control field can affect how the receiver interprets an entire packet. Protecting the data helps the receiver reject transmissions damaged in transit. These checks substantially reduce the chance of passing corrupted data onward, although no finite checksum detects every possible error.

Several older families also include strong integrity checks. The useful distinction is that SC135 makes header and data checking part of its baseline, including when forward error correction is disabled. With some other modes, the level of protection depends on configuration.

Error correction for a broadcast workload

Forward error correction, or FEC, adds redundant information so a receiver can repair some transmission errors. SC135 offers profiles with and without FEC. Its protected profiles provide correction for both the header and the carried data, with interleaving that helps distribute errors across the correction structure.

That is useful for a typical RTK arrangement: one base broadcasts corrections to multiple rovers. Each receiver can repair recoverable errors locally, without requesting another copy of the packet. Fewer lost updates can help preserve the flow of timely corrections as reception conditions change.

The tradeoff is airtime. Redundancy consumes channel capacity, and errors beyond the code’s capability still cause packets to be lost. FEC is a tool for balancing correction delivery against throughput, rather than a guarantee of a particular operating range.

SC135 also removes FEC as a setting that has to match across the link. Each transmission indicates whether it carries FEC, and the receiver decodes it either way. On the EASy+, we confirmed this in all four SC135 profiles: a radio set to an FEC profile receives transmissions sent without FEC, and the reverse. The FEC choice therefore governs only what a radio transmits. This differs from the general guidance for the EASy+ compatibility modes, which calls for identical FEC settings on every radio in a system.

Scrambling as part of the common format

SC135 includes mandatory data scrambling, also called whitening. It transforms repetitive input into a signal pattern better suited to radio reception, then reverses that transformation at the receiver. This reduces the radio’s dependence on the particular byte patterns in the application data.

Whitening is already familiar in SATEL and Pacific Crest modes, where it is typically an on/off setting that must match at both ends. A mismatch is easy to miss. In the native SATELLINE-3AS format we studied, the transmission does not signal whether whitening is on, and the optional payload check is calculated over the whitened data as sent. That check therefore cannot detect a receiver using the wrong setting: the packet can pass and still deliver unusable bytes. SC135 makes scrambling a fixed part of the transport, so there is no setting to get wrong.

Packet identity and room to grow

SC135 packets carry an explicit data length and a sequence number. Sequence information lets a receiver discard duplicates and packets that arrive late. This is especially relevant when repeaters can deliver additional copies of the same transmission.

For RTK, repeated delivery of an old packet does not provide a new observation. Keeping packet identity at the radio layer helps avoid forwarding redundant copies to the GNSS receiver. Sequence tracking does not replace the timing information inside the correction messages.

The standard also provides optional header extensions, allowing additional network information to accompany the data. That gives implementations room to develop while retaining a defined way to locate and deliver the application payload.

How the EASy+ radio protocols compare

The EASy+ protocol menu combines several generations of SATEL formats with compatibility modes for other equipment. The table groups the families we have studied; it does not enumerate every management profile or firmware option. SATEL documents the available compatibility modes in its EASy+ user manual. The structural comparisons reflect our bench work with the radio’s transmitted formats.

These observations describe EASy+ compatibility modes, rather than every product sold under each protocol name. In particular, “no checksum observed” is limited to the configuration and format studied.

The comparison shows why SC135 deserves attention without dismissing established protocols. Error detection, scrambling, FEC, and sequence numbers already appear elsewhere. SC135 brings these ideas together with defined requirements and a shared specification that manufacturers can implement against.

Matching the waveform is only the beginning

SC135 uses four-level frequency-shift keying, or 4FSK. Native SATELLINE-3AS and some Pacific Crest modes also use 4FSK, but their packets and coding rules differ. A shared modulation describes how information becomes a radio signal; it does not establish that two radios can understand one another’s transmissions.

The same distinction helps explain the appeal of 8FSK and 16FSK. More frequency levels can carry more information per symbol, but useful throughput also depends on coding and packet overhead. Receiver requirements and link conditions matter too. SC135’s case for RTK rests on interoperability and a defined reliability baseline, rather than a claim to be the fastest choice in the menu.

On the EASy+, SC135 is offered through four profiles:

Radios on the same link need the same channel width. Because reception detects FEC automatically, they can use different FEC choices within that width, for example a base transmitting with profile 1 and a rover set to profile 3.

What the advantages mean for RTK users

The immediate opportunity is a simpler basis for compatibility. A shared specification gives manufacturers a common target and gives users a clearer question to ask: do these radios support SC135 at the same channel width? Frequency, channel settings, and the correction messages understood by the GNSS receivers still need to agree.

For a new installation, that can support more freedom to select base and rover equipment from different suppliers, once interoperability has been verified. For an existing installation, the protocol already supported by the fleet remains an important consideration: SC135 cannot make a legacy radio understand a format it does not implement.

The reliability features address another practical concern: keeping valid corrections arriving on time. Mandatory integrity checks help reject damaged traffic, FEC can recover some packets that would otherwise be lost, and sequence tracking supports duplicate suppression. Positioning accuracy continues to depend on the GNSS observations, environment, and receiver processing; the radio’s contribution is dependable delivery.