原文地址為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 解決方案相似的實驗，並且想分享他們的結果，請在下面留言。