Network RTK Quality and Correction Latency
A network RTK correction, generated from a modeled virtual reference station rather than a single physical base, carries its own specific quality considerations on top of everything covered so far, and one of the most important is a factor that never comes up with a single nearby base at all: latency.
A note on terminology: this chapter uses "correction" the way the GNSS industry commonly does, as shorthand for the reference data stream a rover receives, whether that stream carries raw observations, network-synthesized observations, or (for other services outside this companion's scope) genuine computed correction values. This companion has been careful elsewhere to distinguish observations from corrections precisely; here, "correction latency" is used because it is the term the industry actually uses for this concept, not as a claim about what specific kind of data is flowing.
Correction latency is the delay between when a correction is generated and when it actually reaches and is applied by the rover. Even a high-quality network correction becomes less representative of current conditions the more delayed it is by the time it arrives.
Why a Delayed Correction Is a Slightly Stale One
Atmospheric conditions, satellite geometry, and orbital details all shift continuously, if usually gradually. A correction generated one second ago describes conditions as they were one second ago, not necessarily as they are right now. Under calm, stable conditions, that gap barely matters. Under rapidly shifting atmospheric conditions, exactly the kind discussed two chapters ago, a delayed correction can meaningfully lag behind what the rover actually needs at that instant.
Reference Station Density and Network Modeling
A network's ability to model atmospheric conditions accurately across its coverage area depends on how many real reference stations feed it and how well distributed those stations are. A rover working near the center of a dense cluster of reference stations benefits from a well-constrained model. A rover working near the edge of a network's coverage, or in a sparsely covered region, receives a correction built from a thinner, less certain model, even if the correction itself arrives with no delay at all.
A strong cellular signal and a stable NTRIP connection guarantee fast, uninterrupted data transfer, but they do not guarantee that the correction being transferred was generated from a dense, well-distributed reference network. Connection quality and correction quality are related but separate questions.
Practical Signs Worth Watching For
Longer than usual convergence times, occasional unexplained drops from FIX to FLOAT, or a rover that seems to perform noticeably worse near the edge of a service provider's coverage map are all consistent with either latency or thin reference density, sometimes both at once. None of these symptoms announce their cause directly, but recognizing the pattern narrows the investigation considerably.
A rover performs beautifully most days but noticeably worse during one particular afternoon session, despite good satellite visibility and no obvious equipment issue. What is worth checking? Recent geomagnetic activity, the rover's position relative to the correction network's reference stations, and whether the connection experienced any noticeable latency or interruption during that session.
Network RTK quality depends on correction latency and reference station density, in addition to everything a single physical base station must also get right. A stable, fast connection guarantees timely delivery, not necessarily a well-modeled, low-latency correction underneath it.
This companion has now covered a long list of things that can quietly undermine a coordinate's trustworthiness. The next chapter turns to the other side of the question: how a professional actually builds confidence back up.