设想一台小型田间机器人沿着一行作物前进。卫星定位界面上的状态从 FLOAT（浮点解）变为 FIX（固定解），绘出的轨迹也收拢成一条更细的线。借助 RTKLIB，这次变化的来由可以逐层查清：它在架构上将通信数据流、观测值解码和求取位置的估计过程分开。沿着这些环节看下去，便能知道软件报告固定解时已经确认了什么，以及哪些问题仍需到现场核验。

RTKLIB 是一个开源的全球卫星导航系统（GNSS）定位库，并有数款基于它开发的应用程序。RTKNAVI 及其命令行版本 RTKRCV 用于实时定位；RTKPOST 和 RNX2RTKP 用于处理已记录的观测数据。这些应用共用同一个库，调用其中的定位算法、接收机解码器和导航数据处理功能。[1] 本文沿用上游 2.4 系列的设计，依据下文列明版本的手册和源代码快照展开。

建立连接只是第一步

RTKNAVI 设有三种输入角色：流动站、基准站和改正数据，具体用途取决于定位模式。常规相对 RTK（实时动态定位）所需的核心输入，是流动站与参考接收机的一组观测数据，以及确定卫星位置所需的导航信息。手册要求输入接收机观测数据和星历数据，并将数据流的传输方式与数据格式分别列为配置项。[3]

这两类配置回答的是不同问题。串口、TCP 和 NTRIP 决定数据如何传入；RTCM 或受支持接收机的二进制格式，则告诉解码器如何解释收到的字节。NTRIP 可以经由互联网传输基准站数据，但选好 caster（数据转发服务器）连接之后，仍需确认所需的观测消息是否抵达。[3]

这一区分在 rtksvr.c 中清晰可见。服务程序读取输入字节，交给 RTCM 解码器或接收机专用解码器，再汇集解码后的观测值，供定位函数调用。每当流动站有一个观测历元的数据可用，程序就组合流动站和基准站的观测值，连同导航数据一起传给 rtkpos()。[4] 历元指观测对应的时刻：解算器需要时间上能够配合使用的观测值，仅有持续传入的数据还不够。

回到那台设想中的机器人，这种分工提示了一套实用的排查顺序：先确认字节是否抵达，再确认选定的解码器是否识别出了有效观测值，随后检查定位结果。活跃的连接指示灯只能回答第一个问题。这是根据服务程序的职责划分得出的推论，也说明了监控系统为何值得保留同样的区分。[4]

第二副天线如何改变计算

载波相位观测值的精度很高，但其中包含一个未知的整周数。接收机能够跟踪电磁波的相位，最初却不知道信号传播路径上共有多少个完整周期。相对 RTK 将流动站与已知位置的基准站观测值结合起来，对观测值求差，有助于抵消共同误差，也让这些整周模糊度更易于求解。[5]

ESA 的 Navipedia 解释了其中的距离限制：两台接收机相隔越远，各自受到的大气误差和轨道误差就越不相似。差分处理之后，多路径效应、干扰和接收机噪声仍然存在，基准站数据能消除的误差有其范围，流动站天线处的这些问题仍需处理。[5]

测站照片还让另一项依赖变得具体可见：参考端安装着一副天线，天线有其特定的位置。RTK 估计流动站相对于这一参考端的位置，再利用基准站坐标将其置于全球坐标框架中。[5] 由此需要区分两项检查：轨迹内部的精密程度，以及轨迹与独立已知位置的吻合程度。即使流动站轨迹聚得很紧，基准站坐标一旦有误，整条轨迹仍会发生偏移。

固定解究竟固定了什么

在上游定位代码中，浮点解里的模糊度估计可以连续取值。resamb_LAMBDA() 例程搜索整数组合候选解，比较候选解的拟合程度，并按配置的阈值执行比值检验。候选解通过检验后，代码便能据此生成固定解。[6] 这里的“固定”指模糊度被确定为整数；在动态定位模式下，流动站仍可处于运动之中。

观测时间也有明确的检查条件。执行普通相对定位时，rtkpos() 会计算流动站与基准站观测值的时间差。若其绝对值超过配置的上限，该次调用便直接返回，跳过相对定位计算。代码将解状态、差分龄期和模糊度验证比值分别列为独立字段。[6] 它们描述了估计结果的不同方面，基于 RTKLIB 开发的应用也值得保留这一区分。

整数假设获准采用，是估计器依据自身模型与检验规则得出的结果。我的工程理解是，应用还应使用自身掌握的证据来核验定位结果，例如经过测量的已知位置、已知间距，或其他适当的测量结果。这项比对仍需另行完成，仅凭 FIX 标签尚不足以确认。

独立研究说明，整周模糊度解算之后，验证工作仍有继续开展的理由。在 2023 年 ION GNSS+ 论文中，Zhen Zhu 及其同事介绍了一项基于 RTKLIB 的实现：利用时间差分载波相位和随机抽样一致性算法（RANSAC）剔除可疑卫星，并在整周模糊度解算后验证定位解。公开摘要报告了采用两类低成本接收机开展的后处理演示。[7] 这项功能属于特定的研究扩展，不能据此认定每个上游 RTKLIB 构建版本都具备该功能。

留下绘出这条轨迹的观测数据

RTKLIB 的日志安排保留了一个很有价值的区分：观测数据与定位结果各有去处。在服务程序中，输入的接收机或 RTCM 字节会在解码前写入配置好的日志流，定位解则经由单独的通道输出。[4] 如果只留下绘图所用的坐标，追查这些坐标如何得来时，许多必要证据就已经丢失了。

通过 RTKNAVI 的文件输入流程回放数据时，手册要求启用 Time-Tag（时间标记）日志记录功能，该功能会生成一个配套的 .tag 文件。[3] 因此，一份有用的记录应同时包括输入日志、相应的时间信息和定位结果输出。我还会保留确切的构建版本、处理配置和基准站坐标，让后续比较有一个明确的起点。

对于独立实验者或小型工程团队，第一次试验可以从一项工作量适中的安排开始：在一个独立已知点短时记录数据，随后只改动一项处理设置，再回放同一份记录。接收机配置和基准站元数据需要有人负责维护。如果团队要将位置数据送入自动化系统，还需要明确规定遇到观测缺失、基准站数据变旧以及解状态变化时如何响应。

这些记录让现场结果有据可查。机器人轨迹变得平滑时，操作人员可以回看保留下来的观测数据，查明哪些观测促成了这一变化、整周模糊度的判定能否经受核验，以及解算位置是否与实地吻合。

资料来源

1. Tomoji Takasu，RTKLIB 项目 README——定位库、应用程序分工及支持的接口；上游源代码快照 71db0ff，核查于 2026 年 11 月 4 日。
2. NOAA 美国国家大地测量局，“Kandi, AI — CORS Site Photos”，BJKA 测站——天线和测量标石的存档照片；页面提醒，照片中的设备与当前设备未必一致。
3. Tomoji Takasu，《RTKLIB 2.4.2 手册》，第 3.2–3.3 节——输入配置和带时间标记的日志记录。
4. RTKLIB，src/rtksvr.c——输入解码、观测数据组合、原始数据日志和定位结果输出，源代码快照 71db0ff。
5. GMV，“RTK Fundamentals”，ESA Navipedia，2011 年，2018 年修订——对相对定位及其局限的独立解释。
6. RTKLIB，src/rtkpos.c——浮点解与固定解、LAMBDA 模糊度解算、比值检验及观测龄期检查，源代码快照 71db0ff。
7. Zhen Zhu 及其同事，“Validation of Low-Cost RTK and PPK Solutions Assisted with Random Sample Consensus in a GNSS-Challenged Environment”，ION GNSS+ 2023——介绍一项基于 RTKLIB 的验证扩展的公开摘要。