企业官网建设流程全解析

简介：这是一份面向测绘、卫星导航与空间大地测量从业者的 GNSS 数据质量检核资源，围绕 G-Nut/Anubis 软件整理而成。该软件支持 RINEX 3 格式，可对 GPS、BDS、GLONASS、Galileo 等系统的观测数据进行质量检核与分析，并将结果可视化绘图，适合需要评估测站数据质量、预处理 GNSS 观测数据的工程师与科研人员。资源包约 11.6MB，主要包含 Anubis 安装程序（含 Windows 64 位静态版）、配置文件编辑与使用简介、两篇中文应用文献，以及 Chart-Gnuplot、plot_Anubis 等绘图辅助工具，基本覆盖了从安装配置到结果出图的全流程。尤其适合希望快速上手、免去在公开渠道零散查找资料的读者，下载后即可对照说明完成数据质量检核与分析工作。目前已有 2794 人浏览学习，实用价值已得到初步验证。

1. GNSS 数据质量检核软件 anubis：数据不体检，解算白忙活

GNSS 数据质量检核软件 anubis，说白了就是给你手里的 RINEX 观测文件做一次“体检”。跑高精度定位之前，我最怕的不是参数调不对，而是观测文件本身有问题——天线没固定稳、接收机中途重启、低仰角卫星多路径暴涨，这些坑在解算阶段往往只表现为残差异常，回头排查特别费时间。用 anubis 在解算前把多路径 RMS、信噪比、周跳、数据完整率一次性打出来，数据能不能用、哪些时段该截掉、哪颗卫星质量太差，一眼就能判断。它只有命令行界面，没有图形窗口，但对做连续运行参考站数据审核、大规模观测数据预处理的人而言，这种不折腾的检核方式反而最省事。下面从它在算些什么、怎么编译运行、参数怎么调、会踩哪些坑，到批处理流程，按我的实际习惯完整讲一遍。

2. anubis 检核逻辑拆解：RINEX 解析、多路径与周跳统计

2.1 RINEX 解析与多系统归组：一切统计的前提

anubis 的第一步是把 RINEX 文件按头和体两部分拆开。头文件里记录版本号、观测时刻、天线类型、观测值类型列表，正文则是逐历元逐卫星的观测数据。解析环节最容易出问题的地方是版本判断：RINEX 2 和 RINEX 3 的格式差异很大，观测值类型从双字符变为三字符，卫星编号规则也不一样。anubis 读文件时不是看后缀名，而是看头记录里RINEX VERSION / TYPE这一行的实际内容，所以你把 RINEX 3 文件改名成.obs或者.rnx都没用，版本字段写错照样解析失败。

解析完成后，数据会按“系统 + 频率 + 卫星编号”重新归组。GPS、GLONASS、Galileo、BDS 各有各的频率组合，比如 GPS 有 L1/L2/L5，BDS 有 B1I/B3I/B1C，anubis 会把同一颗卫星的伪距和载波相位放到一组，后续统计才能做同组比对。如果你只拿观测文件而不给导航文件，程序也能跑，但算不出卫星位置和仰角，报告里仰角分组的栏目就缺数据。我一般会把观测文件和同名导航文件放进同一目录，把整个目录丢给 anubis，这样它能把仰角、方位角一并算出来，后面按仰角筛选低质量数据时才有依据。

解析还有一个容易被忽略的点：一个 RINEX 文件里面可能包含多个观测时段，比如接收机重启后继续记录。anubis 会按时间连续性把数据切成多个观测段，分别统计每段的质量指标。所以如果报告里同一个站点出现多段记录，先别急着怀疑程序出了问题，多半是原始文件确实存在中断。

2.2 多路径与信噪比：最常用的两个健康度指标

多路径是 GNSS 数据质量检核里最核心的指标。它无法直接观测，只能通过双频伪距和载波相位的组合把几何项消掉，剩下的就是多路径和伪距噪声。经典做法是 MP1 和 MP2 组合，公式思路如下：

MP1 = P1 - (f1² + f2²) / (f1² - f2²) * λ1 * L1 + 2 * f2² / (f1² - f2²) * λ2 * L2

这个式子把伪距 P1 与两个频率的载波相位 L1、L2 组合在一起，消掉了站星距离和大部分电离层延迟，剩下的主要是 L1 频点上的多路径效应和伪距噪声。MP2 同理，只是把组合角度换到 L2。anubis 按卫星、按历元逐点计算 MP 值，最后输出 RMS 和均值。实际使用中，MP1/MP2 的 RMS 如果长期超过 0.5 米，就要怀疑站点周围反射物太多，或者天线相位中心不稳定。

信噪比 SNR 是多路径之外的另一张照妖镜。低仰角卫星的 SNR 普遍偏低，但如果某颗卫星在仰角并不低的时候 SNR 明显低于同批次其他卫星，说明信号环境有问题。anubis 通常把 SNR 按 5 度一档的仰角区间做平均，看某个仰角区间里 SNR 是否出现断崖式下降。我习惯先看 MP 值，再看 SNR，两个指标同时异常的卫星基本可以判定为“问题卫星”，解算时直接排除。

2.3 周跳、完整率与报告输出

周跳检测用的是无几何组合，也就是 L1 和 L2 载波相位的差分组合。电离层变化在短时间内是平滑的，所以无几何组合在相邻历元之间的变化应当很小；如果某一历元突然出现跳变，多半是载波相位发生了周跳。anubis 会对每颗卫星的每个连续观测段做这一检测，统计每个观测段发生的周跳次数。周跳越多，说明数据断点越多，解算时模糊度重新收敛的概率就越大。

数据完整率则反映另一个问题：理论上有 8640 个历元，实际记录到 8000 个，完整率就是 92.6%。完整率低的文件不一定不能解，但缺失时段如果集中在某颗卫星的低仰角段，会直接影响该卫星的可用性。anubis 的输出文件一般分成 txt、html、xml 三种，txt 最方便脚本处理，html 适合快速浏览，xml 可以对接后续程序。核心指标汇总如下：

3. 从 anubis.zip 到可用命令：编译安装与最小运行示例

3.1 解压、编译与自检

anubis 源码包通常是一个 zip，解压后里面是源码和配套的配置文件模板。拿到压缩包后第一步是解压并确认目录结构：

unzip anubis.zip ls -la anubis*/ # 先看清解压出来的目录名和内容 cd anubis*/ # 进入源码目录，目录名以实际解压结果为准

解压后先别急着 make，看一眼目录下有没有README或Makefile。有 Makefile 就直接编译，没有就翻一下 README 里推荐的构建方式。常见做法是直接执行 make：

make ./anubis -h

第一行 make 会调用系统里的 C++ 编译器把源码编成可执行文件。如果系统里没装编译工具链，make 会直接报g++: command not found或者make: command not found，这时候先把系统包里的 C++ 开发组件装好，再重新 make。编译完成后会在当前目录生成一个名为anubis的可执行文件，./anubis -h用来打印帮助信息，这一步非常关键——不同版本对命令行参数的支持略有差别，先看帮助能避免后面用错参数。

提示：Windows 下如果你不想自己编译，大多数发布包会附带已经编译好的可执行文件，直接进对应子目录找即可。Linux 下编译完若提示权限不够，先执行chmod +x anubis。

3.2 最小配置文件：三行就够跑

anubis 不像普通软件那样靠一堆启动参数工作，它的核心配置在配置文件里。我不会一上来就把所有配置项写满，而是先给一个最小可跑配置：

<anubis> <process> <interval>300</interval> <elevation>10</elevation> <systems>GPS+GLO+GAL+BDS</systems> </process> <output> <directory>qc</directory> <prefix>q</prefix> <format>T</format> </output> </anubis>

interval 是统计间隔，单位秒，300 秒表示每隔 5 分钟输出一段统计结果；elevation 是截止仰角，10 度以下的卫星直接不进统计；systems 决定要统计哪些系统，GPS+GLO+GAL+BDS表示 GPS、GLONASS、Galileo、BDS 全算；output 部分指定输出目录、文件名前缀和格式，T 代表 txt，需要 html 或 xml 就写成TH或TX。

这个配置我一般命名为anubis.cfg，和观测数据目录放在同一个工作目录下。如果程序报“配置文件里某行不认识”，大概率是当前版本不支持某个字段，删掉那一行再跑即可，不影响整体检核。

3.3 最小运行命令与输出文件

配置文件就位后，运行命令非常短：

anubis -c anubis.cfg -r ./obs

-c指定配置文件路径，-r指定 RINEX 观测文件或包含观测文件的目录。anubis 会扫描目录下所有匹配的观测文件，逐个检核。如果当前版本不支持-r目录这种写法，先执行./anubis -h看帮助里对应的参数名，再按当前版本调整。

运行结束后，去配置里指定的qc目录看输出。文件名类似q_观测文件名.txt，里面包含每个观测段的统计结果。第一次跑通后我建议打开 txt 文件，对照第 2 章的指标表看一遍，确认理解报告里每个字段的含义，再开始调参数。命令行工具的好处就在这里：它把每个指标都落到文本里，查找、对比、归档都很直接。

4. anubis 配置参数调优：让质量报告贴合你的观测场景

4.1 interval、elevation、snrmin 三个基础参数怎么定

interval 直接影响报告的粒度。设成 300 秒，每 5 分钟一个统计段，适合看整体质量趋势；设成 30 秒，统计段更密，能定位到具体是哪几分钟出现异常。但 interval 过小会导致每个统计段里的历元数太少，MP 值和 SNR 的统计意义变弱，反而看不出问题。我的经验是：静态长时段数据用 300 到 600 秒，动态数据或短时段采集用 30 到 60 秒，先粗后细，发现异常段再缩小间隔单独复检。

elevation 截止仰角决定了低仰角卫星是否进入统计。默认 10 度是一个比较平衡的取值，既能保留低仰角卫星的观测信息，又不会让多路径噪声主导统计结果。如果测站周围环境很差，比如山谷、城市峡谷，可以把截止仰角抬到 15 度；如果做高精度静态解算，建议保持在 10 度以下，让报告反映出真实的多路径水平，而不是人为掩盖问题。

snrmin 是一个容易被忽视的参数。它表示参与统计的最低信噪比，低于这个值的观测值直接剔除。有人会把它设得很高，比如 40 dBHz，这样报告“很好看”，但代价是掩盖了弱信号时段的问题。我更建议保持默认或不设，让原始数据自己说话。低 SNR 数据可以在解算阶段剔除，但质量检核阶段应当保留，否则你看不到问题在哪个时段发生。

4.2 静态长时段观测和动态短时段数据，参数怎么换

不同场景下的参数组合差异很大，下面是我常用的两组配置思路：

静态站点的数据量大，统计段太长看不出细节，太短又会产生大量噪声。300 秒是平衡点，配合 10 度截止仰角，能同时覆盖 GPS 和 BDS 的低仰角卫星。动态数据则相反，采集时间短，历元少，必须用 30 秒的小间隔才能把有效统计段凑出来。截止仰角抬到 15 度是因为动态环境多路径更复杂，低仰角数据往往不可靠，直接不进统计反而更干净。

4.3 用阈值定位异常时段的实用方法

anubis 报告不只是给你一堆数字，它还能通过阈值把异常标出来。实际做法是：先跑一遍全时段检核，拿到各时段 MP、SNR、完整率的基线值；然后把明显偏离基线的时段挑出来，单独设更小的 interval 重新检核。举个例子，某站全天 MP1 均值 0.28 米，但中午 12 点到 13 点之间某颗卫星的 MP1 突然涨到 0.7 米以上，这种突变多半是附近有临时遮挡物，或者天线被鸟群、枝叶短暂遮挡。这时候不是把整站数据删掉，而是把该时段截掉，其余时段照常参与解算。

阈值本身没有绝对标准，因为不同天线、不同接收机、不同环境的基线值差异很大。我习惯用“横向对比”代替固定阈值：同一个测站不同日期之间对比，或者同一批次不同测站之间对比。如果某个测站的 MP 值显著高于同期其他测站，先检查天线和架设环境，再决定是否调整处理策略。

5. anubis 使用常见问题与避坑记录：现象、原因与处理

5.1 解析报错，但不是文件坏了

现象：运行 anubis 后终端提示RINEX version not supported或者header parsing failed，看起来像是观测文件已经损坏。

原因：多数情况不是文件坏了，而是文件的版本字段和后缀名不一致。比如明明是 RINEX 3 的内容，文件名却写成.obs，或者压缩传输过程中头记录的RINEX VERSION / TYPE行被截断。

解决：先用任意文本编辑器打开文件前 5 行，确认版本行内容。如果版本字段本身正常，只是后缀名不匹配，把后缀改成.rnx再跑；如果版本行缺字符，找原始数据重新导出。还有一个常用技巧：把观测文件和导航文件放在同一目录，让 anubis 直接扫描目录，避免单文件路径问题。

5.2 多系统数据报告里只有 GPS，GLONASS 和 BDS 全不见了

现象：RINEX 文件里明明有多个系统的卫星，但报告只统计了 GPS，其他系统的行数为零。

原因：配置里systems字段没写全，或者只写了 GPS。另外，RINEX 3 文件的观测值类型列表里如果没有相应系统的观测值，解析时会被跳过。

解决：检查配置文件里的systems字段，确保写成GPS+GLO+GAL+BDS，需要 QZSS 或其他系统就继续追加。改完配置重新跑一遍。如果配置没问题但仍缺系统，打开 RINEX 文件头部的SYS / OBS TYPES字段，确认该系统的观测值确实存在。有些接收机默认不记录 BDS 的载波相位，只记录伪距，这种情况无论怎么配置都出不了 BDS 的完整统计。

5.3 周跳数量异常多，先别急着怪软件

现象：报告显示某颗卫星周跳次数非常多，几乎每个观测段都有 3 次以上跳变。

原因：可能是接收机重启、天线遮挡、信号中断，也可能是这个频点的数据本身不稳定。还有一种常见原因是统计间隔设得太小，比如 30 秒采样下用 5 秒统计间隔，历元间电离层变化本身就会造成误判。

解决：先把 interval 恢复到 300 秒，排除统计粒度造成的假周跳。如果周跳仍然很多，单独导出该卫星在异常时段的原始数据，看看信号强度是否同时下跌。同时看其他卫星在相同时段是否也跳——如果所有卫星一起跳，基本可以断定是接收机或电源问题；只有单颗卫星跳，则从遮挡和多路径方向排查。

5.4 html 报告空白或打不开

现象：检核正常结束，txt 报告内容完整，但生成的 html 文件在浏览器里打开是空白页。

原因：多数情况下不是 anubis 生成失败，而是输出路径或文件前缀里带了中文字符、空格，导致 html 内部引用的样式或数据文件路径解析失败。另一个常见原因是杀毒软件拦了 html 里的脚本内容。

解决：把配置里的directory和prefix改成纯英文路径，不要带空格，重新跑一遍。日常使用我建议只保留 txt 报告，html 需要时才生成，省得被这类问题干扰。

5.5 编译失败：环境问题占大多数

现象：make报错，常见的有g++: command not found、make: command not found、或者链接阶段报找不到某个头文件。

原因：系统里没有 C++ 编译工具链，或者编译器版本过旧，不兼容源码里的新语法。这类问题与 anubis 本身无关，属于环境配置问题。

解决：先安装系统对应的编译组件集合，安装后重试 make。如果安装后仍报头文件缺失，检查系统里是否缺基础开发库，补齐后再编译。实在不想折腾环境，就直接找发布页里现成的可执行文件，省去编译这一步。

注意：运行 anubis 前养成先./anubis -h看帮助的习惯。不同版本参数名可能有差异，先确认-c、-r在当前版本里确实存在，能少踩很多坑。

6. 把 anubis 检核做成批量流水线：多文件处理小技巧

单个文件检核跑通之后，日常使用一定会遇到批量处理的需求。几十个测站的观测文件一个个手动敲命令不现实，我的做法是用循环脚本把检核、汇总、不合格标记一次做完。

for obs in ./raw/*.rnx; do anubis -c anubis.cfg -r "$obs" || echo "$obs 检核失败" done

这个循环会把raw目录下所有.rnx文件逐条送进 anubis。|| echo的作用是当某个文件检核失败时把文件名打出来，避免程序中途停住后你还要回头找是哪个文件出了问题。处理完后再做一次结果汇总：

for rep in ./qc/q_*.txt; do name=$(basename "$rep") mp1=$(grep -m1 "MP1" "$rep" | awk '{print $2}') echo "$name $mp1" done

这段脚本的作用是把每个报告文件里的 MP1 值抽出来，按文件名打印成一行。注意这里grep和awk的字段位置只是示例，不同版本的 anubis 报告格式略有差别，你要先打开一个 txt 报告，确认 MP1 所在行的实际字段位置，再调整awk里的列号。抽出来的汇总结果可以直接重定向到 csv 文件，再导入表格工具做趋势对比。

批量流水线里我还会加一道自动筛选：对完整率低于 90% 的文件单独标记，不直接删除，而是挪到bad目录：

if [ "$rate" -lt 90 ]; then mv "$obs" ./bad/ fi

这个习惯救过我很多次。质量检核的目的不是把所有难看的数据删掉，而是把问题数据单独隔离，让后续解算不会悄悄被污染。自动筛选之后，每一轮数据处理只花几分钟时间，但能换来全流程的稳定。我第一次用 anubis 时也嫌麻烦，觉得多一道工序浪费时间，用顺手之后才发现，数据质量检核才是最不该省的那一步。希望这些命令和踩坑记录能帮到正在处理观测数据的你。

本文还有配套的精品资源，点击获取