TL;DR: Both single-baseline and Network RTK achieve the same centimeter-level accuracy when supported by a dense network. Atmospheric errors are governed by physics, and no model can recover information more accurately than sampling the data directly. Evaluate corrections based on excursion rates at the 99th percentile, not median accuracy. And ask your provider about inter-station spacing before you ask about correction type.
Single baseline. Network RTK. SSR. VRS. These are all different ways to make GNSS far more accurate. But the terminology gets used loosely and marketing creates confusion about which is “best.”
In a recent livestream, Tom Weeks and I spent 30 minutes breaking down different correction types, what determines the accuracy you get, and how to decide which type you want to use.
Three Ways to Correct GPS
To get centimeter-level accuracy, you need a correction signal of some kind. The three primary approaches differ in how they generate that correction.
Single-Baseline RTK
This is the gold standard — and it’s where the technology started. You have a physical base station at a known location with a GPS receiver on it. Because you know exactly where that station is, you can compare what the receiver observes from the satellites against what it should observe, and that difference becomes a correction that a nearby rover can use to solve its position within centimeters.
The key concept here is observables — GPS-speak for the raw measurements your receiver makes. Essentially the distance to each satellite, measured two ways for each signal. It’s literally what the receiver is hearing from the satellites.
Single-baseline RTK works by looking at the difference between the observations on the base station and the observations on your rover. It’s direct, it’s transparent, and it’s fully traceable — meaning if something goes wrong, you can go back in time and look at exactly what data went in and what position came out. This is what the industry calls an OSR (Observation Space Representation) approach: you’re working with actual measurements from a real station.
The limitation is distance. The corrections from that station are only representative of atmospheric conditions near it. As your rover moves farther away, the atmosphere above it diverges from the atmosphere above the base, and accuracy degrades.
Network RTK
Network RTK is a more advanced concept, but it uses the same underlying principles. Instead of a single base, you have multiple base stations in a network, connected to a central server. When your rover connects, that server takes the observables from multiple surrounding stations and uses their known geometry to interpolate — estimating what a base station at your rover’s location would observe if one existed there. It then sends that synthetic observation data to your rover as if it came from a real nearby station.
This is geometric interpolation. The server is making an educated estimate about conditions at your location based on what it can see at surrounding stations. It’s a genuinely useful technique, but the quality of that estimate depends on how much real data the server has to work with. Six stations within 40 km? The estimate is well-informed. Three stations 100 km away? The math still runs, but it’s working with an incomplete picture of what the atmosphere is actually doing.
Network RTK is still an OSR approach — the interpolation happens at the observation level, working with actual measurements from real stations. The distinction matters because it means Network RTK’s accuracy is bounded by the spatial sampling of those real stations, not by the sophistication of the interpolation algorithm.
SSR: Breaking the Problem Into Five Buckets
SSR (State Space Representation) takes a fundamentally different path. Instead of interpolating raw observables geometrically, SSR decomposes the GPS error problem into its individual physics components and models each one separately.
Think of it as five buckets: satellite orbits (where they actually are versus where they’re broadcast to be), satellite clocks (timing drift on each one), ionospheric delays (how the upper atmosphere slows signals based on electron density), tropospheric delays (how weather, water vapor, and pressure affect signals), and signal biases (systematic offsets for each constellation and frequency).
You need to get all of those right for an SSR system to work, because every single component contributes to the model that generates corrections. The errors in each bucket compound.
So why would you choose SSR over Network RTK? The main benefit is that SSR’s physics models let you interpolate further — theoretically covering much larger areas with fewer stations. That is true most of the time, when the physics is well-represented by the equations in those models. SSR was designed for wide-area, continent-scale coverage, and it delivers that — at decimeter accuracy (~10 cm) rather than the centimeter accuracy that RTK provides.
That’s not a failure of the approach. It’s what SSR was purpose-built for.
The contrast with Network RTK is instructive. Network RTK uses a simpler geometric overlay — it’s much more predictable, and honestly, while much less complex from a physics perspective, it tends to work better on consumer-grade GPS receivers. If you have the station density, Network RTK is always going to give you faster fix times and better accuracy than SSR. But nothing beats having more data — and that’s what Network RTK is really powerful at using.
What VRS Actually Means
VRS (Virtual Reference Station) is one of the most misunderstood terms in GNSS. Many people directly equate VRS with Network RTK. That used to be accurate — a decade ago, before SSR was a production technology, VRS basically meant Network RTK. Today, VRS is a delivery format, not a correction type.
All it means is: I’m going to give your rover something that looks like a single nearby base station. The problem is, as a rover, you don’t actually know — is that a real single base, or is it one of these generated things? You can generate a VRS from Network RTK (interpolating observables geometrically) or from SSR (running physics models server-side and converting the output to standard RTCM messages).
To a rover, both look identical. But the accuracy characteristics are different because the underlying methods are different. So when a vendor says “we deliver VRS corrections,” that tells you the format. It doesn’t tell you the method, and it doesn’t tell you the accuracy. Ask what’s behind it.
Why Density Matters — You Can't Fight Physics
This is the topic with the most FUD in the market, and it’s the one I want to spend the most time on because it applies to every correction type equally.
The Atmosphere Is Not Uniform
GPS signals travel through two atmospheric layers — the ionosphere and the troposphere — before reaching your receiver. Both introduce delays that vary across space and time.
There are parts of the ionosphere that are relatively predictable. The GNSS community has models for them — things like the Klobuchar model that every receiver uses. These handle the broad, large-scale patterns: ionospheric activity moving across an area the size of a state, changing gradually. Think of these as the low-frequency components. They account for maybe 80% of the ionospheric effect.
But 80% still leaves significant residual error. And the remaining variation includes high-frequency components — localized disturbances that fluctuate over short distances and change fast. When you think about why the size of these disturbances matters, it comes down to a core assumption in RTK: if the base station and the rover are close enough, they experience the same atmospheric effects. It’s common mode — it cancels out. But if that assumption is wrong because there’s a localized disturbance between them, the receiver doesn’t know that. You have leftover error in the calculation, and that directly translates into position error.
The troposphere has its own version of this — wet and dry components driven by water vapor, temperature, and local weather. It has predictability within it, but it also has high-frequency variation that behaves the same way. A passing weather front can change conditions over a few kilometers.
The Weather Station Analogy
Predicting atmospheric conditions for GPS is like predicting the weather. If you have weather stations every 200 km, you know the general pattern — warm front coming through, low pressure to the west. But you can’t tell whether it’s raining in one neighborhood versus another. If you have stations every 30 km, you can. You’re sampling the variation at fine enough resolution to capture what’s actually happening locally.
GNSS corrections work the same way. Sparse networks capture the broad patterns but miss localized disturbances. Dense networks capture both. And it’s the localized disturbances — the high-frequency components — that determine your accuracy in the moments that matter most.
This is physics. Not an engineering limitation, not a software problem. It constrains every correction method equally — single-baseline, Network RTK, and SSR. None of them can know what they haven’t measured.
What This Means for Network RTK Specifically
For single-baseline RTK, the density relationship is intuitive. Closer stations mean shorter baselines, which means the atmospheric conditions at the base more closely match conditions at your rover.
For Network RTK, the relationship is less obvious — and this is where most market confusion lives. The argument you’ll hear is that Network RTK models the atmosphere across multiple stations, so you don’t need the same density. The model compensates for wider spacing.
This sounds reasonable. But the model is interpolating — estimating conditions between stations based on what it observes at those stations. If those stations are far apart, the model is estimating across areas where it has no direct observations. During quiet conditions, the atmosphere may be smooth enough that this works. But during storms, scintillation, or rapidly changing ionospheric activity — the model is extrapolating through exactly the kind of high-frequency variation it can’t capture without nearby measurements.
Some providers claim their atmospheric models can extend accurate corrections 70 km to 100 km from the nearest station. That might be true most of the time. But then all of a sudden you have some high-frequency component that shows up — and your system has impacted performance for that period of time.
The solution isn’t a better algorithm. It’s more data. Dense networks (30–40 km station spacing) keep both architectures in the high-reliability regime. Sparse networks hope the details don’t matter. Sometimes they don’t. Sometimes they do.
Excursions: Where Real-World Systems Break
Here’s where I want to pull the discussion out of theory and into what people actually care about.
If you’re running an autonomous tractor, or a robotic mower, or a line painting machine — it needs to work all the time. But when you think about what “all the time” actually means, that’s a statistical statement.
The statistical way of looking at this is that you have a distribution. Maybe 95% of your points are within two or three centimeters. But these excursions — the things on the tail of the distribution — are where real-world systems will either work or cause catastrophic error.
When you’re evaluating any RTK system, you shouldn’t just look at the 95th percentile performance. You need to look at the tail of the distribution — the 99th percentile, the worst case — so you can have confidence that your application is actually going to work.
What does this look like in practice? When a system excurses 5–9 cm, that’s where damage happens. A line painter paints a visibly crooked line. An autonomous mower drifts into the flowerbed — and on a $70,000 machine, that’s a warranty claim. A grading system cuts too deep on one side of the pad. A tractor drives over the crop row instead of between them. An autonomous vehicle thinks it’s centered in the lane when it’s actually drifting toward the shoulder.
These aren’t hypothetical. They’re the real-world consequences of corrections that work most of the time but not all of the time.
Dense networks minimize excursion rates for both single-baseline and Network RTK. Short baselines and adequate atmospheric sampling keep the entire distribution tight — not just the median. Sparse networks may produce similar average accuracy, but the tails are longer, less predictable, and harder to detect.
It all boils down to one concept: if your model works most of the time, your accuracy will be there most of the time. The question is what happens the rest of the time — and whether your application can survive it.
A Framework for Choosing
Both single-baseline RTK and Network RTK have pros and cons. With adequate network density underneath, both deliver 1–3 cm accuracy. The choice is about what operational characteristics matter for your application — not which method is “better.”
Single-Baseline RTK
Simplicity and traceability. The correction chain is fully deterministic. You know which station provided data, you have the raw observables, and you can replay the exact scenario to reproduce the exact result. If you design any autonomous system, at some point you’re going to have an anomaly — and you’ll want to go back in time and say, what happened? Being able to trace the direct data from a single base station is just less complicated to debug, candidly.
Visible performance feedback. When baselines get long, the system tells you — longer fix times, float solutions, wider precision estimates. You can design your system to respond to visible degradation. You can’t design around degradation you can’t see.
Network RTK
Redundancy and robustness. If a station goes down — maintenance, equipment failure, someone bumps the antenna (and that happens more often than you’d think) — with single-baseline, your whole job site stops until you switch. Network RTK draws from multiple stations, so a single outage doesn’t interrupt your operation.
Midfield performance. When you’re equidistant from several stations — say 40 km from three stations in a triangle — you definitely have more information if you take the data from all three than just the one that happens to be 39.2 km away. This is especially noticeable with lower-cost receivers that have less complex RTK engines. Network RTK can help those receivers converge faster and maintain more stable solutions. So Network RTK can outperform single-baseline in the 30–40 km range, particularly with lower-cost receivers that have less complex RTK algorithms — because they benefit from having more data to work with, but only if the underlying network is dense
A Note on Receiver Quality
One thing that often gets overlooked: your receiver’s published RTK specification sets a floor on achievable accuracy. Some receivers spec at 0.6 cm; others start at 1 cm or more. No correction service — single-baseline or Network RTK — can exceed what your hardware is capable of.
The honest answer to “how will my rover perform on your network?” is that it’s very dependent on your rover and how it’s implemented. The RTK capability spec and the parts-per-million slope (error introduced with increasing distance from the base station) are what you’ll find on the receiver’s data sheet, and those numbers matter.
Data in has a high factor in what comes out — and that applies on both sides. Whoever your correction provider is, the quality of their base station receivers, their monitoring, and their infrastructure directly shapes the quality of what reaches your rover.
What to Ask Your Correction Provider
If there’s one thing to take from this post: ask about density before you ask about correction type.
Inter-station spacing. Ask your service provider for a map of base stations. If the answer is vague, or the provider leads with coverage area in square kilometers rather than station density, that might tell you something. Coverage without density is a vanity metric.
Excursion rates at the 99th percentile. Median accuracy is the easy number to put in a spec sheet. Tail performance is what your production system depends on.
Replayability. Can you trace the full correction chain? Can you reproduce the exact positioning result from the same inputs? If you’re building anything autonomous, you’ll need this — and most people don’t realize it until they’re debugging a field failure at 2 AM.
What density supports the model. If someone is selling you Network RTK, ask what’s behind it. A sophisticated atmospheric model fed by sparse stations is like a high-resolution display connected to a low-quality camera. The processing is impressive. The output is limited by the input.
The correction architecture is a design choice you make based on your operational priorities. Both are legitimate. The network density is the foundation that determines whether either architecture delivers on its specifications.
If your model works most of the time, your accuracy will be there most of the time. The question is whether your application can survive the rest of the time.
You can’t fight physics. But you can build infrastructure that respects it.
Try It Yourself
At Point One, we built the densest professionally-managed GNSS reference network in the world — 30-40 km average station spacing, nearly three times denser than typical commercial networks — because the applications we serve can’t tolerate hidden systematic errors.
We’ve offered single-baseline RTK since our founding. Now, with the launch of our Network RTK service, you have a choice. Both deliver 1–3 cm accuracy, because both are powered by the same dense network.
You don’t have to pick a side. You can choose based on what your application actually needs — and switch between them as your requirements evolve.
Explore the Point One network map of base stations.
Get started with Point One’s RTK service with a Free Trial