原文作者为rtklibexplorer，写作时间为2018年，非最近更新文章。原文地址： using-ssr-corrections-with-rtklib-for-ppp-solutions这里只是做翻译，方便自己查看记录。
If you have been following recent announcements in precision GNSS, you may have been hearing a lot about SSR (State Space Representation). SwiftNav recently announced their Skylark corrections service, and u-blox announced a partnership with Sapcorda to provide correction service for their upcoming F9 receivers. Both of these services are based on SSR corrections.
如果您最近一直在关注精密 GNSS 方面的公告的话，您可能已经听到了很多关于 状态空间域SSR (State Space Representation）的消息。SwiftNav 最近宣布了他们的 Skylark 校正服务，u-blox 宣布与 Sapcorda 合作，为他们即将推出的 F9接收机系列提供校正服务。这两项服务都是基于安全部门改正。
So, what is SSR? Very briefly, it refers to the form of the corrections. In traditional RTK with physical base stations or virtual reference stations (VRS), the corrections come in the form of observations in which all of the different error source are lumped together as part of the observation. This is referred to as OSR (Observation Space Representation). In SSR corrections, the different error source (satellite clocks, satellite orbits, satellite signal biases, ionospheric delay, and tropospheric delay) are modeled and distributed separately. There are many advantages to this form but what seems to be driving industry towards it now is that it allows the current VRS model where each user requires a unique data stream with observations tailored for their location to be replaced with a single universal stream that can be used by all observers. This is a requirement if the technology is going to be adopted for the mass-market automotive industry for self-driving cars, since it is not practical to provide every car with it’s own data stream.
那么，什么是SSR呢？简而言之，它指的是一种校正服务形式。在传统的基于物理基站或虚拟参考站的 RTK 中，校正是以观测值的形式出现，其中所有不同的误差源集中在一起作为观测值的一部分。这被称为 观测空间域 (Observation Space Representation，OSR)。在 SSR 修正中，对不同的误差源(卫星时钟、卫星轨道、卫星信号偏差、电离层延迟和对流层延迟)分别建模。这种形式有很多优点，但是现在推动行业发展的是，在当前的 VRS 模型中，每个使用VRS的用户会根据自身的位置获取一个独特的数据流，而未来，这将被一个可供所有用户使用的单一通用流所取代。由于SSR服务不需要为每辆车提供特定的数据流，所有汽车都可以使用一样数据流，所以在不久的将来，这项技术将可能被拥有广大市场的自动驾驶汽车行业所采用。
For more detailed information on SSR, Geo++ has a one page summary here and IGS has an 18 minute video presentation on the topic here. Both are excellent.
要了解更多关于 SSR 的详细信息，Geo + + 在这里有一页总结 ，IGS 在这里有一个18分钟的主题视频演示.。两者都很精彩。
Below is an image I borrowed from the IGS presentation which shows the flexibility of the SSR format. It is intended to show how the same SSR data stream can be used globally for PPP quality corrections and also regionally for RTK quality corrections but it is also a good visual for understanding the message details I describe below.
下面是我从 IGS 演讲中借来的一张图片，它展示了 SSR 格式的灵活性。它旨在说明如何在全球范围内使用相同的SSR数据流进行PPP改正，以及在区域范围内进行 RTK 校正，同时它也能很直观的帮助我们理解我接下来将要描述的内容。
The RTCM standards committee is still in the process of finalizing the messages used to send the different correction components. They have split the work into three phases. Phase 1 includes the satellite clock, orbit, and code biases. Phase 2 includes satellite phase biases and vertical ionosphere corrections, and phase 3 includes ionospheric slant corrections and tropospheric corrections.
RTCM 标准委员会最近仍努力就发送不同的改正信息达成一致。他们把这项工作分成三个阶段。第一阶段包括卫星时钟、轨道和伪距偏差。第2阶段包括卫星相位偏差和天顶电离层改正，第3阶段包括电离层倾斜校正和对流层改正。
There are several real-time SSR streams accessible for free today. Unlike the paid services, they do not contain enough detailed regional atmospheric corrections to use as a replacement for a VRS base but they can easily be used for static PPP solutions.
现在有几个实时的 SSR 数据流可以免费访问。与付费服务不同的是，它们没有包含足够详细的区域大气校正，无法用作 VRS 基地的替代品，但可以很容易地用于静态 PPP 解算。
I used the CLK93 stream from CNES for an experiment to test how well RTKLIB handled the SSR corrections. It includes the Phase 1 and Phase 2 RTCM messages but not the Phase 3 messages. Here is the format of the the messages in the CLK93 data stream:
我使用来自 CNES 的 CLK93数据流进行了一个实验以测试 RTKLIB 如何处理 SSR 改正信息。它包括第1阶段和第2阶段 的RTCM 消息，但不包括第3阶段消息。下图是 CLK93数据流中消息的格式:
You can register for free access to the CLK93 (and other) streams from any of these locations:
你可从以下任何一个地点免费登记使用 CLK93(及其他)资数据流:
- 美国:CDDIS and 及IGS
- 欧洲:https://register.rtcm-ntrip.org/cgi-bin/registration.cgi
- 中国:武大导航实验室 ， 中科院上海天文台
- 澳大利亚:Geoscience Australia
Unfortunately, RTKLIB currently only supports the Phase 1 RTCM messages and even this is not complete in the release version. I have gone through the code and made a few changes to make the Phase 1 SSR functional and have checked those changes into the demo5 Github repository. I also added some code to handle the mixed L2 and L2C observations from the ComNav and Tersus receivers. After a little more testing I plan to release this code into the demo5 executables, hopefully in the next week or two.
不幸的是，RTKLIB 目前只支持第1Phase 的 RTCM 消息，即使在发行版中也不完整。我检查了代码并做了一些修改，使得第1帧的 SSR 信息能正常使用，并将这些修改的代码同步到了 demo5 Github 存储库中。我还添加了一些代码来处理来自 ComNav 和 Tersus 接收器的混合 L2和 L2C 观测值。经过一些更多的测试后，我计划将这段代码发布到 demo5可执行文件中，希望在未来一两周内完成。
With only phase 1 measurements, the RTKLIB PPP solutions will work much better with dual frequency receivers than with single frequency receivers. This is because single frequency receivers require ionospheric corrections for longer baselines. For this reason, I did not bother with collecting any single frequency data. Instead, I collected both L1/L2C data with a Swiftnav Piksi Multi receiver and L1/L2/L2C data with a ComNav K708 receiver and a Tersus BX306 receiver.
仅使用第一帧的观测值信息，RTKLIB的双频 PPP 解会好于单频PPP解。因为对于单频接收机来说，处理长一点的基线数据时需要店电离层改正信息（翻译注：而双频通过无电离层组合可以比较方便的削弱电离层的影响）。出于这个原因，我没有费心去收集任何单一频率的数据。相反，我用 Swiftnav Piksi Multi接收器收集 L1/L2C 数据，用 ComNav K708接收器和 Tersus BX306接收器收集 L1/L2/L2C 数据。
RTKLIB is usually used to calculate PPP solutions without SSR corrections but this requires downloading multiple correction files for orbital errors, clock errors, and code bias errors and it is usually done with post-processing rather than real-time, after the corrections are available. With SSR, the process is simpler because the solution can be done real-time and there is no need to download any additional files. It does, however, require access to the internet to receive the real-time SSR data stream from an NTRIP caster. The solution can be calculated real-time or the SSR corrections and receiver observation streams can be recorded and the solution post-processed.
RTKLIB 通常使用SSR改正值来获取PPP解，但这需要下载多个修正文件，用于修正轨道误差、钟误差和伪距偏差，而且通常是在拿到改正信息后进行后处理，而不是实时处理。直接使用 SSR信息会让这个过程更简单，因为可以实时获取解算结果，而且不需要下载任何其他文件。当然了，它需要通过互联网从 NTRIP 服务器那里接收实时的 SSR 数据流。可以实时进行解算得到解算结果，也可以将实时的数据流保存到本地文件进行事后处理。
To enable the use of SSR corrections in RTKLIB, you need to set the “Satellite Ephemeris/Clock (pos1-sateph) input parameter to either “Broadcast+SSR APC” or “Broadcast+SSR CoM”. Note that CoM stands for Center of Mass and APC for Antenna Phase Center. They refer to the reference point for the corrections. The CLK93 corrections are based on antenna phase centers.
为了能够在 RTKLIB 使用SSR改正，你需要把** Satellite Ephemeris/Clock (pos1-sateph)**输入参数设定为「Broadcast+SSR APC」或「Broadcast+SSR CoM」。注意 ，这里CoM 表示质心，APC 代表天线相位中心。它们代表不同的修正参考点。CLK93改正是基于天线相位中心的。
To generate my PPP solution I set the solution mode to “PPP-Static”, ephemeris/clock (pos1-sateph) to “brdc+ssrapc”, ionosphere correction (pos1-ionopt) to “dual-freq”, and troposphere correction (pos1-tropopt) to “est-ztd”. I also enabled most of the other PPP options including earth tides, satellite PCVs, receiver PCVs, phase windup, and eclipse rejection.
为了生成我的 PPP 解决方案，我将解决方案模式设置为“ PPP-static”，ephemeris/clock (pos1-sateph)设置为“ brdc + ssrapc”，ionosphere correction (pos1-ionopt)设置为“ dual-freq”，troposphere correction (pos1-tropopt)设置为“ est-ztd”。我还启用了大多数其他 PPP 选项，包括地球潮汐、卫星 PCVs、接收器 PCVs、相位提升和日食拒绝。
RTKLIB PPP solutions don’t support ambiguity resolution so the ambiguity resolution settings are ignored. I specified the satellite antenna file as “ngs14.atx” which is the standard antenna correction file and is available as part of the demo5 executable package. I also needed to include the CLK93 data stream as one of the inputs in addition to the receiver observations (and navigation file if post-processing).
RTKLIB PPP 解不支持模糊度固定，因此模糊度固定的设置项可以忽略掉。我将卫星天线文件指定为“ ngs14.atx”，这是标准的天线校正文件，可作为 demo5可执行包的一部分使用。我还需要将 CLK93数据流作为接收机观测值(如果是后期处理，还需要导航文件)之外的一个输入。
I collected a couple hundred hours of observations with the SwiftNav receiver connected to a ComNav AT-330 antenna on my roof with moderately good sky visibility. I then ran many four hour static solutions over randomly selected data windows. I also collected a small amount of raw data from a ComNav K708 receiver and a Tersus BX306 receiver.
我用 SwiftNav 接收机收集了几百个小时的观测数据，这个接收机连接和我屋顶上的 ComNav AT-330天线相连，天空能见度还算不错。然后我在随机选择的数据窗口采集了很多组四个小时的解。同时，我也从 ComNav K708接收机和 Tersus BX306接收机收集了少量的原始数据。
Below is a typical 12 hour static solution for a SwiftNav and a ComNav receiver. The SwiftNav solution is in green and the ComNav solution is in purple. Zero in these plots represents an online PPP solution from CSRS from data collected over a month earlier. In this particular example, the SwiftNav solution is slightly better but this was not always the case.
下图是 SwiftNav 和 ComNav 接收机12小时静态解结果。绿色表示SwiftNav 解，紫色表示ComNav解。图表中的0代表使用一个月前收集的数据通过CSRS在线PPP服务 解算得到的在线 PPP 解。在这个特定的例子中，SwiftNav 解稍微好一些，但是情况并不总是这样。
Here is a shorter data set from a Tersus BX306 receiver. With the relatively small amount of Tersus and ComNav data I collected, I did not notice any differences in convergence rates or final accuracy between any of the three receivers.
下面是来自 Tersus BX306接收机的一个较短的数据集。由于我收集的 Tersus 和 ComNav 数据相对较少，我没有注意到三个接收器之间在收敛速度或最终精度方面的任何差异。
The solutions generally all converged to less than 6 cm of error in each axis after 4 hours with one or two minor exceptions that seemed to involve small anomalies at the day boundary. Since the RTKLIB PPP solutions don’t include ambiguity resolution they do take longer to converge but the eventual accuracy should be similar.
一般来说，4小时后每组解的每个轴都会收敛到小于6厘米的误差，但涉及到两天交接的地方时会有一两个小的例外。由于 RTKLIB PPP 解不包括模糊度固定，它们确实需要更长的时间收敛，但最终的准确性应该是相似的。
I’ve uploaded some of the raw observation data for the different receivers and the CLK93 data stream as well as the config file that I used for the solution here.
我已经上传了一些不同接收器和 CLK93数据流的原始观测数据，以及我在这里用于解决方案的配置文件。
This seems like a good start and I hope that RTKLIB will support phase 2 and phase 3 corrections in the future.
这似乎是一个良好的开端，我希望 RTKLIB 将在未来支持阶段2和阶段3的修正。