Imagine a small field robot moving along a row of crops. Its satellite-positioning display changes from FLOAT to FIX, and the plotted track settles into a thinner line. RTKLIB makes that change inspectable: its architecture separates communication streams, measurement decoding and the estimation that produces a position. Following those stages reveals what the software has established when it reports a fix—and what still needs checking in the field.

RTKLIB is an open-source GNSS positioning library with several applications built around it. RTKNAVI and its command-line counterpart RTKRCV perform real-time positioning; RTKPOST and RNX2RTKP process recorded observations. The common library gives these applications access to positioning algorithms, receiver decoders and navigation-data handling.[1] This note follows the upstream 2.4-series design, using the versioned manual and source snapshot identified below.

A connection is only the first stage

RTKNAVI exposes three input roles: rover, base station and correction. Their use depends on the positioning mode. For conventional relative RTK, the essential pairing is observations from the rover and a reference receiver, together with the navigation information needed to locate the satellites. The manual requires receiver observation and ephemeris data and offers separate choices for a stream's transport and data format.[3]

Those choices answer different questions. Serial, TCP and NTRIP describe ways to bring data in. RTCM or a supported receiver's binary format tells the decoder how to interpret the incoming bytes. NTRIP can carry reference-station data over the internet, but choosing a caster connection does not establish that the desired observation messages are arriving.[3]

The distinction is visible in rtksvr.c. The server reads input bytes, passes them to an RTCM or receiver-specific decoder, and gathers decoded observations for the positioning call. For each available rover observation epoch, it assembles rover and base observations and calls rtkpos() with the navigation data.[4] An epoch is the measurement time: the solver needs observations that belong together, rather than an undifferentiated stream of traffic.

For our imaginary robot, this suggests a useful debugging sequence. Establish that bytes arrive, then that the selected decoder recognizes useful observations, then inspect the resulting solution. A busy connection indicator answers only the first of those questions. This is an inference from the separation of responsibilities in the server, and a practical reason to preserve that separation in monitoring.[4]

The second antenna changes the calculation

Carrier-phase measurements offer fine precision, but they contain an unknown whole number of wavelengths. The receiver can track the wave's phase without initially knowing how many complete cycles lie along the signal path. Relative RTK combines observations from a rover and a base whose position is known; differencing measurements helps cancel shared errors and makes those integer ambiguities tractable.[5]

ESA's Navipedia explains that atmospheric and orbital errors become less alike as the receivers move farther apart. Multipath, interference and receiver noise remain after differential processing: a reference feed cannot remove every problem at the rover's antenna.[5]

The station photograph makes another dependency tangible. There is a mounted antenna at the reference end, with a particular position. RTK estimates the rover relative to that reference and uses the base coordinates to place it in a global frame.[5] From this follows an important distinction: a tightly clustered rover track can still be displaced if the reference coordinates are wrong. Precision within the track and agreement with an independently known location are separate checks.

What the fix actually fixes

In the upstream positioning code, a float estimate carries continuously valued ambiguity estimates. The resamb_LAMBDA() routine searches for integer candidates and compares their fit through a ratio test against a configured threshold. An accepted candidate allows the code to form a fixed solution.[6] Here, “fixed” concerns the ambiguity integers; a rover in kinematic operation can still be moving.

Timing also has an explicit gate. For ordinary relative positioning, rtkpos() computes the time difference between the rover and base observations. If its magnitude exceeds the configured maximum, that call returns without running the relative-positioning calculation. The code exposes solution status, differential age and ambiguity-validation ratio as distinct fields.[6] These describe different aspects of the estimate and deserve to remain distinct in any application built on top.

An accepted integer hypothesis is a result of the estimator's model and tests. My engineering reading is that an application should also check the result against its own evidence: a surveyed location, a known separation, or another suitable measurement. A FIX label alone cannot perform that comparison.

Independent research illustrates why validation can continue after ambiguity resolution. In their 2023 ION GNSS+ paper, Zhen Zhu and colleagues describe an RTKLIB-based implementation that uses time-differenced carrier phase and RANSAC to exclude suspect satellites and validate a solution after its integers have been resolved. Their published abstract reports a post-processing demonstration with two types of low-cost receivers.[7] That is a specific research extension, not a feature claim about every upstream RTKLIB build.

Save the measurements that made the line

RTKLIB's logging arrangement preserves a valuable distinction between observations and answers. In the server, incoming receiver or RTCM bytes are written to the configured log stream before decoding. Position solutions have their own output path.[4] Keeping only the plotted coordinates discards much of the evidence needed to investigate how they were obtained.

For replay through RTKNAVI's file-input workflow, the manual instructs users to enable Time-Tag logging, which creates a companion .tag file.[3] A useful recording therefore includes the input logs and their timing information, alongside the solution output. I would also retain the exact build, processing configuration and reference coordinates so that a later comparison has a defined starting point.

For an individual experimenter or a small engineering team, a manageable first trial is a short recording at an independently known point, followed by replay with one processing choice changed. Someone needs to own the receiver configuration and the reference metadata. A team feeding positions into an automated system also needs an explicit response to missing observations, ageing reference data and changes in solution status.

The payoff is a field result that can be questioned. When the robot's line becomes smooth, the retained measurements let its operator ask which observations supported that change, whether the integer decision survives scrutiny, and whether the resulting location agrees with the ground.

Sources

1. Tomoji Takasu, RTKLIB project README — library, application roles and supported interfaces; upstream source snapshot 71db0ff, checked November 4, 2026.
2. NOAA National Geodetic Survey, “Kandi, AI — CORS Site Photos,” station BJKA — archived antenna and monument photograph; the page cautions that photographs may not show current equipment.
3. Tomoji Takasu, RTKLIB 2.4.2 Manual, sections 3.2–3.3 — input configuration and time-tagged logging.
4. RTKLIB, src/rtksvr.c — input decoding, observation assembly, raw logging and solution output, source snapshot 71db0ff.
5. GMV, “RTK Fundamentals,” ESA Navipedia, 2011, revised 2018 — independent explanation of relative positioning and its limits.
6. RTKLIB, src/rtkpos.c — float and fixed estimates, LAMBDA ambiguity resolution, ratio validation and observation-age checks, source snapshot 71db0ff.
7. Zhen Zhu and colleagues, “Validation of Low-Cost RTK and PPK Solutions Assisted with Random Sample Consensus in a GNSS-Challenged Environment,” ION GNSS+ 2023 — public abstract describing an RTKLIB-based validation extension.