The RTK Trick: How Does Carrier Phase RTK Reach Centimeter Accuracy

Carrier phase RTK reaches centimeter accuracy by reducing shared error, measuring a finer signal, resolving the missing whole-cycle count, and validating that its supporting evidence remains intact.

Our guide to what RTK GPS is and how the basic correction workflow works uses a deliberately simple story: a reference receiver sees how far ordinary GNSS is off and helps nearby receivers correct a similar error.

That explains why a nearby reference helps. It does not explain centimeters. The actual mechanism compares observations from multiple receivers and satellites before it introduces a far finer ranging observable than code timing alone.

Real RTK starts with four simultaneous measurements.

Double Difference GNSS: Four Measurements, Two Subtractions

A single epoch of dual-receiver, dual-satellite tracking creates the 2×2 observation set from which RTK forms its two subtractions:

Observation notation: A1 means Receiver A's observation of Satellite 1. A2, B1, and B2 follow the same row-and-column convention.

The same satellite clock error appears in observations from both nearby receivers, while each receiver carries its own receiver clock bias. Double differencing removes those clock terms in two steps and reduces other errors only when the two receivers see sufficiently similar conditions.

First difference: two receivers, one satellite

For Satellite 1, subtract Receiver B's observation from Receiver A's:

The satellite clock error is common to both observations, so it cancels. Over a short baseline, residual orbit error, ionospheric delay, and tropospheric delay are also similar enough that much of each term is reduced. The receiver clock bias remains different, so one subtraction is not enough.

Second difference: two satellites

Repeat that receiver difference for Satellite 2, then subtract the two results:

The receiver-clock difference appears in both single differences, so the second subtraction removes it. The remaining observation is a cleaner relative measurement between the receivers, not a position by itself. Standalone GNSS must estimate receiver clock bias as an unknown; short-baseline RTK suppresses it through differencing before the solver estimates the relative baseline.

Difference processing helps only where the error is genuinely shared. A short baseline does not make orbit error, ionospheric delay, or tropospheric delay disappear; it makes their residuals similar enough that differencing can suppress much of them. Local multipath, interference, and receiver noise never meet that assumption:

For the definitions and typical scale of each term, see our map of GNSS error sources and the GNSS error budget.

RTK Base, Rover, and Baseline: Relative vs Absolute Accuracy

In a deployed RTK system, the reference receiver is the Base, the moving or measured receiver is the Rover, and the distance between them is the baseline.

A shorter baseline usually makes the Base and Rover experience more similar orbit error, ionospheric delay, and tropospheric delay, so their difference is more useful. This is why RTK accuracy is often written as a baseline-dependent expression rather than one fixed number.

A common horizontal specification is 1 cm + 1 ppm: the fixed term is 1 cm, while the ppm term adds about 1 mm for every kilometre of Base-to-Rover baseline (10 mm at 10 km). It is a product test convention, not a universal law; the confidence level, receiver, antenna, correction source, environment, and task still matter. There is no universal distance at which RTK abruptly stops working.

RTK makes the Rover precise relative to the Base first. That relative result becomes an accurate absolute coordinate only when the Base is anchored correctly in the coordinate frame the application expects.

A Rover can therefore look stable and repeatable while the entire job is shifted. That is a reference problem, not necessarily an ambiguity problem. Our guide to GNSS coordinate systems and datums explains why a good fix can still disagree with a map.

Carrier Phase vs Pseudorange: Why RTK Uses a Finer Ruler

Ordinary GNSS begins with the pseudorandom noise, or PRN, code. The receiver aligns the arriving code with a locally generated copy, estimates signal travel time, and turns that time into a distance called a pseudorange.

Code timing is direct and robust, but its observation noise is typically at the meter scale. That is enough for a standalone position, but not enough to produce centimeter positioning by itself.

The same GNSS signal also contains a radio-frequency carrier. The receiver tracks that carrier to maintain lock, and high-precision GNSS uses the carrier's phase as a second, finer observable from the same transmitted wave.

The two observations differ in both precision and what they leave unknown:

GPS L1 is transmitted at 1575.42 MHz, which corresponds to a wavelength of about 19 cm. One percent of an L1 cycle is 1.9 mm. That conversion explains why sub-cycle phase tracking works at a millimeter scale, roughly two orders of magnitude finer than code pseudorange.

It is a measurement-scale comparison, not a universal 1-2 mm receiver specification: actual phase error depends on signal strength, multipath, tracking loops, and receiver noise. For the wider signal picture, see our guide to GNSS frequencies and L1, L2, and L5 signal bands.

Integer Ambiguity in RTK: The Missing Whole-Cycle Count

Pseudorange and carrier phase express distance differently. Code timing provides a complete, noisy path estimate:

Carrier phase changes the representation. It measures the precise fractional position inside the carrier cycle, then adds an unknown count of complete cycles:

In the second expression, λ is the wavelength and N is the unknown integer number of full cycles folded into the observation when tracking begins. That unknown N is the integer ambiguity: the fractional phase is precise, but one phase reading does not reveal how many complete wavelengths lie between satellite and receiver.

Resolving N is a multivariate integer-search problem, not a one-satellite lookup. Every usable satellite-signal pair adds an ambiguity dimension. As an illustration, even a ten-ambiguity problem with only three plausible integers per dimension contains 3¹⁰ = 59,049 combinations if searched naively.

A real receiver does not enumerate that cube blindly. Pseudorange, satellite geometry, multiple frequencies, continuous epochs, correction data, and uncertainty estimates constrain the float solution to a much smaller neighborhood of plausible candidates.

Double differences help twice. They remove the dominant clock terms and reduce shared residuals, which produces a tighter float ambiguity estimate. In the conventional differential model, differencing also cancels the fractional receiver and satellite phase biases so that the remaining ambiguity term is integer-valued; Navipedia’s carrier-phase ambiguity reference describes that property.

Practical engines then reparameterize highly correlated ambiguity estimates into less coupled integer combinations before candidate enumeration. This does not remove physical ambiguity dimensions; it makes the candidate search and validation more efficient.

Before a candidate is accepted, ambiguity estimates remain real-valued and uncertain: this is Float. Fixed applies integer constraints only after the engine accepts a candidate and the measurements remain consistent. A loss of lock invalidates continuity for the affected satellite-signal observation and forces that ambiguity to be initialized again.

RTK Float vs Fixed: What Each Solution State Actually Means

Float and Fixed are ambiguity-solution states, not formal accuracy units.

In RTK Float, the solver is estimating ambiguity values and their uncertainty but has not accepted one integer combination. The result is often better than standalone GNSS and may reach decimeter or sub-meter performance, but the actual error remains environment- and receiver-dependent.

In RTK Fixed, the solver has accepted an integer solution. With clean observations, current corrections, suitable geometry, and a sound reference setup, those constraints can support a centimeter-grade position.

The status ladder separates the algorithm state from its common field result:

Two receivers can report Fixed under the same sky and still differ in convergence time, stability, or resistance to bad observations. The label tells you the stage the engine reached, not every rule it used to reach it.

Why RTK Drops from Fixed to Float: Four Links Behind Every Fix

A Fixed solution is the last result of a four-link chain. If any link weakens, the receiver may remain Float, reject a candidate, or stop maintaining a previously accepted solution:

Receiving bytes is not the same as using corrections. RTCM correction data carries reference observations, coordinates, and related messages. NTRIP correction delivery is one common transport path. A live connection can still point to the wrong mountpoint, omit signals the Rover needs, carry incompatible content, or describe a distant or mismatched reference.

Local antenna environment dictates phase continuity. Buildings, trees, vehicle structures, and reflective surfaces can remove or distort the signals used by both ends of the RTK link. A loss of lock creates a cycle slip: a whole-cycle discontinuity in the carrier measurement. The previously accepted ambiguity for that satellite-signal observation is no longer valid, so the receiver must discard or reinitialize it.

With enough unaffected observations, an engine may preserve a partial solution or recover quickly. When the remaining evidence is insufficient, Fixed drops to Float and convergence starts again.

For diagnosis, check solution state and correction age first. Confirm that corrections are being used, then inspect sky view, signal continuity, geometry, and local multipath. Only after those checks should the ambiguity engine become the main suspect.

Can RTK Fixed Be Wrong? False Fixes and Wrong Base Coordinates

Yes. Fixed means the algorithm accepted an integer solution; it does not independently verify the physical world.

A false fix occurs when the solver accepts the wrong integer combination. It is more dangerous than Float because Float admits uncertainty. A false fix can produce a stable-looking coordinate and a normal status flag while the relative position itself is wrong.

How a false fix happens

A false fix is not an arbitrary guess. The engine begins with a float ambiguity vector and an uncertainty model, then searches nearby integer candidates. Many engines compare the best candidate with the next-best candidate and add residual or time-consistency checks.

Those tests ask whether a candidate fits the available data and model better than its alternatives; they do not compare the Rover against ground truth.

Multipath or non-line-of-sight signals can bias local observations and survive double differencing. Interference contaminates measurements. Blockage and cycle slips break phase continuity. Weak geometry, too few clean observations, or residual atmospheric mismatch can move the float estimate toward the wrong integer set.

Under those conditions, a wrong candidate can appear sufficiently consistent and sufficiently separated from its nearest alternative to pass validation. A conservative engine may remain Float when that separation is weak; a system optimized for fast availability needs equally strong integrity safeguards.

False fix is not the same as a wrong Base coordinate

These failures can both produce a convincing but incorrect map position. They fail at different layers:

A false fix calls for scrutiny of observations, continuity, geometry, and ambiguity validation. A wrong Base coordinate calls for scrutiny of survey coordinates, datum, reference frame, antenna height, and network configuration. Reinitializing the Rover will not repair a wrong reference coordinate.

How to Judge RTK Fix Quality: Confidence, Monitoring, and Fallback

A GNSS receiver produces the best estimate it can from the satellites, environment, corrections, and models available at that moment. The coordinate is an output, not proof.

Accuracy describes how far the result may be from truth. Confidence describes how strongly the available evidence supports using that result. The statistical language behind CEP, RMS, R95, and DOP is covered in our guide to GNSS accuracy, probability, and DOP. Here the operational question is simpler: should the application accept this epoch?

No single field is an acceptance gate. The following signals test different layers of evidence and should be read together:

Applications can turn those signals into four lightweight operating states:

• Accepted: Fixed and the supporting indicators remain healthy. Continue normal precision operation.
• Degraded: The solution returns to Float or quality indicators weaken. Slow down, warn the operator, or widen control limits.
• Untrusted: A position jump, stale correction, or sensor disagreement appears. Reject the update, pause, or revalidate.
• Recovered: Fixed returns and remains consistent for a task-defined period. Resume only after the evidence is stable again.

The gate should follow the cost of being wrong. A survey point, autonomous machine, mowing robot, and visual map marker do not need the same response. It should also use history: a freshly recovered Fix may need to remain consistent for a task-defined hold period before precision work resumes.

A low-risk display may show a degraded position with a warning; a machine controlling motion near people or fixed infrastructure may need to stop.

Conclusion: Centimeter Accuracy Is Conditional

RTK centimeter accuracy is a conditional output, not a permanent receiver mode. A Fix must continue to survive fresh corrections, continuous phase measurements, a sound reference, and the application's own cross-checks.

System integration must move beyond “Is it Fixed?” The acceptance rule must define what evidence supports that state and the exact fallback action when the state, corrections, or observations degrade.

Zero Jiang

Founder, Kalmix

Dedicated to making high-precision GNSS positioning accessible and reliable for global developers. Passionate about autonomous systems, RTK technology, and robust hardware engineering.