ZED-F9P双频接收机测试初步     DATE: 2019-12-09 17:31

对那些不够幸运不能很早地从u-blox拿到早期评估版的小伙伴来说,现在可以购买u-blox最新的低成本双频接收机ZED-F9P了。CSGShop现在正在售卖一版ZED-F9P接收机,售价260美元,看起来相当合理,因为它比NEO-M8P单频接收器仅多20美元。
更好的是,Ardusimple正在宣传一款F9P接收器,售价为158欧元(约合180美元)+ 20欧元的运费,但他们的主板将在1月份之前发货。据我所知,这实际上比今天任何人卖的M8P接收器(价格)都要便宜!
当然,这仍然比没有内置RTK引擎的u-blox M8T单频接收器更有价值,CSGShop上这款售价为75美元,于明年推出的没有内置RTK引擎的F9T势必会将双频接收机的价格降到最低。
不幸的是,我并不是直接从u-blox获得评估板的幸运者之一。但是,我确实有两个来自Gumstix的原型板,由他们给我给我来做评估。Gumstix提供现成的电路板和半定制电路板。我没有直接与他们合作,但它看起来像一个有趣和有用的概念。Gumstix的F9P主板至少在明年2月才会发售,但我想我会分享一些初步测试的结果。从性能角度来看,我希望这些主板与其他供应商的F9P主板类似。
首先选择了一个附近常用的驾驶路线对F9P与M8T进行比较。对F9P自带的实时解和RTKLIB解、实时解和后处理解进行了比较。

实验设置:

对于基站,通过天线分线器将CSGShop M8T接收机和Gumstix F9P接收机连接到我屋顶上的ComNav AT330双频天线上。由于RTKLIB尚未完全支持设置F9P所需的接收机命令,因此我使用在Windows笔记本电脑上运行的u-blox u-Center应用程序的最新版本(18.08),根据u-blox官网上的文档来配置F9P接收机,然后我将设置保存到闪存上。接收器通过USB数据线连接到笔记本电脑上,利用之前提到过的STRSVR和RTK2GO.com将基站的观测数据利用网络以NTRIP流的形式播发出去。我将F9P配置为发送RTCM3 1005,1077,1087,1097,1127和1230电文,这其中包括基站的位置、原始观测值和GLONASS偏差值。
大多数情况下,u-blox文档写得很好,这个实验(exercise)做起来相当简单,但(做的时候)我确实遇到了几个问题。首先,当我将F9P接收机插入笔记本电脑时,Windows选择了标准的Windows COM端口驱动程序,而不是像插入M8T那样选择u-blox GNSS COM端口驱动,如下图所示,其中COM17对应是M8T,COM21对应的是F9P。
驱动异常
两个驱动程序都允许用户通过右键单击设备名称在属性菜单中设置波特率。使用u-blox驱动程序时,波特率设置似乎并不重要,因为它是USB连接。我总是将u-blox驱动程序波特率保留为默认值9600波特,没出现过问题。但是,使用Windows驱动程序时,我发现必须将波特率设置增加到115200以避免数据丢失问题。之前采样率大于5HZ时也遇到过相同的问题,那时候我用UART串口连接M8T,再利用一个FTDI转换器连接USB而不是直连用USB接口(连接M8T)。虽然我确认,在当前这个测试情况下,主板使用接收机上的USB接口而不是UART接口。没有大碍,可能是这块板子比较特殊吧,但为了防止以后你也碰到相同的问题,你仍然需要留意一下。
我遇到的第二个问题是F9P模块似乎对我的天线分线器比较敏感,这个分线器是一个标准的SMA DC模块和tee,我之前在许多其他接收器上使用过这个模块但没有问题。如果断掉F9P的电源,分线器就会工作正常;但如果关闭M8T的电源,F9P似乎会检测到tee,并关闭天线电源。同样,这不是什么大问题,但需要知道一下。
对于流动站,我为F9P配备了一个u-blox ANN-MB-00双频天线。这是u-blox为评估版F9P提供的天线单元。我曾经计划像往常一样将这个天线信号分配给两个接收器,但我遇到了上述问题,并且到现在也没完全搞懂这个问题,最后单独为M8T配备了一个Tallysman TW4721 L1天线。两个天线都直接安装在车顶上,这个可以把车顶作当作是一个比较大的平面。
我用手机上的热点将基站的NTRIP观测值数据流传到笔记本电脑里,然后既传给一个F9P接收机,又传传给两个RTKNAVI程序,每个程序对应一个流动站接收机。
将基站观测值数据流传输到F9P,同时记录内置RTK解和流动站原始观测值,并将原始流动站观测值发送到RTKNAVI,只用一个串口会比较有挑战性,因为一个串口同时只能连一个应用程序。幸运的是,RTKLIB有一个小技巧可以解决这个问题。如下图所示,如果在STRSVR中勾选了“Output Received Stream to TCP Port”并且指定端口号,则来自串行端口上另一方向的所有数据将被重定向到本地TCP / IP端口。然后,任何其他RTKLIB应用程序可以使用指定的端口号将此数据作为具有服务器地址“localhost”的TCP客户端进行访问。
串口号设置
将流动站的F9P设置为输出原始观测值、导航信息(UBX-RXM-RAWX / UBX-RXM-SFRBX)和解信息(UBX-NAV-POSLLH)。利用RTKNAVI将所有这些消息记录到单个日志文件中。RTKCONV和RTKPLOT都可以从这个日志文件里提取他们需要的消息而忽略其余的消息,因此组合它们(成一个文件)不是问题。
来自F9P的解信息POSLLH消息的经纬度的精度默认为1e-7°,大约为1厘米。要获得更高精度,您可以使用POSHLLH消息,也可以通过在UBX-CFG-NMEA消息中设置一个位来提高POSLLH消息的精度(这里应该指的是有效位数)。RTKLIB只能理解POSLLH消息,这就是我所使用的。不幸的是,直到收集到数据后我才意识到精度的问题,所以实验中我得到的F9T自带RTK解由于设置了一个比较低的精度(resolution)所以会比较差。
我使用最新的demo5 b31代码来计算所有RTKLIB解。demo5和2.4.3版本的RTKLIB都已更新,以转换新的双频u-blox二进制电文。demo5的代码能处理所有双频观测值,但我不相信2.4.3的代码能够处理Galileo E5b的观测值,RTKLIB 2.4.2并没有对此做任何更新。
在最近的B30 / B31版本中进行的demo5代码更新是基于2.4.3 B30代码的更新,但包括对我之前添加到M8T的demo5代码中的u-blox周跳处理的一些修改。由于demo5代码主要针对低成本接收机,因此我也进行了一些更改,以使E5b频率更易于指定和更快处理。
为了用RTKNAVI算F9P的实时解,我唯一需要对默认的M8T配置文件进行的重大更改是将频率选项从“L1”更改为“L1 + L2 + E5b”。我还应该将基站位置获取方式改为“RTCM Antenna Position”以利用F9基站的RTCM 1005电文但这里不这样做。由于RTKNAVI解中使用的近似基本位置,这会导致RTKNAVI解与F9P解有一个比较小的不同。我会在后来使用RTKLIB后处理中使用基站的准确位置来验证不同的解方案是否完全匹配。
完成了所有上述设置后,我绕着社区周围开车,特别注意那些星空图比较有挑战性的街道,因为我知道两个接收器都表现良好,如果条件不够挑战性,就会很难区分两者。

结果:

首先使用RTKCONV将二进制日志文件转换为观测文件并确认一下F9P是否记录了GPS,GLONASS和Galileo的L1和L2观测值。我也启用了Bediou星座,但据我后来验证,当我收集数据时,并没有完全正常运行的Bediou卫星。
下图是L1观测值序列图,左侧是M8T,右侧是F9P。在观测条件比较差的时段,我对数据放大了约2分钟以比较二者。红色的点表示发生了周跳,灰色的点表示存在半周模糊度。
比较
首先需要注意一下F9P没有记录SBAS卫星的观测值,而M8T记录了,这为M8T提供了更多的可用卫星。然而,有趣的是,我不知道为什么,F9P从Galileo的E27卫星收集了相当不错的观测值,而M8T却根本没有收到这颗星的观测值。当然,F9P还对每颗卫星的第二频率进行了第二组测量,因此它最终得到的原始观测值总体上几乎是M8T的两倍。
另外请注意,与M8T相比,F9P报告的周跳更少,半周期模糊度更少。其中可能是因为天线不同,但特别是半周期模糊度的巨大差异表明u-blox除了添加第二频率之外还对新模块进行了其他改进。
另一件值得注意的事情是Galileo卫星的数量。如果你把上图结果与我发布的早期实验进行比较,你会发现现在有更多的伽利略卫星,因为越来越多的卫星开始上线。额外的卫星确实对M8T的解有帮助,因为正如您所看到的,它们往往在最困难的时候(环境比较差)拥有最高质量的观测。我不知道为什么会这样。尽管如此,它对F9P来说似乎并非如此。
接下来我对实时解进行了比较。首先是两个接收机的RTKNAVI实时解。对于完整的驾驶路线,M8T解的固定率为77.3%,而F9P解的固定率为96.4%。对驾驶中最具挑战性的部分,一个较旧的社区,这里街道较窄,树木较大的结果进行放大,如下图。M8T在左侧,F9P在右侧。绿色表示固定解,黄色表示浮动解。显然,F9P明显优于M8T。

F9P自带RTK解的效果更好,其固定率为99.2%,如下图所示。3个解的水平误差都在2cm以内,在垂直方向上误差大一点,并且它们都没有显示任何错误固定的迹象。

我没有像以前那样做静态测试来描述首次固定时间,这一次测试中,利用RTKLIB,M8T首次固定的时间是18秒,而 F9P则在6秒内就达到第一次固定。在这两种情况下,当硬件完成锁定卫星并获取所有卫星的导航数据后RTKLIB启动。demo5 的RTKLIB代码中有一个额外的基于卡尔曼滤波位置方差的固定约束条件,用于在滤波收敛时降低错误固定率,这样做有时就会影响首次固定的时间。在这个实验里,我已将此参数增加到0.1米,因为大量的观测可降低错误固定的可能性。这个约束并没有限制M8T首次固定时间,但它对F9P这样做了,这意味着如果增大这个约束参数值,F9P会更快达到第一次固定。我不知道这个参数对应的的F9P内部RTK解的等效数字是什么,因为它早已经运行并在我开始记录数据之前实现了固定,但通常F9P似乎很快就能实现第一次固定。
接下来,我使用RTKLIB对两组数据做后处理,滤波方式选择“combined”,对数据做向前和向后卡尔曼滤波。这显着改善了结果,使M8T的固定率从77.3%上升到96.1%,F9P固定率从96.4%上升到98.8%。

结论:

显然这还不足以得出任何明确的结论,但到目前为止我对F9P印象非常深刻!F9P的原始观测数据和内置RTK解看起来和任何一个花费比它高几倍的接收机的效果一样好。
如果有人想更仔细地查看这个实验的数据,我已将其上传到此处。有一点需要指出,我在这篇帖子和其他帖子中所说的所有固定率都不会与原始解决方案中的固定率完全匹配,因为我调整了数据的开始和结束时间来保证数据集的一致性,并在达到第一次固定后才开始。我相信这是比较多种解决方案的最公平的方式,特别是当内部解和RTKLIB解决混合使用时。
另外,我还要再次感谢Gumstix将这些模块提供给我进行评估!

更新:12/2/18:

回顾一下我在本次实验中使用的配置文件,我发现虽然我原本打算将实时和后处理配置文件保持一致,但实际上它们之间存在一些细微差别。特别的一个差别,之前提到过的会影响结果的,是我在后处理配置文件中降低了后处理时固定整周模糊度所需要的最小的连续样本数(pos2-arminfix),从100降低到20。过去对于一个采样率为5HZ的实验,我通常将这个值设置为100。然而,随着模糊度跟踪增益(pos2-varholdamb = 0.1)的降低以及来自Galileo的观察结果的增加,固定错误的可能性降低,并且我在最近的实验中倾向于使用较低的arminfix值。减少这个值似乎可以解释M8T在实时和后处理下出现的固定率的跳跃,而不是像之前那样归因于由向前滤波(forward)切换到组合(combined)滤波(导致固定率的变化)。这些滤波的变化差异仅影响RTKLIB实时和后处理结果之间的比较,而不影响M8T和F9P之间的比较,因为配置文件在两个接收器之间是一致的。
这个实验仅仅只是为了更快速的了解F9P。它需要更多的数据和更多的分析来正确表征F9P,所以我不会尝试在这里做,但我将分享下面的表格,其中包括我在原始帖子后跑的一些案例。我希望在未来的帖子中能深挖更多的细节。
  固定率      
  实时 事后 事后 事后
arminfix 100 100 20 20
滤波 forward forward forward combined
M8T/RTKLIB 77.3% 81.2% 96.2% 96.1%
F9P/RTKLIB 96.4% 99.1% 99.3% 98.8%
F9P internal 99.2%      
最后值得一提的是,乍一看,后期处理中,固定的百分比从M8T = 96.0%增加到F9P = 99.3%可能听起来不那么显着,但如果你从浮点率降低的角度去看的话,它几乎变化了6倍,从浮点率4.0%降低到到0.7%。

原文链接:rtklibexplorer:A first look at the u-blox ZED-F9P dual frequency receiver

  上一篇:动态RTK如何设置