Choosing Your RTCM Broadcast Profile
With a coordinate established and a firm grasp of what an RTCM stream actually contains, a genuine decision now belongs to the person running this base, one most rover users never get to make at all: exactly what to broadcast.
Selecting an RTCM profile means deciding which message set version, which constellations and frequencies, and which update rate to actually broadcast, a decision that directly shapes what every rover connecting to this base can and cannot achieve.
Matching the Profile to the Rovers That Will Actually Connect
A broadcast profile is only as useful as the receivers meant to consume it. Including every available constellation and the newest message set version sounds like an obvious default, until an older or simpler rover in the fleet turns out not to support some of it, and quietly falls back to a degraded solution without ever reporting an outright error.
A base broadcasting more than the intended rovers can actually use is not a wasted effort so much as a mismatch waiting to surface as an unexplained accuracy problem on whichever receiver cannot use the full stream.
Rate, Bandwidth, and Latency, Chosen Deliberately
A higher message rate reduces latency between an observation and its arrival at the rover, at the cost of more bandwidth consumed by the transport method chosen in the next chapter. A radio link with modest bandwidth, or a cellular connection billed by data usage, both make a strong case for a leaner rate and message set than an unconstrained wired connection would ever need to consider.
Broadcasting the maximum possible rate and the widest possible message set is not automatically the best configuration. It is the best configuration only when the transport method and the connecting rovers can actually make full use of it without cost or compatibility trade-offs elsewhere.
A Decision Worth Documenting
Whatever profile gets chosen deserves the same documentation discipline this series has emphasized from its earliest companions: which message set, which constellations, which rate, recorded somewhere a future user, possibly not the person who set it up, can actually find. An undocumented profile decision is not a mistake on the day it is made. It becomes one the day somebody else needs to understand it.
A base is configured to broadcast every available constellation and the newest message set version by default, without checking what the fleet's rovers actually support. Is that automatically the safest choice? Not necessarily. An older receiver in that fleet may quietly underperform on a stream richer than it can fully use, with nothing in its own reporting indicating why.
Choosing an RTCM broadcast profile means matching the message set, constellations, and rate to the rovers that will actually connect and the transport method carrying the stream, not simply maximizing every setting available. Documenting that choice is what makes it usable by anyone beyond the person who originally made it.
A chosen profile still has to physically reach a rover. The next chapter covers exactly how, and what keeps that path running.