【翻译】使用 Swiftnav Piksi Multi的PPP方案结果分析

本文主要是介绍【翻译】使用 Swiftnav Piksi Multi的PPP方案结果分析，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

原文章《PPP solutions with the Swiftnav Piksi Multi》来自rtklibexplorer 2017年-11-23日的文章，讲述PPP的信息，原文章地址：https://rtklibexplorer.wordpress.com/2017/11/23/ppp-solutions-with-the-swiftnav-piksi-multi/ 这里仅作简单的翻译，部分为意译，翻译不当还请指教。

I have had a couple recent questions about the Swiftnav receiver and PPP solutions so before leaving the stationary rover for a moving rover, I thought I would take a quick look at this subject.

我最近有一些关于 Swiftnav 接收器和 PPP 解决方案的问题，所以在停止静态接收机测试转向动态接收机测试前，我想我应该快速看一下这个主题。

Unlike RTK or PPK which are differential solutions using two receivers, PPP (precise point positioning) is an absolute solution done with just a single receiver. Since we don’t have the advantage of eliminating the errors through differencing, it is a more challenging problem and is usually (but not always) done with dual frequency receivers for stationary targets. RTKLIB does support PPP solutions and we will look at them too, but in general I prefer using one of the free online services since it is easier to do this and the answers are more accurate. PPP solutions require precise clock and ephemeris data which must be downloaded from the internet. Since you need to be connected to the internet anyways to download these, I see very little advantage to trying to run your own solution with RTKLIB unless you are using it as a learning tool.

与 RTK 或 PPK 是使用两个接收机的差分解决方案不同，PPP (精密单点定位)是只用一个接收机完成的绝对定位解决方案。由于没有通过差分消除误差的优势，精确定位变得更具挑战性，通常(但并不总是)对静止的目标通过双频接收机来实现定位。RTKLIB的确支持 PPP 解决方案，我们也会考虑这些方案，但是总的来说我更喜欢使用免费的在线服务，因为这样做更容易，而且结果也更准确。PPP 解决方案需要精确的时钟和星历数据，这些数据必须从互联网上下载。通常下载这些数据星历和时钟数据时你得使用网络，所以我觉得，和使用在线PPP服务相比，使用RTKLIB算出一个结果并没有太多的优势，除非你想着把使用RTKLIB做PPP解算当作是一个学习的过程。

There are several different online services available and they all have their own advantages and disadvantages. I will use the CSRS service, provided by the government of Canada, in this experiment for a few reasons.

有几种不同的在线服务，它们都有自己的优点和缺点。在这个实验中，我将使用由加拿大政府提供的 CSRS 服务，原因有几个。

First of all, unlike some of the other services, CSRS uses the GLONASS satellites in the PPP solution. This is particularly relevant for the Swift receiver since it is L2C and only half of the GPS satellites include dual frequency measurements. In this case, including the GLONASS satellites roughly triples the number of measurements. CSRS will also process L2C data directly. Some of the other services won’t work with L2C data unless you modify the header of the observation file. If you do run into this problem trying to use another service, manually editing the Rinex file header and changing the observation type from C2 to P2 in the file header will usually work.

首先，与其他一些服务不同，CSRS 在 PPP 解决方案中使用 GLONASS 卫星。这对 Swift 接收机尤其重要，因为它是 L2C的，而且只有一半的 GPS 卫星包括双频观测值。在这种情况下，包括 GLONASS 卫星在内，观测值大约是原来的三倍。并且CSRS 还将直接处理 L2C 数据。除非您修改观测值文件的文件头，否则其他一些服务无法处理 L2C 数据。如果您在尝试使用其他服务时遇到了这个问题，那么手动编辑 Rinex 文件的文件头并将文件头中的观测类型从 C2更改为 P2通常是可行的。

Another reason for using CSRS for this experiment is that it will solve for single frequency data sets as well as dual frequency. The single frequency solutions are based on code observations only and significantly less accurate than the dual frequency solutions but they are available. In this case I will take advantage of this to compare the PPP solution for both single frequency M8T data and dual frequency Swift data.

另一个使用 CSRS 进行本实验的原因是，它能解算单频数据和双频数据。单频解仅仅基于伪距观测值，远不如双频解精确，但它们都可以参与解算。因此我将利用这一点来比较单频 M8T 数据和双频 Swift 数据的 PPP 解决方案。

CSRS also has a very convenient data submission tool that can be downloaded to your computer. With this tool installed and configured, you simply need to drag any observation file onto the tool icon and it will email you a solution a few minutes later. It’s hard to get much simpler than that! You do need to setup an account before accessing the service or downloading the tool but that is a relatively quick and easy process and only has to be done once.

CSRS 还有一个非常方便的工具，可以将它下载到您的计算机上。安装和配置这个工具后，您只需将任何观测者文件拖到工具图标上，几分钟后它就会给您发送解决方案。没有比这更简单的了！在访问服务或下载工具之前，你确实需要设置一个帐户，但这是一个相对快速和简单的过程，而且只需要做一次。

One last feature that CSRS provides that many of the other services don’t is the option to process kinematic data sets as well as static but I have not tried this out yet.

最后，CSRS 不仅能处理静态数据集，同时也能处理动态数据集，而许多其他服务都没有这个功能，但是我还没有尝试过。

For this experiment, I used eight hours of data collected from the Swiftnav GPS-500 antenna on my roof which was connected to both a Swiftnav receiver and a u-blox M8T receiver through a splitter. The antenna is mounted on a one meter pole at the bottom edge of a low-angled roof so has a reasonably good, but certainly not ideal, sky view.

在这个实验中，我使用了从我屋顶上的swiftnavgps-500天线收集的8小时数据，这个天线通过一个信号分离器连接到 swiftnavacter 接收机和 u-blox M8T 接收机。该天线安装在一个低角度屋顶的底部边缘的一米杆上，所以有一个相当好的天顶视图，但肯定不理想。

The accuracy of the PPP solution will depend on the accuracy of the ephemeris used. This will vary based on how long it has been since the measurement data was collected. Here is a list from their website of the three possibilities along with their wait times and accuracies for the CSRS solutions.

PPP 解的精确度将取决于所用星历的精确度。这取决于测量数据收集以来的时间长短。这里是从他们的网站列出的三种可能性，以及他们的等待时间和 CSRS 解决方案的准确性。

• FINAL (+/- 2 cm): combined weekly and available 13 -15 days after the end of the week

最终产品 (+/-2厘米) : 每周一次，当前周后13-15天后可用

• RAPID (+/- 5 cm): available the next day

快速 (+/-5厘米) : 第二天可用

• ULTRA RAPID (+/- 15 cm): available every 90 minutes

超快速(+/-15厘米) : 每90分钟可用

In my case, I had collected this data a few days earlier so CSRS was able to use the rapid precise ephemeris data for the solution.

在我的例子中，我在几天前收集了这些数据，所以 CSRS 能够使用快速精密星历数据来解决这个问题。

I converted both raw binary files to Rinex format using the RTKCONV app in RTKLIB. CSRS only accepts the older 2.11 format so I did need to specify this in the RTKCONV options. Usually I use the newer 3.03 format since it is easier to read and to parse with Matlab.

我在 RTKLIB 中使用 RTKCONV 应用程序将两个原始二进制文件转换为 Rinex 格式。CSRS 只接受旧的2.11格式，所以我确实需要在 RTKCONV 选项中指定它。通常我使用较新的3.03格式，因为它更方便使用matlab进行读取和解析。

Next I dragged the two files onto the CSRS tool icon and a few minutes later both solutions appeared in my email folder. I had previously configured the tool with a few bits of information including my email address. The results included a pdf summary file and a csv file with the epoch by epoch convergence of the solution.

接下来，我把这两个文件拖到 CSRS 工具图标上，几分钟后，这两个解决方案都出现在我的电子邮件文件夹中。我之前已经配置了一些信息，包括我的电子邮件地址的工具位。结果包括一个 pdf 摘要文件和一个 csv 文件，其中包含 epoch by epoch 的收敛解。

Here is the solution from the csv file for the Swift receiver. The results in the file are in LLH format where latitude and longitude are both in degrees. I converted both from degrees to meters using the appropriate meters per degree constants for my particular location, then subtracted the final point to generate the plot below. Note that this is a different coordinate system than I used in the plots in my last post in which I converted the LLH coordinates to earth-centric XYZ coordinates. In XYZ coordinates, the Z coordinate is only equivalent to height if you made the measurement at the North or South pole. In this case I have used the angle to meter conversion to preserve the separation between vertical and horizontal components to better show their relative accuracies.

下面是 Swift 接收机的 csv 文件中的解。文件中的结果是 LLH 格式的，其中经纬度都是度。我使用特定位置的适当的米/度常数将两者从度转换为米，然后减去最后一个点以生成下面的图。请注意，这是一个不同的坐标系，在我上一篇文章中，我将 LLH 坐标转换为地球中心的 XYZ 坐标。在 XYZ 坐标系中，如果你在北极或南极进行测量，z 坐标只等于高度。在这种情况下，我使用角度到仪表的转换来保持垂直和水平分量之间的分离，以便更好地显示它们的相对精度。

In this case the horizontal components converged to something very close to the final answer in about two and a half hours whereas the vertical component doesn’t seem to have fully converged even in eight hours.

在这种情况下，水平部分在大约两个半小时内收敛到非常接近最终解，而竖直部分似乎在八个小时内也没有完全收敛。

The 95% confidence levels for the results reported in the summary file were about one cm for the combined horizontal components and 2.5 cm for the vertical component. This was consistent with my best guess for the actual errors based on both RTK and PPP measurements made with multiple receivers and online services. I estimate the actual error being about one cm in the combined horizontal components and about 1.5 cm in the vertical component.

摘要文件中报告的结果的95% 置信水平对于合并的水平部分约为1厘米，对于垂直部分约为2.5厘米。这与我对基于 RTK 和 PPP 测量的实际误差的最佳猜测是一致的，这两种测量都是通过多个接收器和在线服务进行的。我估计实际误差在组合的水平分量中约为1厘米，在垂直分量中约为1.5厘米。

I did not include any antenna calibration corrections in my solutions since I am not aware of a calibration file available for the GPS-500 antenna. This means my solutions will be for the location of the phase center of the antenna, not the geometric center. In this particular experiment, since I am only using the results to compare with other results from the same antenna, the errors will cancel and can be ignored. Normally though, this offset will an add additional error to the position measurements. Ideally for accurate absolute measurements, a calibrated antenna would be used, in which case the calibration file can be specified in the solution and RTKLIB will apply the correction to remove this error.

在我的解决方案，我没有包括任何天线校准更正，因为我不知道一个可用于 GPS-500天线的校准文件。这意味着我的解决方案将是天线的相位中心的位置，而不是几何中心。在这个特殊的实验中，由于我只是用这些结果与同一天线的其他结果进行比较，因此误差将被抵消掉，可以忽略不计。通常情况下，这种偏移会增加位置测量的额外误差。对于精确的绝对测量来说，最好使用经过校准的天线，在这种情况下，可以在解决方案中指定校准文件，RTKLIB 将进行修正以消除这个误差。

Unfortunately the CSRS PPP single frequency results for the M8T data were much less accurate with about half a meter of error in the horizontal components and three quarters of a meter error in the vertical axis.

不幸的是，CSRS PPP 单一频率的 M8T 数据结果准确得多，水平分量误差大约半米，垂直轴误差四分之三米。

I then ran a PPP solution with RTKLIB for both data sets using a configuration similar to what is recommended in this tutorial. The Swift data produced a result with very similar accuracies to the CSRS result in the horizontal components but nearly five cm of error in the vertical component. Note that the convergence times are longer in the RTKLIB solution. It is likely that both solutions would have reduced vertical errors if I had run with a longer data set. The typical recommendation for PPP solutions is at least two hours of measurement data but longer data sets will generally improve accuracy. Here is a plot of the RTKLIB PPP solution for the Swift data.

然后，我用 RTKLIB 为这两个数据集运行了 PPP 解决方案，使用的配置类似于本教程中推荐的配置。雨燕数据得出的结果与 CSRS 的结果非常接近，其中水平分量的结果与 CSRS 的结果非常接近，但垂直分量的结果误差接近5厘米。注意，RTKLIB 解决方案的收敛时间更长。如果我使用较长的数据集，这两种解决方案都可能减少垂直错误。对 PPP 解决方案的典型建议是至少两个小时的测量数据，但是较长的数据集通常会提高准确性。下面是针对 Swift 数据的 RTKLIB PPP 解决方案的图表。

In this case I was not able to get an RTKLIB PPP solution for the M8T data because of too large residual errors. In other cases I have got PPP solutions with single frequency data but the accuracy of the solutions has always been much lower than the dual frequency data. I do not have a lot of experience with the PPP settings in RTKLIB so it is possible I am not getting the most out of RTKLIB. I hope to dig into this side of things more in the future.

在这种情况下，我无法为 M8T 数据获得 RTKLIB PPP 解决方案，因为剩余误差太大。在其他情况下，我得到了单频数据的 PPP 解决方案，但解决方案的准确性一直远远低于双频数据。我没有很多的经验与在 RTKLIB 的 PPP 设置，所以它是可能的，我没有得到最多的 RTKLIB。我希望将来能更深入地研究这方面的事情。

PPP is great for locating static receivers but if you need to track moving rovers, you will still want to use RTK or PPK solutions for that. The ability to get accurate locations for your base station using a PPP solution though is a significant advantage of using dual frequency receivers rather than single frequency receivers. This is particularly true if your base station is not close enough to a CORS type reference station to get an RTK/PPK solution for your base station location.

PPP 对静态定位来说是一个伟大的方法，但如果你需要跟踪一个移动的接收机的时候，你仍然希望使用 RTK 或 PPK 解决方案。使用 PPP 解决方案获得基站精确位置的能力是使用双频接收机而不是单频接收机的一个显著优势。如果您的基站离 CORS 类型的参考站不够近，无法获得适合您的基站位置的 RTK/PPK 解决方案，那么这种情况尤其明显。

There is a significant advantage in having two identical receivers for RTK/PPK solutions since it will give the maximum number of overlapping measurements to difference and will allow ambiguity resolution with the GLONASS satellites. In this case the simplest configuration would be to use Swift receivers for both base and rover. A less expensive alternative worth considering would be to connect a Swift receiver and M8T receiver to the base station antenna through a splitter and then use an M8T receiver for the rover. You could then use the Swift receiver to find your base location and the two M8T receivers to find the rover location relative to the base position.

拥有两个 RTK/PPK 解决方案的相同接收机有一个显著的优势，因为这将使重叠的测量数量达到差值的最大值，并使全球轨道导航卫星系统能够解决模糊度问题。在这种情况下，最简单的配置就是同时为基地和漫游者使用 Swift 接收器。值得考虑的一个较便宜的替代方案是通过分配器将 Swift 接收器和 M8T 接收器连接到基站天线，然后为漫游者使用 M8T 接收器。然后你可以使用 Swift 接收器找到你的基地位置，两个 M8T 接收器找到漫游者相对于基地位置的位置。

For me at least, this ability to locate the base with PPP would be the most compelling reason to justify the extra cost of the Swift receivers over the M8T receivers.

至少对我来说，这种利用 PPP 定位基地的能力将是证明 Swift 接收器比 M8T 接收器额外成本的最有说服力的理由。

Hopefully, this time in my next post, I will actually get to looking at the moving rover case with the Swift receivers. After that I hope to do a four way comparison between the M8T, and low cost dual frequency receivers from Swift, Tersus, and ComNav. I met Andy from ComNav at the recent drone expo in Las Vegas and he was kind enough to lend me two of their receivers and antennas for a couple months to use for evaluation. I also understand that Tersus has recently updated their firmware so I’m quite excited about all the different options becoming available in the low cost dual frequency receiver market.

希望这次在我的下一篇文章中，我能够真正看到斯威夫特接收器移动漫游者的情况。在此之后，我希望对 M8T 和来自 Swift，Tersus 和 ComNav 的低成本双频接收器进行四向比较。最近在拉斯维加斯的无人机博览会上，我遇到了 ComNav 公司的安迪，他好心地借给我两个接收器和天线，借我用几个月做评估。我也知道 Tersus 最近更新了他们的固件，所以我很高兴能在低成本的双频接收器市场上有所有不同的选择。

这篇关于【翻译】使用 Swiftnav Piksi Multi的PPP方案结果分析的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！