5. What RTK Really Measures
A GNSS RTK receiver sits over a point, connects to a correction source, and the status climbs from FLOAT to FIXED. The position settles. Estimated accuracy drops to a few centimeters. Repeated measurements agree closely.
It's tempting to read that as the receiver discovering the one true coordinate of that point. That isn't quite what happened.
RTK is exceptionally good at determining a rover's position relative to a reference. Whatever coordinate comes out of that process also inherits the reference frame, the epoch, and every assumption the reference itself was carrying.
Two Receivers Watching the Same Sky
A standalone receiver estimates its own position from satellite signals alone, carrying real errors along with it: satellite clock error, atmospheric delay, orbit uncertainty, and more. Place a second receiver nearby at a fixed position, and both receivers end up observing many of the same satellites through nearly the same slice of atmosphere.
Because the two receivers share so much of the same error, the known reference can help the rover cancel or sharply reduce it. That shared view is the entire foundation real-time kinematic positioning is built on.
The clearest way to picture this is not "the base tells the rover where it is." It's the rover combining its own satellite measurements with trusted information from that reference, still doing its own observing the whole time, and using both sets of information together to solve for the position that best fits everything available.
A correction source improves a rover's solution. It never replaces the rover's own measurements. Precision GNSS, at its core, is an estimation problem: combine what the rover itself observed with what a trusted reference supplied, and solve for whichever position best explains both.
Why Carrier Phase Changes Everything
Ordinary GNSS ranging uses coded signals to estimate distance to each satellite, precise enough for everyday navigation and nowhere near precise enough for centimeter-level work. RTK instead tracks the phase of the satellite's own carrier wave, whose wavelength is far shorter than the coded pattern, revealing distance changes the coded signal alone could never see.
There's a catch. The moment a receiver starts tracking, it has no way of knowing how many complete carrier-wave cycles actually lie between the satellite and its antenna. Those unknown whole-cycle counts are the integer ambiguities. A FLOAT solution is still estimating them as ordinary decimal numbers. A FIXED solution means the receiver resolved them to specific whole integers with enough statistical confidence to commit to that answer, not with absolute certainty.
What a FIX Actually Proves
| A FIX strongly supports | A FIX does not prove | Why the distinction matters |
|---|---|---|
| The carrier-phase solution is internally consistent | The coordinate is in the reference frame you expected | The correction source may use a different frame or realization entirely |
| The rover-to-reference geometry is highly precise | The base coordinate itself is correct | A base-position error transfers directly into the rover's result |
| Repeated measurements should agree closely under similar conditions | The elevation is referenced to mean sea level | GNSS reports ellipsoid height by default, unless a geoid model has been applied |
A FIX is a statement about the quality of the carrier-phase solution, nothing broader. A displayed accuracy figure, ten millimeters horizontal, for instance, is itself an estimate the receiver infers from the physics involved, not a guarantee. Trust the number, but hold it a little loosely.
"The receiver says FIXED, so the published coordinate must be correct" doesn't hold up. FIX confirms the RTK engine resolved its relative positioning solution. The final coordinate can still be shifted if the reference coordinate, the reference frame, the epoch, the antenna setup, or the height conversion behind it is wrong, among other possibilities, and FIX has no way to catch any of those. That's a separate concern from whether the fix itself was resolved correctly in the first place, false fixes and multipath included, which is its own subject covered in depth elsewhere in this series.
Where the Correction Actually Comes From
Three common paths supply an RTK rover with a reference to work against.
The first is a local base station: a second receiver either set up over an already-known point or left to survey in an approximate position of its own, sending its own observations directly to the rover.
The second is a real-time network: a service that sends observations from permanent stations across a region, usually delivered over NTRIP.
The third is a wide-area satellite or internet correction service, modeling orbit, clock, and atmospheric error across a large region and broadcasting it to any compatible receiver.
Coverage, setup, and processing all differ between the three. Every one still supplies a reference the rover's solution gets anchored to.
Making Sense of RTK, PPK, PPP, OSR, and SSR
These five terms get thrown around as if they're competing technologies. They aren't, and it's worth sorting out what each one actually answers before going further. Two independent questions do that sorting.
| Question | Choice | What it tells you |
|---|---|---|
| When? | Real time or post-processed | Whether the position is produced in the field or worked out afterward |
| How are corrections represented? | OSR or SSR | Whether the rover receives base-like observations, or a description of the individual error sources |
A solution can be real time or post-processed independently of whether it's built from observation-style corrections or modeled error states, which is exactly why these terms keep showing up in different combinations.
OSR, observation space representation, delivers a correction that behaves like observations from a reference station, and the rover combines that against its own measurements, commonly through single and double differencing, to cancel shared error. A physical local base is the most direct example, and a network RTK service can build the same kind of correction for a virtual, modeled reference station near the rover instead. Either way, what reaches the rover still looks like base-station information.
Most SparkPNT users receiving PointPerfect over its RTCM feed are receiving an OSR correction stream, even though the service itself runs a much larger correction infrastructure behind the scenes. What matters to the rover is the format actually delivered, not the size or sophistication of whatever produced it.
SSR, state space representation, works differently. Rather than building a base-like observation, it describes individual error sources directly, satellite orbit error, satellite clock error, signal biases, sometimes atmospheric effects, and a compatible receiver applies those modeled corrections straight onto its own undifferenced observations. SSR is a correction representation, nothing more specific than that. It is not simply another name for PPP, and it shouldn't be assumed just because a service happens to offer global coverage. What actually determines OSR versus SSR is the format delivered to the rover, not the scale of the service behind it.
PPP, precise point positioning, uses precise satellite orbit, clock, and bias information to solve a single receiver's position without comparing it against a nearby base at all. Classic PPP can need a real convergence period before reaching its best accuracy, though newer ambiguity-resolution techniques and regional atmospheric corrections, often called PPP-AR or PPP-RTK, can shorten that considerably.
PPP describes a positioning method. SSR describes a way of representing corrections. The two show up together often enough to blur into one idea, but they are not interchangeable terms, and a service can genuinely be one without being the other.
PPK, post-processed kinematic, means raw observations get logged in the field and the precise solution gets computed afterward, with no live correction link required during collection. PPK is fundamentally a statement about timing, not a single fixed correction model: a rover and a nearby base can be processed later as a differential solution, and a lone receiver can just as easily be processed later using precise satellite products as a form of post-processed PPP. What post-processing buys is real: recovering work after a dropped link, room for more careful quality control, and access to correction products that simply weren't available live in the field.
| Conventional RTK / OSR | PPP / SSR | PPK | |
|---|---|---|---|
| Timing | Real time | Real time or post-processed | After field collection |
| Nearby base | Usually a local base or network representation | Not required | Often used, but not always |
| Information used | Base-like observations or corrections | Orbit, clock, bias, and sometimes atmosphere states | Recorded observations plus later correction data |
| Main idea | Compare rover against a reference | Model the errors affecting one receiver directly | Trade a live link for processing later |
None of these five terms, on their own, guarantee the reference frame, the epoch, the antenna height, or the height type behind a position. Each one describes a different piece of how a solution gets computed or delivered, not what that solution actually means once it's computed. Real time or post-processed, base-like corrections or modeled error states, RTK or PPP or PPK, that part still has to be tracked deliberately every time.
Why a Wrong Base Coordinate Rides Straight Through
An RTK rover solves its position by differencing its own satellite observations against the base's, and that differencing cancels shared atmospheric, orbital, and clock error between the two. What it never does, and was never built to do, is check whether the base's own assumed coordinate is actually correct. That coordinate simply serves as the anchor point everything else in the solution gets attached to.
If the base's true position is known to the centimeter and the rover's carrier-phase solution is excellent, the rover's own coordinate comes out correctly anchored too. Shift the base's assigned coordinate by a full meter to the east instead, and the rover's carrier-phase solution can still be just as excellent, precise, repeatable, internally consistent, while the resulting coordinate comes out roughly a meter east of where it should actually be. The relative measurement was never the problem. The anchor it was measured against was.
This is not the RTK engine computing some separate "baseline" number and adding it to the base coordinate as an afterthought. The base coordinate is built into the estimation from the very start, which is exactly why differencing has no way to notice when that one number is wrong. An error there rides through to the rover's result essentially unchanged, not because anything failed, but because nothing in the process was ever capable of checking it.
Precise, and Still Somewhere Else Entirely
Set up an RTK receiver as a temporary base in a yard, let it average a standalone position for several minutes, sometimes called surveying in a base, and start transmitting corrections to a rover. That averaged base position typically sits decimeters to meters away from an authoritative survey coordinate.
The rover can still reach FIX quickly and report an accuracy of a centimeter or two, genuinely useful for measuring distances, mapping features, or returning to the same point later that same day. Measure the length of a building this way, and the result is excellent, since both ends of that measurement share the same base error and it cancels out of the difference. Measure the location of one corner of that same building, and the base's own error rides straight into the answer. A base sitting seventy centimeters from where it believes itself to be hands every single rover reading that same seventy-centimeter offset. Ten millimeters of reported accuracy is ten millimeters relative to the base. It is seven hundred and ten millimeters away from the real, authoritative position.
Averaging a base's own position does not connect it to an authoritative reference frame on its own. Work that has to match published control, GIS data, engineering plans, or a state RTK network needs a base coordinate deliberately established in the correct frame and epoch, not simply averaged in the field.
The Questions Worth Asking Before Trusting Any Fixed Coordinate
What correction source actually produced this solution? What coordinate was assigned to the base or network reference? Which reference frame or datum does that coordinate use? At what epoch is it valid? Is the reported height an ellipsoid height or an orthometric elevation? Were the antenna height and antenna reference point actually handled correctly?
RTK measures a rover's position with extraordinary precision relative to a reference. A FIX is a strong signal that the relative solution converged well, though not an absolute guarantee, since a false fix, multipath, poor satellite geometry, or atmospheric conditions can occasionally still slip through. The reference coordinate, and everything describing it, is what determines where that precise solution actually lands in the real world.
RTK hands over a precise three-dimensional coordinate, height included. That height is rarely the elevation most people are actually expecting. Chapter 6 asks a deceptively simple question, elevation above what, and that question leads directly to the ellipsoid, to gravity, and to why the geoid exists at all.