原文地址为https://rtklibexplorer.wordpress.com/2021/07/23/comparing-rtk-solutions-for-the-u-blox-f9p/，这里仅作翻译记录使用，更精确的理解请查看原文
The u-blox F9P internal RTK solution engine is very good and I have been recommending using it rather than RTKLIB for real-time RTK solutions, saving RTKLIB for F9P post-processing solutions. However, in this post, I will take another look at that recommendation.
U-blox F9P 内部 RTK 解决方案引擎是非常好的，我已经推荐使用它而不是 RTKLIB 实时 RTK 解决方案，保存 RTKLIB 为 F9P 后处理解决方案。然而，在这篇文章中，我将再次研究这个建议。
Tomoji Takasu, the creator of RTKLIB, recently published some data also confirming the high quality of the F9P RTK solutions. He ran comparisons of the F9P against several other receivers of various price and quality. You can see his results in the 2021/07/01 entry of his online diary. His conclusion (at least the Google translation of the original Japanese) is that “Considering the price, there is no reason to choose other than F9P at this time.”
高须智二，RTKLIB 的创建者，最近发表了一些数据，也证实了 F9P RTK 解决方案的高质量。他将 F9P 与其他几个价格和质量各异的接收器进行了比较。你可以在他2021/07/01的在线日记中看到他的研究结果。他的结论(至少是谷歌翻译的原版日语)是: “考虑到价格，目前没有理由选择 F9P 以外的其他产品。”
He did his comparisons by splitting an antenna output, feeding it to the two receivers being compared, then cycled the antenna output on and off. He fed the output of the receivers to RTKPLOT to produce plots like the example shown below from his diary which show acquire times and consistency of the fix location. In this case the upper plot is a Bynav C1-8S receiver and the lower plot is a u-blox F9P. The yellow intervals in the plot indicate float status and show the acquire times for each signal cycle. The green intervals indicate fix status and show the consistency of the fix location. Clearly the F9P outperformed the C1-8S in this example.
他通过分割天线输出进行比较，将其送入两个接收器进行比较，然后循环天线输出的开关。他把接收器的输出信息输入到 RTKPLOT，生成如下图所示的情节，这些情节来自他的日记，显示了获取修复位置的时间和一致性。在这种情况下，上图是 Bynav C1-8S 接收器，下图是 u-blox F9P。图中的黄色区间表示浮点状态，并显示每个信号周期的获取时间。绿色间隔表示固定状态并显示固定位置的一致性。显然，在本例中，F9P 的性能优于 C1-8S。
Receiver comparison data from Tomoji Takasu online diary 接收者比较数据来自高须友二在线日记
Inspired by his comparisons and the recent changes I incorporated into the demo5 b34c code, particularly the variable AR ratio threshold option described in my previous post, I decided it was time to do a similar head to head comparison between the internal F9P RTK solution and the latest demo5 RTKNAVI RTK solution.
受到他的比较和我最近在 demo5 b34c 代码中加入的改变的启发，特别是在我之前的文章中描述的可变 AR 比率阈值选项，我决定是时候对内部的 F9P RTK 解决方案和最新的 demo5 RTKNAVI RTK 解决方案进行一个类似的头对头的比较了。
To setup this experiment I used u-center to configure an Ardusimple F9P receiver to output both NMEA position messages (GGA) and raw observation messages (RAWX, SFRBX) to the USB port. I then setup STRSVR and RTKNAVI on my laptop as shown in the image below.
为了设置这个实验，我使用 u-center 配置了一个 Ardusimple F9P 接收器，将 NMEA 位置消息(GGA)和原始观察消息(RAWX，SFRBX)输出到 USB 端口。然后我在我的笔记本电脑上设置 STRSVR 和 RTKNAVI，如下图所示。
RTKLIB configuration for the comparison 用于比较的 RTKLIB 配置
The first instance of STRSVR is configured to stream NTRIP data from a nearby UNAVCO reference base (P041) to both the u-blox receiver and a local TCP/IP port. The output of the u-blox receiver is streamed to a second local TCP/IP port by selecting the “Output Received Stream to TCP Port” in the “Serial Options” window. The second instance of STRSVR then streams the second TCP/IP port containing the output of the u-blox receiver to a file for logging the internal F9P solution. This file will contain the raw observations in binary format as well as the receiver solution but RTKPLOT will ignore the binary data and plot just the NMEA message data.
STRSVR 的第一个实例被配置为从附近的 UNAVCO 引用基(P041)向 u-blox 接收器和本地 TCP/IP 端口流 NTRIP 数据。U-blox 接收器的输出通过选择“ Serial Options”窗口中的“ Output Received Stream to TCP Port”流输出到第二个本地 TCP/IP 端口。STRSVR 的第二个实例将包含 u-blox 接收器输出的第二个 TCP/IP 端口流到一个文件中，以便记录内部的 F9P 解决方案。这个文件将包含二进制格式的原始观测以及接收方案，但 RTKPLOT 将忽略二进制数据，只绘制 NMEA 报文数据。
The demo5_b34c version of RTKNAVI is configured to use the two TCP/IP ports configured above, one from the receiver, and one from the UNAVCO base, as inputs for rover and base. I also configured two instances of RTKPLOT so that I could see the real-time status of both solutions in addition to saving the results to files.
的 demo5_b34c 版本被配置为使用上面配置的两个 TCP/IP 端口，一个来自接收器，一个来自 UNAVCO 基地，作为漫游者和基地的输入。我还配置了 RTKPLOT 的两个实例，这样除了将结果保存到文件中之外，还可以看到两个解决方案的实时状态。
To setup the RTKNAVI config file for this experiment, I started with the PPK config file from the U-blox F9P kinematic PPP data set 12/24/20 data set and made a few changes to make it more suitable for a real-time solution. Time to first fix is not as important in post-processed solutions since they are usually run in both directions, so the config parameters in that file are set to minimize the chance of a false fix at the expense of relatively long acquire times. To shift this balance towards faster acquire times, I increased the maximum filter variance allowed for fix (Max Pos Var for AR / pos2-arthres1) from 0.1 to 1.0 and decreased the number of fix samples required for hold (Min Fix / pos2-arminfix) from 20 to 10. I also changed the solution type from combined to forward since combined mode is not possible for real-time solutions.
为了为这个实验设置 RTKNAVI 配置文件，我从 U-blox F9P 运动学 PPP 数据集12/24/20中的 PPK 配置文件开始，并进行了一些更改，使其更适合于实时解决方案。在后处理解决方案中，首次修复的时间并不重要，因为它们通常在两个方向上运行，所以文件中的配置参数被设置为最小化错误修复的可能性，以牺牲相对较长的获取时间为代价。为了将这种平衡转移到更快的获取时间，我将修复所允许的最大滤波方差(最大 Pos Var 为 AR/pos2-arthres1)从0.1增加到1.0，并将持有所需的修复样本数(Min Fix/pos2-arminfix)从20减少到10。我还将解决方案类型从 combined 更改为 forward，因为对于实时解决方案，组合模式是不可能的。
Most importantly, I enabled the new variable AR ratio threshold described in my previous post by setting the AR ratio threshold min and max (pos2-arthresmin, pos2-arthresmax) to 1.5 and 10. I left the nominal AR ratio threshold at 3.0. This means that instead of using a fixed AR ratio threshold of 3.0 for all epochs, the AR ratio threshold used in each epoch is selected from the blue curve below, with the limitation that it can not drop below the specified minimum of 1.5
最重要的是，我通过设置 AR 比值阈值 min 和 max (pos2-arthremin，pos2-arthremax)分别为1.5和10，启用了上一篇文章中描述的新的可变 AR 比值阈值。我将名义 AR 比率阈值保持在3.0。这就意味着，每个历元使用的 AR 比阈值不是固定的3.0，而是从下面的蓝色曲线中选取，其限制是不能低于规定的1.5
AR ratio threshold curves AR 比值阈值曲线
This will allow the AR ratio to drop well below 3.0 when there are many available satellites and the model strength is very high, while still protecting against false fixes by increasing the AR ratio when the number of satellites and the model strength are low.
这将使 AR 比率在有许多可用的卫星且模型强度非常高的情况下大大降低到3.0以下，同时在卫星数量和模型强度较低的情况下通过增加 AR 比率来防止错误的修正。
To run the experiment, I connected the antenna to the receiver, waited until both solutions had acquired a fix, then disconnected the antenna for 10-20 seconds to force the receiver to lose lock to all the satellites, then reconnected the antenna again. I repeated this sequence for about 15 cycles.
为了进行这个实验，我把天线连接到接收器上，等到两个方案都找到了解决方案，然后断开天线10-20秒，迫使接收器失去对所有卫星的锁定，然后重新连接天线。我重复这个序列大约15个周期。
I ran this experiment twice. The first time, I connected the receiver to a Harxon geodetic GPS-500 antenna mounted on my roof with a reasonably good view of the sky. The second time, I connected the receiver to a smaller, less expensive u-blox ANN-MB antenna with ground plane on a tripod in my backyard in a moderately challenging environment with the sky view partially blocked by the house and nearby trees. In both cases, the base station (P041) was 17 kms away and included Galileo E1 signals in addition to GPS and GLONASS.
我做了两次这个实验。第一次，我把接收器连接到一个 Harxon 大地测量 gps-500天线上，这个天线安装在我的屋顶上，可以相当清晰地看到天空。第二次，我把接收器连接到一个更小、更便宜的 u-blox ANN-MB 天线上，在我家后院的一个三脚架上安装了地面飞机，在一个适度具有挑战性的环境中，天空视野部分被房子和附近的树木所阻挡。在这两种情况下，基站(P041)距离17公里，除了全球定位系统和全球轨道导航卫星系统之外，还包括伽利略 e1信号。
Below is the result from the first experiment. As previously, yellow is float, and green is fix. The internal F9Psolution is on the top and the RTKNAVI solution is below. The blue in the F9P plot indicates a dead reckoning solution which only occurs when the antenna is disconnected, so can be ignored.. To reduce clutter in the plots I am showing only the U/D axis. In this case I know the precise location of my roof antenna so the y-axis values are absolute errors.
下面是第一个实验的结果。如前所述，黄色是浮动的，绿色是固定的。内部的 F9Psolution 在顶部，RTKNAVI 解决方案在下面。蓝色在 F9P 图表示航位推算的解决方案，只有当天线是断开，所以可以忽略。.为了减少图中的混乱，我只显示 u/d 轴。在这种情况下，我知道我的屋顶天线的精确位置，所以 y 轴值是绝对误差。
F9P vs RTKNAVI, GPS-500 antenna on roof F9P 对 RTKNAVI，gps-500屋顶天线
Here is a zoomed in version of the same plot. Both solutions acquire first fix fairly quickly in most cases. The absolute errors during fix are small for both solutions but do appear to be a little larger in the internal F9P solution. None of the errors are large enough to be considered false fixes.
下面是同一情节的放大版本。在大多数情况下，这两种解决方案都能相当快地获得第一修复。修正过程中的绝对误差对于两个解决方案都很小，但是在内部的 F9P 解决方案中似乎有一点大。没有一个错误大到足以被认为是错误的修复。
F9P vs RTKNAVI, GPS-500 antenna on roof (zoomed in) F9P 对 RTKNAVI，gps-500屋顶天线(放大)
Below is the same plot for the second experiment where the smaller ANN-MB antenna is located in a more challenging environment. Again, both solutions tend to acquire first fix quite quickly, and again the internal F9P errors appear to be larger than the RTKNAVI errors. In this case I don’t know the precise location of the antenna so the errors are relative.
下面是相同的图为第二个实验，其中较小的 ANN-MB 天线位于一个更具挑战性的环境。同样，两种解决方案都倾向于很快获得第一个修复，而且内部 F9P 错误似乎比 RTKNAVI 错误更大。在这种情况下，我不知道天线的精确位置，所以误差是相对的。
F9P vs RTKNAVI, ANN-MB antenna in backyard (zoomed in) F9P 对 RTKNAVI，后院的 ANN-MB 天线(放大)
Here is a summary of the acquire times for both solutions measured from the above plots. The plots don’t show precisely when the antenna was reconnected so I measured both acquire times starting from the first solution output sample after the disconnect gap, regardless of which solution it came from. The first column in the table is the number of acquisitions measured, the other columns show the minimum, maximum, mean, and standard deviations of the time to first fix in seconds.
下面是从上面的图表中测得的两种溶液获得时间的总结。图上没有显示天线重新连接的准确时间，所以我测量了从断开连接后的第一个解决方案输出样本开始的获取时间，不管它来自哪个解决方案。表中的第一列是测量的获取数量，其他列显示第一次修复时间的最小、最大、平均值和标准偏差(以秒为单位)。
GPS-500 antenna on roof
| solution | count | min | max | mean | std |
|---|---|---|---|---|---|
| F9P | 16 | 5 | 63 | 16.4 | 16.5 secs |
| RTKNAVI | 16 | 5 | 20 | 8.4 | 3.9 secs |
ANN-MB antenna in backyard
| solution | count | min | max | mean | std |
|---|---|---|---|---|---|
| F9P | 15 | 5 | 102 | 27.5 | 30.3 secs |
| RTKNAVI | 15 | 5 | 41 | 13.1 | 10 secs |
Time to first fix comparison between F9P and RTKNAVI F9P 和 RTKNAVI 首次修复比较的时间
Both solutions performed quite well in both experiments. The RTKNAVI solution outperformed the F9P internal solution in both cases, but given the very small amount of data and testing conditions, I would be reluctant to declare RTKNAVI the winner. I does suggest though, that the RTKLIB solution has closed the gap and should be considered at least roughly equal in performance to the internal RTK engine for real-time solutions.
两种方案在两个实验中都表现得很好。在这两种情况下，RTKNAVI 解决方案都优于 F9P 内部解决方案，但是考虑到数据量和测试条件非常少，我不愿意宣布 RTKNAVI 获胜。尽管如此，我还是建议 RTKLIB 解决方案已经消除了这个差距，并且应该认为至少在性能上与内部 RTK 引擎的实时解决方案大致相当。
In many cases it will still be simpler for real-time solutions to use the internal solution than RTKNAVI since it requires less configuration. There are cases, however, where it makes more sense to use an external solution even in real-time. For example, one user recently shared data with me where the rover is measuring real-time buoy activity. In order to avoid needing a bi-directional radio link, he sends the rover raw observations back to shore and calculates the solution there. Otherwise he would need to send the raw base observations to the buoy, and then send the resulting solution back to shore.
在许多情况下，使用内部解决方案的实时解决方案仍然比 RTKNAVI 更简单，因为它需要更少的配置。然而，在某些情况下，使用外部解决方案甚至是实时解决方案更有意义。例如，一个用户最近和我分享了探测器测量实时浮标活动的数据。为了避免需要一个双向无线电连接，他将探测器的原始观测结果发送回岸上，并在那里计算出解。否则，他需要将原始的基础观测数据发送到浮标上，然后将得到的结果发送回岸上。
If anyone else runs a similar experiment comparing RTKNAVI to the internal F9P solution and wants to share their results, please leave a comment below.
如果还有其他人在做 RTKNAVI 和内部的 F9P 解决方案相似的实验，并且想分享他们的结果，请在下面留言。