Base and Rover GPS Explained: How RTK Pairs Actually Work

Base and rover GPS from first principles: what each unit does, why the pair beats standalone GNSS by a hundredfold, what the base coordinates control, and how modern setups collapse the classic complexity.

The problem the pair was invented to solve

A single GNSS receiver — your phone, a drone’s standalone GPS — lands within a few metres of truth, because satellite signals cross an atmosphere that delays them unpredictably and orbits and clocks carry small errors. The insight behind RTK: two receivers near each other experience almost identical errors at the same instant. Let one sit still (the base) and continuously report what it observes; let the other move (the rover) and difference its observations against the base’s — the shared errors cancel, carrier-phase ambiguities resolve, and the rover’s position relative to the base collapses to 1–2 centimetres. That subtraction is the whole trick; everything else is delivery.

What the base actually does all day

The base’s job is monastic: occupy one position, track every satellite in view on multiple frequencies, and broadcast its raw observations plus its own coordinates in RTCM 3.x — the open format every rover speaks (the message anatomy). It computes nothing about the rover and does not even know rovers exist: the stream is a broadcast, which is why one base serves a drone, three tractors, and two survey rovers simultaneously without pairing. Its single point of vulnerability is self-knowledge — whatever the base believes about its own coordinates, every rover inherits, offset and all (the inheritance rule in full).

What the rover does with the stream

The rover receives corrections over radio, NTRIP, or a drone’s RC link, aligns them with its own observations epoch by epoch, and solves the between-receiver vector. While ambiguities are unresolved it reports FLOAT (decimetres); once resolved, FIX (centimetres) — the two words that govern field confidence (when FIX won’t come). Distance matters gently: accuracy degrades by about 1 mm per kilometre of baseline (the “1 ppm” term), and shared-atmosphere cancellation weakens past 30–40 km — the physics behind every network’s station spacing.

Where the base gets its coordinates — the pair’s only hard question

The classic answers: occupy a known monument; average an autonomous position (fast, but metre-class absolute — fine only for self-contained work); transfer coordinates from a network with a rover; log statics for OPUS or AUSPOS and wait a day. The modern answer folds the question into the hardware: a self-converging PPP base computes its own ~1.5 cm ITRF2020 position from L-Band satellite corrections in about three minutes — no monument, network, or wait (all five methods compared). Whichever route, this is the decision that sets the pair’s absolute accuracy; the rover merely delivers it.

Base-and-rover versus the alternatives

Architecture	Who provides the base	Accuracy	Dependencies
Own base + rover	You	1–2 cm relative to base	Base coordinates method
Network RTK	CORS operator	~cm inside coverage	Subscription, cellular, baselines
PPK pair	You (logs, not stream)	~cm after processing	Office step; base coordinates
PPP standalone	Satellites (no base)	~1.5–3 cm after minutes	Open sky; convergence per device

The architectures interlock rather than compete: the strongest modern stack uses PPP once at the base, RTK from base to rovers, and PPK logs as insurance — each method deployed where its costs are lowest (the full comparison).

A first setup, end to end

Day one with a base-and-rover kit: place the base on open ground (or a known point, if that is your coordinates method) and start it broadcasting; note the connection details — radio channel and protocol, or NTRIP host/port/mountpoint/credentials. On the rover: enter those details, watch correction age settle at 1–2 seconds, wait for FIX, and store a test point twice from different approaches — agreement within a couple of centimetres proves the pair. From there the workflow scales without new concepts: more rovers join the same broadcast; a drone joins through Custom Network RTK; a tractor joins over the radio. One stream, one datum, any number of consumers.

The vocabulary, decoded in one place

Base / reference station: the stationary receiver broadcasting corrections. Rover: any moving receiver consuming them. Baseline: the base-to-rover distance (source of the 1 ppm term). RTCM: the correction format. NTRIP: corrections over the internet; mountpoint: the named stream. FIX / FLOAT: ambiguity states — centimetres versus decimetres. RINEX: raw logs for post-processing. Known point: a monument with trusted coordinates. PPP: satellite-delivered absolute positioning — the technique that lets a base skip the known point entirely. Ten terms, and every base-and-rover conversation in the industry becomes readable.

Common beginner mistakes, pre-empted

Five patterns account for most first-month frustration. Averaging the base then wondering why data won't overlay the neighbour's survey — relative versus absolute, decided at the base. Case-typos in mountpoints — NTRIP connects and delivers silence. Forgetting the controller supplies the data path for a drone's NTRIP client. Judging health by satellite count instead of FIX status and correction age — the two numbers that actually matter. And changing the base position mid-session — every rover's frame shifts with it; converge or establish once, then leave it alone. Each mistake is cheap to avoid once named, which is most of what experience consists of.

One-line takeaway

The rover delivers the centimetres, but the base defines what they're relative to — master the pair by mastering one question (where does the base get its coordinates?) and one habit (watch FIX and correction age, not satellite counts).

Where to go from here

With the pair's logic in hand, the rest of this library slots into place: how the base earns its coordinates on unknown ground (four methods compared), what the correction stream contains (RTCM message anatomy), the three transports that carry it (radio, NTRIP, RC link), and the triage script when FIX refuses to come (the four families). Every one of them is a footnote to the same subtraction trick you now understand.

One-line takeaway

Two receivers, one subtraction: the base broadcasts what it sees from a position it must somehow know, the rover cancels the shared errors down to centimetres — learn where the base's coordinates come from and you understand the entire trade.

Further reading

The delivery mechanics glossed here — how the stream physically travels — are compared transport-by-transport in radio vs NTRIP vs RC link, and the cost consequences of the architecture are priced in the cost guide.

Frequently asked questions

What is the difference between base and rover GPS?

The base stays fixed and broadcasts its observations; rovers move and difference against them, achieving 1–2 cm relative to the base. Same hardware class, different roles — many receivers can play either.

How far can a rover work from the base?

Practically, link range governs (radio ~5 km, NTRIP unlimited in coverage); physically, accuracy degrades ~1 mm/km and solution robustness fades past 30–40 km baselines.

Can one base serve multiple rovers?

Yes — the RTCM stream is a broadcast with no pairing. Drones, tractors, machine control, and survey rovers can consume it simultaneously.

Do base and rover need to be the same brand?

No — RTCM 3.x is vendor-neutral. Any compliant base feeds any compliant rover, which is the foundation of mixed fleets.

Does the base have to be on a known point?

No — that is one of several coordinate methods. Averaging trades absolute accuracy for speed; PPP self-convergence delivers absolute coordinates with no point at all.