A standard smartphone GPS gets you to within a few meters. A survey-grade RTK receiver gets you to within a couple of centimeters, in real time, on a moving rover. That gap — roughly a hundredfold improvement in accuracy — isn’t a better antenna or a faster chip. It’s a fundamentally different measurement technique, and understanding it is what separates someone who operates GNSS equipment from someone who actually knows why it sometimes doesn’t work.
The Core Problem: Code Phase Isn’t Accurate Enough
Ordinary GPS positioning measures the travel time of a coded signal broadcast from each satellite — the «code phase» — and converts that time delay into a distance. This works, but the code itself is coarse enough that timing errors translate into meters of position error, compounded further by atmospheric delay, satellite clock drift, and orbital uncertainty.
RTK instead measures the carrier phase — the underlying radio wave itself, which oscillates at a known frequency with a wavelength of about 19 cm for GPS L1. If you can count the carrier wave cycles precisely, your ranging precision improves by roughly two orders of magnitude compared to code-phase measurement. The catch is the «integer ambiguity» problem: a receiver can measure the fractional part of a wave cycle very precisely, but it has no way to know, on its own, how many whole wavelengths separate it from the satellite. Solving that ambiguity — resolving it to the correct integer number of cycles — is the central computational challenge RTK exists to solve.
The Base-and-Rover Concept
RTK solves the ambiguity problem by using two receivers at once:
- A base station, at a precisely known, fixed location.
- A rover, the moving receiver whose position you actually want.
Both receivers track the same satellites simultaneously. Because the base’s true position is already known, any discrepancy between its measured and known position reveals the local error sources — atmospheric delay, satellite clock and orbit errors, multipath — affecting that region of sky at that moment. The base broadcasts that correction data to the rover in real time, and the rover applies it to its own carrier-phase measurements. Because both receivers are close enough to experience nearly identical atmospheric and orbital error, this differential correction cancels out the large majority of the error sources that limit standalone GPS accuracy, leaving only the integer ambiguity to resolve — which the rover’s processing does continuously, arriving at what’s called a «fixed» solution once it succeeds.
Fixed vs. Float: The Number That Actually Matters in the Field
Anyone who has run an RTK rover has watched the receiver cycle between two states, and this distinction matters more than any spec sheet number:
- Float solution: the receiver has a good estimate of the integer ambiguity but hasn’t locked it to an exact whole-cycle count yet. Accuracy is typically decimeter-level — better than code-phase GPS, but not survey-grade.
- Fixed solution: the receiver has resolved the integer ambiguity exactly. This is what delivers the centimeter-level accuracy RTK is known for, and it’s the state you should confirm your receiver has actually reached before recording any survey point, not just assume from a green light.
A receiver that repeatedly drops back to float in dense canopy or near structures isn’t broken — it’s telling you the satellite geometry or signal environment at that spot isn’t good enough to maintain a reliable fix, which is a real-world constraint worth planning around rather than fighting.
What Limits RTK: Baseline Distance and Correction Delivery
RTK’s accuracy depends on the base and rover experiencing nearly identical atmospheric conditions, which only holds true over a limited distance — typically referred to as the baseline. As baseline distance grows, atmospheric conditions between base and rover diverge, degrading correction quality. This is precisely why dense networks of permanent reference stations — CORS (Continuously Operating Reference Stations) networks — exist: instead of hauling your own base station to every site, you subscribe to a correction stream from the nearest network station, delivered over the internet using the NTRIP protocol, or over UHF/LoRa radio for sites without cellular coverage.
RTK vs. PPP vs. PPP-RTK: The Bigger Picture
RTK isn’t the only way to achieve high-precision GNSS positioning, and it’s worth understanding where it sits relative to the alternatives, since the correction-service landscape has been shifting:
| Method | Typical accuracy | Convergence time | Coverage | Local infrastructure needed |
|---|---|---|---|---|
| RTK | ~2 cm | ~20 seconds | Regional (limited by baseline distance) | Dense base station or CORS network |
| PPP (Precise Point Positioning) | ~30 cm | Several minutes or more | Global | None — uses global reference data |
| PPP-RTK | ~10 cm | ~20 seconds | Continental | Sparse reference network (compared to RTK) |
PPP achieves global coverage without any local base station by using highly precise satellite orbit and clock data broadcast from a small number of global reference stations, but it trades that infrastructure-free coverage for a long convergence time and lower final accuracy than RTK. PPP-RTK is the hybrid that’s gained real momentum in the past few years: it combines a sparser regional reference network with the same integer-ambiguity-resolution approach RTK uses, achieving RTK-like fast convergence and better-than-PPP accuracy without requiring the dense base-station coverage classic RTK needs. This is the technology behind newer base-station-free correction services now appearing on professional receivers — a genuine shift in how the industry delivers centimeter-class positioning where dense CORS coverage doesn’t already exist.
Why This Matters Beyond the Spec Sheet
Understanding the mechanism, not just the resulting accuracy number, changes how you actually work in the field:
- You’ll know why RTK struggles under dense canopy or near tall structures — it’s a satellite-visibility and multipath problem affecting ambiguity resolution, not a hardware defect, and it tells you when to expect degraded performance before you’re standing there confused about a dropped fix.
- You’ll understand why baseline distance to your correction source matters — a subscription to a CORS network 80 km away will perform differently than one 10 km away, and this is worth checking before choosing a correction provider.
- You’ll know what «float» actually means when you see it on screen — a decimeter-level warning, not a system failure, but not a state to record survey points in either.
- You’ll understand why PPP-RTK is showing up in more product marketing — it’s a genuine technical shift toward less infrastructure-dependent high-precision positioning, not just a rebrand of existing RTK.
Final Takeaway
RTK’s centimeter-level accuracy comes from measuring the GNSS carrier wave directly rather than the coarser broadcast code, using a base station’s known position to cancel shared atmospheric and orbital errors, and resolving the integer ambiguity in the carrier-phase count to lock onto a precise fix. Everything else — CORS networks, NTRIP corrections, fixed-vs-float indicators, baseline limitations — follows directly from that core mechanism. Understanding it is what turns «my RTK receiver keeps dropping to float» from a mystery into a solvable field problem.
Want a deeper look at how this plays out on specific hardware, or how PPP-RTK correction services compare across receiver brands? That’s covered in our GNSS receiver comparison.