RTK Goes Networked: What Breaks When Every Rover Wants Its Own Base
On this page
TL;DR
Every Rover wants a short baseline to a nearby Base. Single-base RTK creates it in the field; CORS removes the repeated setup but not the physical distance. Network RTK models how GNSS errors vary across several known stations and delivers the result through VRS, FKP, MAC, or shared grid streams. As users grow from survey crews into moving fleets, the weak points shift to station cost, per-user generation, reference handovers, and trust in the stations feeding the service.
In The RTK Trick, we followed carrier phase through the Rover until it became a Fixed solution. This time, we turn around and follow that baseline to its other end: the Base.
Giving every Rover a nearby Base breaks five things in sequence: field setup, station cost, per-user generation, continuity in motion, and trust in the stations themselves. Each solution moves more work from an individual survey setup into the correction service.
Surveying drove the first two: field setup and station cost. Connected fleets drove per-user generation and continuity; crowdsourced supply made station trust the fifth.
Single-Base RTK: When Distance Becomes the Limit
The early commercial RTK workflow was direct. A survey crew placed a Base over a known point, sent its observations over radio, and let a nearby Rover solve one baseline. Trimble records its first commercial RTK product in 1993, placing this familiar workflow in the early 1990s.
Single-base RTK is still useful because the operator controls the reference coordinate, equipment, radio link, and work area. It can run without cellular coverage, and a fault has a short path to investigate. The same simplicity also concentrates the risk: a wrong Base coordinate shifts every Rover result, and one Base failure stops the job.
Distance is the harder limit. The farther the Rover moves from the Base, the less alike their atmospheric paths become. Receiver specifications often expose that relationship through a parts-per-million term. As explained in The RTK Trick, a common 1 cm + 1 ppm specification adds roughly 1 mm for every kilometre of baseline under the stated test conditions.
The ppm term describes accuracy once RTK is working; it misses another operational penalty. As a baseline lengthens, ambiguity resolution can take longer and RTK availability can fall, especially when the ionosphere is active.
NTRIP can replace the radio, and RTCM can standardize the stream. Neither changes the physical separation. Shortening that distance requires more Bases; the first step was to make those Bases permanent.
CORS and Nearest-Base RTK: Permanent, Online, Still One Baseline
A Continuously Operating Reference Station (CORS) turns a temporary setup into maintained infrastructure. Its location, equipment metadata, coordinates, and reference frame can be monitored over time, so users no longer have to establish a new Base for every project.
The idea grew out of scientific tracking and geodetic-control work in the 1980s and early 1990s. In the United States, NOAA's National Geodetic Survey began the national CORS network in 1994. Permanent public and commercial reference services later became common across mature surveying markets.
Once those stations were online, a Caster could use a Rover's approximate position to select a nearby physical station and forward its observations. That removes field setup and radio line-of-sight, but the Rover still solves one physical baseline. A distant station is easier to reach over the internet; it is still distant.
Adding stations shortens that baseline, but density becomes expensive quickly. In a roughly uniform service area, halving the target spacing requires about four times as many sites. Each site needs a monument, surveyed coordinates, power, backhaul, and maintenance.
A collection of CORS can therefore remain a collection of single Bases. The correction model changes only when the service compares several stations and estimates what happens between them. Building more stations is one answer. Modeling the space between them is the other.
How Network RTK Models the Space Between Stations
Network RTK uses simultaneous observations from several reference stations with known coordinates to estimate how satellite-orbit and atmospheric errors vary across a region. The network solves and monitors the difficult inter-station relationships; the Rover receives a local representation of that regional model and still computes its own final position.
Reference stations make this possible because their coordinates are known, their antennas do not move, and they observe continuously. The network processor can maintain consistent ambiguity relationships between stations and track the residual ionospheric, tropospheric, and orbit behavior across the service area. A moving Rover that needs a result within seconds does not have the same time or geometry.
Network Processing vs. Rover Positioning
Network processing software checks reference-station data and estimates how correction errors vary across the region. The Rover positioning engine combines the delivered information with its own live measurements, resolves its local ambiguities, and outputs position. These are different processing layers, even when both are casually called an “RTK algorithm.”
The regional model is not a simple average. Inside a well-shaped station network, it can interpolate between observed conditions. Near an edge, or beyond the network, it begins to extrapolate. Terrain, weather, ionospheric activity, station geometry, and a bad input stream can all affect the result.
Physical station spacing is therefore a trade-off. Denser geometry captures more local variation and adds redundancy. Wider spacing costs less but asks more of the model, especially where the ionosphere changes quickly. Processing can make better use of sparse infrastructure; it cannot reconstruct variation that no station observed.
Once the regional model exists, the next decision is how much of it the service should process before sending anything to the Rover.
VRS, FKP, and MAC: Who Does the Work?
VRS, FKP, and MAC are three ways to hand regional Network RTK information to a Rover. They use the same multi-station foundation but divide the remaining work differently between the service and the positioning engine.
Virtual Reference Station (VRS) keeps more work on the service side. The Rover reports an approximate position, usually through NMEA GGA. The network then synthesizes a self-consistent set of Base observations near that position and returns a familiar correction stream. A Rover that already handles single-base RTCM can often use VRS without learning the geometry of the whole network.
That compatibility made VRS a practical path from single-base receivers to regional services. The first cost is visibility: the Rover sees a plausible Base stream, not the health of the station network and model behind it.
The second is generation. A nearest-base service may also track each Rover's GGA and connection, but it only forwards an existing stream. Conventional VRS synthesizes a new one for each Rover.
FKP, often translated as area correction parameters, sends regional correction gradients around a real reference station and lets the Rover interpolate them for its own location. MAC, the Master-Auxiliary Concept, sends full observations from a master station plus differences from auxiliary stations after the network aligns their ambiguity levels. Both can share network information among multiple users, but they require compatible messages and more capable Rover-side processing.
| Method | What the service sends | What the Rover does | Main trade-off |
|---|---|---|---|
| VRS | Synthetic observations from a virtual Base near the Rover | Processes a familiar single-baseline-style stream | Broad compatibility; personalized generation and less network visibility |
| FKP | Regional correction gradients around a physical station | Interpolates the gradients for its own position | Shared delivery; requires compatible Rover processing |
| MAC | Master observations plus leveled auxiliary differences | Uses master and auxiliary data to form a local correction | Preserves more network information; increases Rover-side complexity |
Accuracy depends on the station network, regional model, implementation, message support, and Rover behavior; the acronym alone does not rank them. In practice, use the method the service supplies and the Rover firmware has been tested to process. VRS remains the common compatibility path for receivers built around a single-base stream.
VRS takes the premise literally: every Rover gets its own nearby Base. That answer works well for survey-sized demand. A large fleet exposes the next limit because the service must keep generating personalized streams.
Gridded VRS: Compute by Area, Not by Rover
A shared-grid implementation prepares virtual observations or correction streams at fixed points across the coverage area, updates them continuously, and assigns each Rover to a nearby point. Vendors use different names for this architecture, including Gridded VRS and Grid VRS. The scaling principle is the same: compute a reusable regional output for each cell instead of synthesizing a new one for every user.
One grid stream can serve every Rover assigned to that cell. The regional generation workload therefore follows the number of maintained cells, while authentication, connections, bandwidth, and delivery still follow the number of users. This is how a service can preserve a Base-like stream without repeating the same regional calculation for every machine.
Cloud infrastructure makes it practical to keep many shared streams current and distribute them to large fleets. It does not add atmospheric detail to the physical station network.
Grid spacing and physical station spacing solve different problems. The output grid controls virtual-baseline length and how often a moving user changes cells; the physical network controls what the regional model can observe.
Coarser cells mean fewer handovers and a longer virtual baseline. Finer cells keep the virtual Base closer, but they create more streams and more boundary crossings. Shared computation fixes the per-user generation problem. Motion exposes the reference-continuity problem.
Moving Rovers: Why RTK Drops from Fixed to Float
A survey point may remain near one reference for an entire occupation. A vehicle, mower, drone, or field robot keeps moving. The service must keep the reference useful while the Rover carries ambiguity states from one moment to the next.
A nearest-base service may switch to another physical station. A VRS service may rebuild the virtual Base closer to the Rover. A grid service may assign the next cell. A failed source station can also force the backend to reorganize its model. Each event changes a different part of the reference path, but any of them can coincide with a drop from Fixed to Float or a coordinate discontinuity.
| Scenario | What changes | What to check |
|---|---|---|
| Nearest-base handover | Physical Base, baseline, coordinates, and possibly hardware | Station ID and Base ARP coordinates change as the solution drops |
| VRS rebuild | Virtual Base location and synthesized observations | Base ARP relocation, Station ID behavior, and time to return to Fixed |
| Grid crossing | Assigned virtual grid point | ARP moves by one grid step and the event repeats near cell boundaries |
| Backend reconfiguration | Source stations, subnetwork, or regional model | Rover fields may stay unchanged; correlate the event with provider status or logs |
Log the solution state, Station ID, and Base antenna-reference-point coordinates together. RTCM MT1005/1006 commonly carry the station identity and ARP coordinates needed for this check; an antenna descriptor can add context when a nearest-base service switches physical hardware. RTCM Unpacked maps those messages to the Rover data path.
A moving service cannot avoid every reference change. Its quality shows in whether adjacent references share the same frame, whether the transition is visible in the data, and how quickly the Rover returns to Fixed. More station overlap shortens the baselines on both sides of a handover and provides a spare when one source fails, but conventional ownership makes that density expensive.
Crowdsourced RTK Networks: Cheaper Density, Harder Trust
Crowdsourced networks, including DePIN (decentralized physical infrastructure network) models, change who supplies the reference stations, not the mathematics used to position a Rover. Tokens, contribution scores, or revenue sharing can encourage participants to add coverage without one operator purchasing and maintaining every site.
Those station streams can support several delivery paths. A service may select and forward the nearest physical Base, feed many community streams into a VRS or other regional processor, or sell raw station access to another correction provider. “Crowdsourced” describes the supply and incentive model. “Network RTK” describes how multiple observations are modeled and delivered.
Independently installed stations vary more in siting, hardware, coordinates, and maintenance. In nearest-base delivery, one poor station reaches the Rover directly, so the operator must qualify each station before delivery and switch away from degraded sources.
A multi-station processor can cross-check and down-weight an outlier, but an undetected fault can contaminate a correction shared by many users. Because ownership and operation are separated, uptime and contribution scores are not enough; putting a station into production requires continuous data-quality checks, coordinate validation, anomaly detection, and a way to quarantine it quickly.
Coordinates need separate governance. Automated PPP can estimate a station in a global frame, while a customer may need a regional frame at a defined epoch. Neighboring stations can agree with one another and still share the same frame error. Beyond WGS84 explains why a stable correction can still be referenced to the wrong place.
Crowdsourcing makes density cheaper. The hard engineering moves to trust: deciding which independently owned stations may enter the regional model or reach a Rover directly, and removing them quickly when their data degrades.
Conclusion: In Network RTK, the Network Is the Product
When every Rover wants a nearby Base, field setup breaks first, and CORS fixes it. Shortening distance then makes station cost the limit, so Network RTK models the region. Personalized VRS preserves compatibility but scales generation with active users. Shared grids reuse that work, moving Rovers expose handovers, and independently owned stations make trust the hard part.
Before choosing or integrating a correction service, ask four concrete questions:
- What reaches the Rover? A physical Base, a personalized VRS, network parameters, or a shared grid stream?
- What happens while it moves? How are nearest-base changes, VRS rebuilds, and cell crossings handled?
- What defines the reference? Which coordinate frame and epoch are used, and how are Base coordinates monitored?
- What happens to a bad station? Can the service detect, down-weight, isolate, and replace it before users see the fault?
Two products sold as an “RTK network” can follow very different paths. Station count alone does not reveal whether the service routes one Base, estimates a regional model, generates a VRS, or maintains shared grid streams.
Key Takeaway
A Network RTK provider maintains a reference frame, models a changing atmosphere, runs a real-time distributed system, and decides which station data to trust. The network architecture—not the label on the service—determines how well RTK scales and how gracefully it fails.
Frequently Asked Questions
What is Network RTK?
Network RTK is a correction service that uses simultaneous observations from several reference stations with known coordinates to model how GNSS errors vary across a region. It can deliver that information as a Virtual Reference Station (VRS), area correction parameters (FKP), Master-Auxiliary Concept (MAC) data, or shared grid streams. The Rover still combines the correction with its own measurements and calculates its final position.
Is CORS the same as Network RTK?
No. CORS describes continuously operating reference infrastructure. Several CORS may publish individual Base streams without being modeled together. Network RTK begins when observations from multiple stations are compared to estimate regional error behavior and deliver a local correction to the Rover.
What is a Virtual Reference Station (VRS) in RTK?
A VRS is a synthetic set of Base observations generated near a Rover's position, usually reported through NMEA GGA. Conventional VRS creates a personalized stream for that Rover. A shared virtual grid instead prepares streams at fixed regional points and lets every Rover in a cell reuse the same output, so the main generation workload follows grid cells rather than active users.
Should a Rover use VRS, FKP, or MAC?
Use the method offered by the correction service and validated with the Rover firmware. VRS is the common compatibility choice because it resembles a single-base RTCM stream, provided the Rover sends NMEA GGA. FKP and MAC expose more regional information to the Rover but require the corresponding messages and positioning logic. None is inherently the most accurate.
Why does a moving Rover drop from Fixed to Float after a reference change?
A nearest-base service may switch physical stations, a VRS may be rebuilt, or a grid service may assign another cell. Each event can change the Base coordinates or observations used by the Rover and reset its ambiguity state. Log the solution state together with the Station ID and Base ARP coordinates from RTCM MT1005/1006 to confirm whether the drop matches a reference change.
Is a crowdsourced RTK network the same as Network RTK?
No. Crowdsourcing describes how reference stations are supplied, owned, and rewarded. Network RTK describes how observations from several stations are modeled for the Rover. A crowdsourced service may provide nearest-base single-baseline RTK, contribute streams to a regional Network RTK processor, or do both through different products.
Continue exploring
RTCM Unpacked
Map the observation, station, antenna, and message details the Rover actually receives.
LateralBeyond WGS84
See why reference frames, epochs, geoids, and transformations can move a perfectly Fixed position.
ApplyRTK GPS for Robotics
Turn correction continuity and position confidence into navigation behavior for outdoor robots.
