基于GAMP 的实时PPP 软件实现及性能分析

刘 亚 ，何 文涛 ，张 洁

(1.中国科学院微电子研究所，北京 100029；2.中国科学院大学，北京 100049；3.杭州中科微电子有限公司，浙江 杭州 310053)

0 引言

精密单点定位(Precise Point Positioning，PPP)利用卫星观测及导航数据，事后精密星历等可在全球范围内实现高精度定位[1]，相较于实时动态(Real-Time Kinematic，RTK)技术[2]摆脱了参考站的束缚，可以适用于更多的测量环境。

目前事后PPP 在函数模型以及定位解算策略上都比较成熟，不过对于PPP 实时化应用却显得不太稳定。现如今精密单点定位应用在各个领域，包括卫星定位、地震监测、大气误差反演及空间环境探测等[3]。对于大部分领域的应用，PPP 的实时化必不可少，而限制实时PPP 性能最主要的原因就来自于精密星历。

2007 年国际全球导航卫星系统(Global Navigation Satellite System，GNSS)服务组织(International GNSS Service，IGS)启动了实时项目(IGS Real-Time Pilot Project，IGS-RTPP），2013 年4 月1 日起利用全球实时跟踪网采集的GNSS数据，实时估计轨道及钟差改正数以空间状态表示(State Space Representation，SSR)形式，通过国际海运事业无线电技术委员会标准协议(Radio Technical Commission for Maritime services，RTCM)编码，基于RTCM 网络传输协议(Network Transport of RTCM via the Internet Protocol，NTRIP)向全球用户播发[4]。对于实时PPP，可以通过广播星历结合SSR 改正获得实时精密星历来进行高精度定位解算[5]。目前已有的处理实时PPP 软件有RTKLIB[6]和BNC[7]等，不过在PPP 处理策略或配置选择上没有GAMP 软件丰富，但是GAMP 是事后PPP 处理软件，所以本文在GAMP软件的基础上增加了实时数据接收及处理模块，完成了实时PPP 软件的搭建，验证了其处理实时数据及实时PPP 定位解算的功能。

1 GAMP 软件简介

GAMP 是山东科技大学周峰博士基于RTKLIB 精密单点定位部分编写的软件[8]，可以在多平台下运行，且对RTKLIB 中很多算法进行了改进，如周跳探测、钟跳修复以及GLONASS 频间偏差处理等，同时也增加了新的算法让其更加适用于精密单点定位。GAMP 软件结构或精密单点定位处理流程如图1所示，图中EOP、DCB 文件分别为地球定向参数和差分码偏差文件，atx 文件为卫星及接收机天线相位信息文件，ZTD、AMB 和sTEC 分别表示对流层天顶总延迟、载波相位模糊度和倾斜电离层电子浓度总含量。

图1 GAMP 软件精密单点定位处理流程

GAMP 进行精密单点定位处理具有较高的定位精度，且定位稳定性较好，同时也配备了配置文件进行PPP 处理策略的选择，对于从事PPP 研究人员来说是一个更好的选择。不过从图1 中可以看出，GAMP 适用于事后精密单点定位，其处理数据来源于观测、导航、精密星历文件等，所以需要增加实时数据接收及处理模块让其适用于实时PPP 定位解算，更加偏向于实时化应用。

2 实时PPP 软件模块搭建

基于GAMP 软件，本研究需要搭建实时数据接收及处理模块来实现实时PPP 解算。首先要确定实时数据来源，本文的实时PPP 软件实时数据来源有两种，分别为基于NTRIP 协议网络播发的实时数据以及接收机串口数据。根据实验或实际应用需求对观测数据来源进行选择，并且可以设置合适的数据采样间隔。软件实现结构如图2 所示。

图2 实时PPP 软件实现结构

对于串口输入以及UBLOX 译码，这里不详细阐述[9]，这是一种固定的编译码格式，设定好串口波特率等参数来接收UBLOX 数据进行译码。这里UBLOX 模块结合天线外部输入提供了卫星导航以及观测数据，为了验证实时PPP 软件的性能，也可以使用网络播发的各个测站的观测数据来进行测试，这些数据来源是基于NTRIP 协议。卫星导航、观测以及SSR 数据等在传输中以RTCM 格式形成数据源，需要接收来自转播中心的实时数据然后进行RTCM 格式译码获得所需要的信息。RTCM 格式主要是由一系列电文结构和电文内容构成[10]，在实时处理时需要先匹配同步码，获取到数据长度，据此来提取整个数据段然后进行24 位CRC 校验，校验成功后获取对应的信息编号进行实时数据的提取。

很显然，实时PPP 处理的数据并不是单一来源，所以需要进行多线程处理，前文中提到实时PPP 的稳定性除了接收的卫星观测数据质量的好坏，很大一部分来自于SSR 信息的稳定，因此采用组合SSR 信息的方式尽量减小由单一SSR 数据源长时间中断而带来的影响[11]，详细操作流程如图3 所示。

图3 组合SSR 挂载点操作流程

不同SSR 挂载点数据更新频率不一样，大部分为5 s的更新周期，获得SSR 改正数后结合广播星历可以计算出精密单点单位所需要的卫星精密轨道及钟差。计算步骤如下所示[12]：

(1) 计算出t时刻RAC (Radial，Along -track and Cross-track)坐标下的改正数：

其中，t 为卫星轨道及钟差计算时刻，t0为SSR 数据更新时 刻，δOr、δOa和δOc分别为轨道改正数径、切和法方向分量，分别为轨道改正数径、切和法方向时间变化率。

(2)将RAC 坐标下改正数转化为地心地固(Earth-Centered-Earth Fixed，ECEF)坐标下改正数：

其中，r 和v 分别为广播星历所计算出的卫星位置及速度，R为转换矩阵，δx、δy 和δz 分别为轨道改正数x、y和z 方向分量。

(3)计算卫星精密轨道：

其中，Xprec、Yprec和Zprec为卫星精密轨道三维坐标，Xbrd、Ybrd和Zbrd为广播星历计算出的卫星轨道三维坐标。

(4)计算卫星精密钟差：

其中，δC 为实时钟差改正量，C0为SSR 改正数中钟差改正量，C1和C2分别为钟差一阶及二阶钟差变化量，dtprec为卫星精密钟差，dtbrd为广播星历卫星钟差，c 为光速。整个计算过程需要注意SSR 改正数与广播星历数据版本号(Issue Of Data，IOD)的匹配，GPS 和GALILEO 的IOD匹配可以直接进行，BDS 和GLONASS 需要进行一定的变换[13]。

最后将实时接收的数据经过预处理后再进入精密单点定位的处理流程。数据预处理中包括对粗差探测与剔除、钟跳探测与修复以及周跳探测，周跳探测采用比较通用的Geometry-free 和Melbourne-Wübbena 组合探测方式[14]。在进行精密单点定位处理时若因观测量不足或是SSR 改正数缺失则输出标准单点定位值。程序停止的条件除了有定位时长设定之外，当某一数据源长时间未接收新数据或是数据源连接失败都可以终止整个程序。另外，对原先GAMP 使用文件形式对解算策略进行配置的方式进行了改变，统一到程序中进行配置。对一些只能用于事后PPP 的改正文件进行了改变或去除，如差分码偏差(Differential Code Bias，DCB)文件在实时PPP 软件中改为使用SSR 的码偏差数据(部分SSR 挂载点会播发绝对码偏差数据)，但是天线相位中心改正文件保留不变，若是可提供接收机天线型号及相关参数，则可进行天线相位中心偏差及变化改正。软件还保留有实时PPP模糊度固定模块[15]，但目前固定率未能满足要求，所以实际应用中不会使用该模块。

3 IGS 测站定位性能分析

通过NTRIP 协议可以接收到部分IGS 测站通过网络播发的实时观测数据，观测数据内容、采样间隔、卫星系统以及测站相关信息可通过转播中心数据源表进行查询。预先设定好实时PPP 软件的解算策略即观测数据采样间隔为1 s，使用GPS/GLONASS 双系统双频消电离层组合的方式进行PPP 定位解算。在2021-01-07～2021-01-12，随机对ABMF、CAS1、LMMF 和ZIM2 4 个测站进行实时静态精密单点定位，定位时长为5 h，三维方向的定位性能如表1 所示(实时PPP 三维方向定位精度及收敛时间)。

表1 4 测站定位性能表

4 测站5 h 最终的定位精度都可以达到厘米级，特别是LMMF 测站，N 方向可以达到毫米级。不过收敛时间有很大差异，CAS1 和ZIM2 测站收敛时间在1 h 左右，而ABMF 测站收敛时间为1.62 h，部分原因来自于各个测站位置不同，可观测卫星数量级卫星构型不同。同时，从表1 中可以看出，ZIM2 测站历元数明显小于其他3个测站(4 个测站历元数据均少于18 000)，这说明在随机选择测站进行实验时，因为实时数据流通过网络进行传播，网络或是挂载点稳定性无法得到保障，所以会出现信号中断的情况。网络或数据挂载点的不稳定会影响PPP 的收敛速度，实时PPP 的稳定性因此也会出现波动。如果没有出现长时间的信号中断，实时PPP 的定位精度可以达到预期目标。

4 UBLOX-F9T 定位性能分析

为了验证实时PPP 处理软件在实际应用中功能是否稳定，采用UBLOX-F9T 模块进行实时静/动态PPP 测试。SSR 挂载点采用组合SSR 形式(CLK93 和SSRA00CAS0，两挂载点转播中心不同，数据有效周期设置为90 s)，广播星历以及卫星观测数据来自于UBLOX-F9T 模块的接收。

测试分为静态模式和动态模式，静态模式采用单GPS、GPS+GALILEO 和GPS+GALILEO+BDS 组合方式进行定位解算，每种方式进行3 次重复实验(实验时间不同)，每次持续时间均为5 h，3 种方式平均定位收敛时间以及定位精度如图4 所示。

图4 静态实时PPP 收敛时间及定位精度

不同GNSS 组合方式静态实时PPP 定位收敛时间及精度不同，与单GPS 系统相比，GPS+GALILEO 和GPS+GALILEO+BDS 系统组合在收敛时间上都有所加快，其中GPS+GALILEO 组合PPP 收敛时间加快11.20%，GPS+GALILEO+BDS 组合PPP 收敛时间加快48.60%。因为BDS 实时改正数精度的限制，所以在定位精度上逊色于单GPS 静态PPP。总体上3 种方式静态实时PPP 定位精度都在厘米级，收敛时间最快约为40 min，同时多系统组合可加快PPP 定位收敛，GALILEO 系统的加入也可提高静态PPP 定位精度。

动态实时PPP 采用GPS+GALILEO+BDS 组合方式进行定位解算，进行3 次重复实验，每次持续时间为5 h，定位效果如图5 所示。

图5 动态实时PPP 偏差

动态精密单点定位对于测量值和卫星轨道和钟差质量要求较高，应用所设计的实时PPP 软件通过UBLOX模块接收数据进行实时动态PPP 解算，定位精度可达到分米级，部分时间段可达厘米级，整体来看满足实时动态PPP 定位需求。从图5 中可以看出，动态PPP 定位过程高程方向有个别定位跳动的情况，其中测试1 出现定位偏离以及再收敛的过程，原因可能来自于所接收的实时改正数钟差会出现跳动和异常值，或是SSR 挂载点切换时带来的钟差异常。后期需要对SSR 改正数进行历元间滤波，以减小钟差异常所带来的影响。

5 结论

GAMP 软件在处理事后PPP 上性能稳定优异，但无法应用于实时PPP 解算，因此本文通过对实时PPP 算法模型及系统的搭建增加了实时数据的接收及处理模块，实现了事后PPP 处理向实时PPP 解算的转化。通过IGS测站以及UBLOX 模块接收数据进行实时PPP 实验测试发现，静态模式下实时PPP 定位精度可达厘米级，动态模式下可达到分米级，满足了实际工程化应用。不过在实验中也发现静态PPP 收敛时间过长以及动态PPP 会因SSR 改正数异常问题定位出现偏离，后期会优化PPP算法，同时进行不同分析中心SSR 改正数历元间滤波算法研究，增加组合SSR 滤波模块，减少挂载点切换时对动态PPP 所带来的影响。