RTK gets you centimeter-level positions by resolving carrier-phase integer ambiguities against corrections from a reference station. Where those corrections come from shapes almost everything else: accuracy, how reliably the rover fixes, and how far from the base you can work. Two setups dominate the field. One is a single dedicated base. The other is network RTK, usually delivered as a Virtual Reference Station (VRS) solution. Here is how they compare from an engineering point of view.
Single-Base RTK: The Mechanics
One reference receiver sits on a known point and streams its observations to the rover (RTCM 3.x MSM messages or a proprietary format) over UHF radio, NTRIP, or a cellular modem. The rover builds double-differenced carrier-phase observations against that base and solves for the baseline vector.
Double differencing cancels receiver and satellite clock errors outright. Orbit error, ionospheric delay, and tropospheric delay are another story. They are spatially correlated, so they cancel on short baselines and creep back as the baseline grows. A typical error budget is 5-10 mm + 0.5-1 ppm horizontally, which puts a 30 km baseline at roughly 15-30 mm of distance-dependent error before multipath and noise enter the picture. Ambiguity resolution gets shaky somewhere past 15-20 km, especially when the ionosphere is stirred up, a real headache around solar maximum.
VRS: The Mechanics
VRS runs on a CORS network, commonly with 30-70 km between stations. A central server continuously resolves network-wide ambiguities and models the spatially correlated errors: the dispersive ionospheric term, plus the non-dispersive geometric and tropospheric contributions.
The rover opens the session by sending its approximate position to the caster as a GGA sentence. The server synthesizes a reference station at or near that spot, computes its observations from the nearest physical station(s), and applies the network-derived corrections for ionosphere, troposphere, and orbits. What comes back is plain RTCM, so the rover treats it as a real base sitting a few meters away. Error behavior ends up resembling a zero-length baseline, since most distance-dependent terms are removed server-side. And because only standard RTCM is required, nearly any RTK-capable receiver can use it.
Other Network RTK Flavors
VRS isn’t the only game in town. FKP (Flächenkorrekturparameter) broadcasts area correction gradients and leaves the interpolation to the rover. MAC (Master-Auxiliary Concept, RTCM 3.x messages 1014-1017) ships master-station data along with differences from the auxiliary stations. Both are one-way streams and go easier on the server, whereas VRS needs a two-way link. VRS still leads on field adoption, mostly thanks to receiver compatibility.
Side-by-Side Comparison
| Parameter | Single-Base RTK | VRS |
|---|---|---|
| Effective baseline | Actual distance to base | Near zero (virtual) |
| Distance-dependent error | 0.5-1 ppm, grows with range | Largely modeled out |
| Practical range | ~10-20 km for reliable fixes | Anywhere inside network coverage |
| Initialization | Quick on short baselines, slower at range | Typically fast and consistent within the network |
| Communication | Radio or NTRIP, one-way possible | NTRIP, two-way (GGA required) |
| Infrastructure | One receiver and a known point | Dense CORS network plus server software |
| Coordinate frame | Tied to your base coordinates | Tied to the network datum (e.g., ITRF/NAD83 realization) |
| Cost | Hardware and setup labor | Usually a subscription |
| Failure mode | Base outage stops every rover | Server or network outage; degrades to the nearest station |
Single-Base RTK: Pros and Cons
- Pro: No dependence on cell coverage. UHF works where there is no network at all, which matters in mining, forestry, and remote construction.
- Pro: Minimal latency. Corrections go straight from base to rover, usually in under a second end to end. Machine control and UAV work benefit most.
- Pro: You own the whole chain. Base location, mask angle, logging rate, message set: all your call, and nobody else can pull the plug on your service.
- Pro: Cheapest to run over time on a fixed project footprint. Once the gear is paid for, there are no recurring fees.
- Con: Accuracy slides with distance. Ionospheric and tropospheric residuals eat into fix rate and precision as the baseline stretches.
- Con: One base, one point of failure. A power drop, a tracking glitch, or a typo in the base coordinates hits every rover on the job.
- Con: Datum risk and setup overhead. The base has to sit on a point with correct coordinates in the project datum. Get that wrong and the entire survey carries a systematic offset. Localization to local control is often needed anyway.
- Con: Field logistics. Radio licensing, antenna height measurement, and keeping the base from walking off all take time.
VRS: Pros and Cons
- Pro: Even accuracy across the coverage area. With a healthy network, horizontal precision typically holds at 8-15 mm + 0.5 ppm no matter which physical station is closest.
- Pro: Power on and go. No base to occupy, so no occupation time and no coordinate-entry mistakes.
- Pro: Georeferenced to the network datum. Results repeat between days and between crews without re-establishing control.
- Pro: Built-in redundancy. Network software flags and drops faulty stations, so a single failure rarely stops service.
- Con: You need mobile data. Dead zones, congested towers, or a dropped NTRIP session cut corrections off, and 1-3 seconds of latency can hurt in high-dynamic applications.
- Con: The provider controls quality. Station density, processing, and uptime are out of your hands, and spacing much beyond 70 km degrades interpolation.
- Con: Recurring fees. Subscriptions are per rover, and across a big fleet that adds up fast.
- Con: Weak at the edges. Outside the station polygon the system extrapolates rather than interpolates, and fix reliability and accuracy visibly drop.
Choosing Between Them
A single base makes sense when the work area is compact (within roughly 10-15 km of the base), cellular coverage is unreliable, latency matters, or you run many rovers on one project and per-seat subscriptions would sting. Think construction staking, precision agriculture on large farms, UAV photogrammetry with ground control, and open-pit mining.
VRS fits better when work spans big or shifting areas, crews hop between sites, repeatability to a national or regional datum is required, or setup time is the bottleneck. Cadastral surveys, utility mapping, corridor work, and GIS data collection are the usual beneficiaries.
Plenty of crews mix the two. A common pattern is to use VRS to establish control points or to calibrate the local base position, then switch to a local base for high-rate work or areas with no coverage. Whichever you pick, shoot a known control point as a check. Multipath, poor satellite geometry, and obstructed sky hurt both methods equally.
