【RTKLIB源码阅读】rtklibexplorer博客翻译-A first look at RTKLIB with dual frequency receivers

原文：https://rtklibexplorer.wordpress.com/2017/06/20/a-first-look-at-rtklib-with-dual-frequency-receivers/

正如我在上几篇文章中提到的，我最近一直在探索 RTKLIB 与几个不同的低成本双频接收机的使用。 低成本在这里是一个相对的术语。 接收机的价格为 600-1700 美元，加上天线的费用，这些配置比我通常使用的基于 u-blox 的单频版本要贵得多。 不过，它们的价格还是比更多的传统制造商的型号要低很多。

我的第一个接收机是 Swift Navigation 的 Piksi Multi。

它可以从他们的网站上买到，开发板的价格是 595 美元，或者是 1995 美元的完整套件，包括两个接收器、天线和发射器。 该接收机依赖新的 L2C 码用于 L2 频率，因此不支持传统的 P2 代码。 L2C 是一种未加密的代码，只适用于较新的 GPS 卫星。 目前大约有一半的 GPS 卫星在播放这些代码，但随着新卫星的发射，这个数字还会增加。 这确实意味着 Multi 只能对具有 L2C 功能的卫星进行双频测量。 此外，尽管接收器硬件能够支持 GLONASS G1/G2、BeiDou B1/B2、Galileo E1/E5b、QZSS L1/L2 和 SBAS 信号，但目前的固件不支持这些星座。 这意味着该接收机目前的能力有些有限，但随着他们发布新的固件和更多卫星的发射，它应该会有所改善。

我一直在用的第二个接收机是一个更昂贵的，即 Tersus 公司的 Precis-BX306，可从其网站上购买，价格为 1699 美元。

该接收器确实支持 L2 频率的 P2 码，因此能够接收所有 GPS 卫星的双频信号。 在目前的硬件和固件中，它还支持 Glonass G1/G2 和北斗 B1/B2。 Tersus 也有类似的接收机，价格较低，但能力也不如这款。 Precis-BX305 完全支持 GPS L1/L2，但只支持 GLONASS G1 和北斗 B1/B3。 Precis-BX316R 支持与 BX306 相同的所有星座，但只提供原始测量，它没有内部 RTK 引擎。 这两款产品的售价均为 999 美元。

本着充分披露的精神，我应该提到，Tersus 公司给了我 BX306 接收机进行评估，我的一个咨询客户允许我使用他们的 Piksi Multi 接收机进行这次评估。 我感谢他们两个人的慷慨解囊。

在挖掘接收机的细节之前，值得先讨论一下双频接收机比单频接收机有什么优势，以及 RTKLIB 在多大程度上能够利用这些优势。 所有这些对我来说都是相当新的，所以下面的分析是基于我有点有限的理解。 如果我有什么错误，我希望有经验的读者能跳出来纠正我。

双频接收机最明显的优势是它比单频接收机对同一卫星星座提供更多的测量值。 然而，如果这是唯一的优势，那么在考虑到额外的 GLONASS、SBAS 和Galileo 测量时，仅支持 GPS 的 Piksi Multi 仍然不如 u-blox M8T。 双频接收机确实也倾向于拥有更多的高端电路，并倾向于与更昂贵的天线相配。

不过，最大的优势来自于用不同的频率对通过大气层的同一路径进行的多次测量。 以不同的方式使用这些测量对的线性组合，我们可以收集到单频测量所不能提供的信息。 两个特别有用的线性组合是无电离层组合和宽巷组合。

宽巷组合只是在两个频率下进行的相位测量的差值，这种组合的优点是，这种测量的有效波长是两个测量之间的频率差的函数。 在 L1/L2 的情况下，频率之差为 348 兆赫，波长为 86 厘米。 在 86 厘米的周期内解算整周模糊度要比在 19 厘米的更短的 L1 波长上解决这些模糊度容易得多，这是单频接收机的唯一选择。 一旦宽巷模糊度得到解决，它们就可以用来协助解决较短周期的 L1 和 L2 模糊度问题。 这可以使双频接收机的首次固定时间快得多。

当然，这些额外的信息只有在求解算法利用它们的时候才有价值。 不幸的是，RTKLIB 在这方面似乎相当令人失望。 在大多数情况下，RTKLIB 对 RTK 的默认配置是独立处理两个频率测量的，对线性组合的利用非常少。 这使得它们并不比来自不同卫星的两个测量值更有价值。 在配置文件中有一个启用无电离层组合的选项（pos1-ionoopt =dual-freq），它使用无电离层组合来估计相位偏差，而不是单独测量。 但用户手册指出，无电离层模型并不适用于 RTK 解算模式，我发现在运行RTK 解算时，设置这个选项会破坏模糊度解算。代码中还有一个宽巷模糊度的选项，但是用户手册中没有提到这个选项，而且如果设置了这个选项，就会试图调用一个不包括在 RTKLIB 源代码中的外部函数。 在 PPP 解决模式中，对双频的支持可能会多一点。 然而，当前的 RTKLIB 版本在 PPP 模式中没有对模糊度解算进行任何尝试。 RTKLIB 的 2.4.2 版本确实包括手册中所说的模糊度解算的测试版，但在 2.4.3 版本中已经删除。 如果没有模糊度解算，我在 PPP 解算方面的经验是，使用一些使用模糊度在线 PPP 服务可以得到比使用 RTKLIB 更好的解决方案。 我希望有人能证明我是错的，并提供一个配置文件，用 RTKLIB 生成一个 RTK 或 PPP 解决方案，充分利用双频测量的线性组合，但从我看到的一切来看，没有多少代码支持这种能力。

幸运的是，这两台接收机都可以在没有 RTKLIB 的情况下计算自己的 RTK 解。 因此，以下实验的目标是将两台接收机与 M8T 单频接收机进行比较，同时将其内部解法与 RTKLIB 解法进行比较。 不幸的是，这两台接收机都没有被设置为处理以前收集的测量数据的后处理，因此所有的内部 RTK解算都需要实时完成。 在我的上一篇文章中，我描述了我如何配置接收机以通过手机链接接收实时基站数据。

因此，让我们先看看一些实际的测量数据。

下面是一组从一辆行驶中的汽车上的两个接收机同时采集的测量观测数据。 左边的观测数据来自 u-blox M8T 接收机，右边的观测数据来自 Tersus 接收机。 只锁定在 L1 的卫星用黄色表示，锁定在 L1 和 L2 的卫星用绿色表示。

在数据集开始时，M8T 被锁定在 8 颗 GPS、7 颗Glonass、4颗 Galileo 卫星和 3 颗 SBAS 上，共有21次测量。 Tersus 接收器被锁定在 8 颗 GPS L1、7 颗 GPS L2、6 颗 Glonass L1 和 5 颗 Glonass L2上，共有 26 次测量。 即使在考虑 L1/L2 组合的额外优势或更昂贵的电子设备和天线之前，更多的卫星数量应该使 Tersus 比 M8T 更具优势。

下面是一组类似的数据。 M8T 接收机在左边，这次 Swift 在右边。 同样，黄色是单频的测量，绿色是双频的测量。

这一次，天空中的卫星少了几颗。 在数据集开始时，M8T 锁定了 7 颗 GPS、7 颗 Glonass、2 颗Galileo 和 3 颗 SBAS，总共有 19 个测量值。 Swift 接收机有 6 个GPS L1和4个GPS L2，总共只有10 个测量值。 特别是对于不利用 L1/L2 组合中的额外信息的 RTKLIB 来说，将很难弥补测量数量的不足。

如前所述，随着 Swift 发布支持 GLONASS、BeiDou、Galileo、QZSS 和 SBAS 的固件，以及更多具有 L2C 功能的 GPS 卫星的发射，这种情况应该得到改善。

在我的下一篇文章中，我将比较用这些不同的测量结果产生的解，包括来自 RTKLIB 和内部 RTK 引擎的解。