What RTK Already Taught Us
The next several chapters will repeatedly compare other methods against RTK, so it is worth being precise, briefly, about exactly what RTK actually is before contrasting anything against it.
RTK solves a rover's position in real time by comparing its carrier-phase observations against a nearby base or network's observations, canceling shared atmospheric and orbital error through that comparison, and resolving integer ambiguities immediately in the field.
The Three Ingredients Worth Remembering
Three properties of RTK matter most for what follows. First, it is real time: reference observations are made available and differenced against within moments, with a coordinate available immediately in the field. Second, it depends on a nearby reference, a physical base station or a network's modeled virtual station, close enough that shared error actually cancels. Third, it resolves integer ambiguities on the spot, using whatever satellite geometry and atmospheric conditions happen to exist at that exact moment.
Every one of RTK's three defining properties, real-time delivery, a nearby reference, and immediate ambiguity resolution, is a design choice. Each of the methods in this companion changes at least one of them deliberately.
What This Companion Will Not Repeat
How RTK actually cancels shared error, why baseline length matters, what a false fix is, and how to verify an RTK position were all covered in detail earlier in this series. None of that is repeated here. This companion takes RTK as a known, understood baseline, and asks a different question entirely: what happens to a position solution when one or more of those three defining properties is changed on purpose.
This companion is not a second, deeper explanation of RTK itself. It uses RTK as the baseline everything else gets compared against, assuming the mechanics were already covered earlier in this series.
The Question Worth Carrying Forward
With RTK's three defining properties clearly in view, real time, a nearby reference, immediate resolution, the next chapter turns those properties into a simple, reusable framework: two independent questions that, between them, explain every correction method in this companion.
RTK's identity rests on three properties: real-time delivery, a nearby physical or virtual reference, and immediate ambiguity resolution. This companion assumes that mechanism is already understood and uses it purely as a baseline for comparison.
Before turning to methods that change RTK's defining properties, it is worth pausing on something RTK itself already varies quite a bit: the actual physical and network arrangement that delivers the correction in the first place.