尧图网站建设 
简介面向GNSS数据质量分析场景G-nut Anubis 2.3.0压缩包是一套覆盖Windows、Linux及源码编译的完整工具集。该软件用于GPS及多系统GNSS观测数据质量检核适合测绘、地球科学、交通监控与精准农业等领域的科研和工程人员使用。压缩包内含30个文件总大小7.88MB主要文件类型包括两个Windows可执行程序、Perl源码模块、PDF教程与官方手册、XML配置模板、Linux安装文档、示例数据及经验分享PPT兼顾直接运行、学习文档和二次开发三种需求。已有2088人学习下载。使用这套资源新手可按教程和配置介绍快速上手完成多星数据质量评估进阶用户可结合源码、VS2019编译指导及zlib依赖自行定制功能深入了解Anubis的运行机制与统计输出方式。1. G-Nut/Anubis 是什么一个 7z 压缩包背后的 GNSS 数据质量分析利器做 CORS 站运维和 PPP 解算的人大概都遇到过这种场景手里的 RINEX 观测文件看起来没问题但定位精度突然掉到分米级说不清是接收机坏了、天线被遮挡还是当天电离层活动异常。G-Nut/Anubis 就是用来回答这个问题的开源工具——它读入 RINEX 2/3 观测文件把多路径误差、信噪比、周跳、卫星可见性、钟跳这些指标逐项统计出来生成一份可以直接存档的质量报告。这个版本以 7z 压缩包形式分发2.3.0 不算新但胜在稳定至今仍是不少测绘单位做数据质量分析的默认选择。适合三类人基准站运维工程师、解算前的数据预处理环节、以及接收机进场验收的技术员。2. 先过解压这一关7z 包安装与运行环境准备2.1 为什么是 7z以及解压工具怎么选以 7z 格式分发图的是 LZMA2 压缩率高在网盘和邮件之间传递省流量。但很多人在 Windows 下直接用 WinRAR 去解 7z偶尔会报“数据错误”或干脆不识别尤其当压缩时勾选了加密文件名、或者用了分卷。我见过不少同事把包重新下载两三遍最后才发现是解压工具实现不完整——这不是包坏了是工具没选对。常见做法是装官方 7-Zip而不是各种“增强版”。增强版多出来的功能主要是更多压缩算法和右键菜单美化对解压这个包没有实际帮助反而可能因为你系统里同时装了两套 7z 关联双击时调用了旧版而翻车。安装时注意勾选“添加到系统 PATH”或者装完手动把C:\Program Files\7-Zip加进环境变量。这一步不做后面脚本里直接敲7z x会提示找不到命令很多 7z 安装教程都栽在这一句上。下载安装后先在命令行验证一下7z | head -n 5能看到版本号和命令列表就说明 PATH 有效。这里有个细节7-Zip 的命令行程序有三个7z.exe、7za.exe、7zr.exe。7z.exe功能最全支持 LZMA2 和加密头后两个是精简版遇到带密码、带加密文件名的包可能解不动。所以 PATH 里优先保证7z指向的是完整版7z.exe。2.2 Windows 与 Linux 下把 Anubis 跑起来的两种姿势解压之后先别急着处理自己的数据打开包里文件看一眼。这个 7z 压缩包可能只带源码也可能带 Windows 下直接执行的程序。判断方法很直接在命令行敲anubis -v或anubis --version能回显版本号就直接用提示找不到命令就走编译路线。Windows 下最省事的做法是用别人构建好的可执行文件解压后放进一个固定目录比如D:\gnss\anubis再把该目录加入 PATH。注意不要和别的 GNSS 工具混在一个目录里Anubis 的可执行文件名比较通用很容易和系统里其他程序重名。Linux 下先把 7z 解压工具装上再处理源码sudo apt install p7zip-full build-essential # Debian/Ubuntu 系 7z x G-nut_anubis2.3.0.7z -o./anubis-src # 注意 -o 后面没有空格 cd ./anubis-src ./configure # 如果存在该脚本 make -j$(nproc) sudo make install这四步里最容易出问题的是参数格式。7z x的-o指定解压输出目录-o与目录路径之间不能有空格写成-o ./anubis-src没问题写成-o ./anubis-src也常见但写成分开的-o ./dir会被当作两个参数解压路径就乱了。make -j$(nproc)用全部 CPU 核心并行编译如果编译中途报错先降级成make -j2再试并行度高时偶发内存不足导致的编译失败属于正常现象。Anubis 的源码构建只依赖标准 C 工具链不需要额外装库这点比很多 GNSS 项目省心。但这也意味着它默认没有图形界面所有操作都在终端里完成。新发行版上如果apt搜不到p7zip-full换成sudo apt install 7zip包名在 2023 年之后的 Debian/Ubuntu 里改过。2.3 验证安装跑通自带的示例数据源码包里通常会带 example 目录和测试 RINEX 文件。拿到包的第一步不是处理自己的数据而是先把示例跑通确认编译结果和运行环境没有隐藏问题。mkdir -p ~/gnss-qc cd ~/gnss-qc cp -r ~/anubis-src/example/* . anubis -x example.json -i example.rnx -o output/-x指定配置文件-i指定输入 RINEX 文件-o指定输出目录。执行后终端会滚动输出每个 GNSS 系统的卫星数、信噪比分段统计等数字output/目录下出现 XML 报告就说明环境正常。如果提示找不到输入文件先ls看看示例目录里的实际文件名Anubis 对 RINEX 3 文件名后缀非常敏感.rnx和.obs不能随便改这是第一次运行最容易踩的坑。3. 第一次正式处理从 RINEX 文件到 QC 报告的完整命令3.1 配置文件先于命令anubis.json 的关键字段Anubis 用 JSON 文件做配置命令本身很简洁真正的工作量在配置里。先给一份我常用的最小配置把四大全球系统的主力信号都列上{ observations: { gps: [C1C, L1C, D1C, S1C, C2W, L2W, D2W, S2W], glo: [C1C, L1C, D1C, S1C, C2P, L2P, D2P, S2P], gal: [C1X, L1X, D1X, S1X, C5X, L5X, D5X, S5X], bds: [C2I, L2I, D2I, S2I, C7I, L7I, D7I, S7I] }, interval: 30, mask: 10, snr: [0, 55], output: { directory: ./qc } }这份配置里observations是最核心的字段。每个系统后面对应一组观测值C是伪距L是载波相位D是多普勒S是信噪比。很多人只填了C和L结果报告里多路径组合和信噪比统计全是空的——多路径计算必须同时有伪距和相位信噪比必须显式列出S开头的观测值缺一个对应的统计列就静默消失。interval是统计的时间间隔单位秒。对静态观测数据设 30 秒足够如果你手里的 RINEX 是 1 秒采样这里设 30 秒相当于每 30 秒做一个快照统计报告文件大小会小很多。mask是高度角掩蔽角低于该角度的卫星不参与统计市区观测建议设 10 度山区的测站可以放宽到 5 度。snr是信噪比分段的上限Anubis 默认按 0~50 dB-Hz 分段统计有些新接收机信噪比能到 55设 55 能让高段位不至于全部堆在最后一档。3.2 执行命令从原始观测文件到报告输出的完整流程配置写好后执行命令很简单anubis -x anubis.json -i ISDD00RUS_S_20240010000_01D_30S_MO.rnx -o qc/这个命令里-x后面是配置文件名-i是输入的 RINEX 3 文件-o是输出目录。RINEX 3 文件名本身携带信息ISDD是测站号00RUS是国家和机构20240010000是时间戳01D表示一天的数据30S表示采样率。Anubis 会从文件名里解析这些元数据所以拿到数据后不要自作主张改名改成test1.rnx这种通用名会让输出报告的站点信息全是乱的。执行期间终端会逐小时打印统计进度。数据量大的时候一小时 RINEX 在普通电脑上大约跑几秒到几十秒取决于卫星数量和信号频点数。跑完后qc/目录下会生成以测站和日期命名的 XML 报告。终端摘要和 XML 之间的关系需要注意终端里看到的是总览XML 才是完整的逐卫星、逐时段的明细后续写脚本做批量质检解析的就是这个 XML。Windows 下命令完全一致只是可执行文件换成anubis.exe。如果提示缺少 DLL通常是系统缺 Visual C 运行库去微软官网装最新的 VC Redistributable 就能解决这属于通用问题和 Anubis 本身无关。3.3 看懂结果先看哪几个指标报告生成后不要先盯着定位精度那是结果不是原因。质量分析里最值得先看的是四个指标指标说明健康参考范围MP1 / MP2L1、L2 上的多路径误差小于 0.5 米SNR各系统信号信噪比中位数GPS 高于 40 dB-Hz周跳比观测历元数与周跳数之比大于 1000 为佳钟跳接收机钟跳次数尽量为 0多路径数值突然变大优先怀疑天线净空条件变化比如附近立了新楼、树叶遮挡而不是接收机坏了。信噪比整体偏低但多路径正常则怀疑天线增益或馈线衰减。周跳比骤降且伴随 SNR 低多半是测站被人动过天线或线缆松动。这套排查顺序能把故障范围缩小到环境、天线、接收机三选一后面的批量脚本也是按这个思路写判断条件的。4. 把报告调到能用的状态频点、高度角与周跳参数设置4.1 观测值选择不同系统该盯哪些信号配置里的观测值表决定了报告能给出哪些统计。GPS 通常用 L1 C/A 和 L2 半无码C1C/L1C与C2W/L2W两个频点都存在才能算多路径和电离层残差。GLONASS 的C2P对应老式接收机的 P 码观测新接收机可能输出C2C要根据实际数据头文件里的观测类型列表来填不要照抄我上面的表。Galileo 和 BDS 的信号命名最容易搞错。Galileo 的C1X、C5X是 E1 和 E5a 频点C7X才是 E5bBDS 老信号是 B1I/B2I对应C2I、C7I新一代接收机输出 B1C/B2a 时对应C1X、C5X。填错了不会报错只是报告里对应卫星的统计永远是零这种静默失败比报错更坑人。建议在配置前先打开 RINEX 头文件看每个系统实际输出了哪些观测类型。用下面的命令提取head -n 50 ISDD00RUS_S_20240010000_01D_30S_MO.rnx | grep -A 5 SYS / # / OBS TYPES这一步花两分钟能避免整份报告因为观测值列表不匹配而白跑。观测值不是越多越好列表太长会拖慢处理速度常规数据质检盯每个系统两到三个频点就够。4.2 高度角掩蔽与信噪比阈值mask参数直接影响统计样本。设 10 度意味着 10 度以下的卫星全都不进入多路径和周跳统计。好处是剔除了低高度角噪声数据坏处是如果测站本身净空条件差高角度卫星本来就不多再一掩蔽可用卫星数太少报告统计数据波动反而变大。我一般在平原开阔环境用 10 度城区或山区降到 5 度。注意 Anubis 的掩蔽角是硬性过滤不同于后处理解算里的高度角加权它不会把低角度卫星折算权重而是直接不统计。snr的用法也需要理解。[0, 55]不是过滤条件而是统计分段的界限低于 0 和高于 55 的信噪比不会进统计表。对大多数测站保持默认分段即可。真正需要调它的是那种用了信号放大器的测站信噪比整体偏高如果不把上限扩到 60高段位卫星全堆积在最后一档看不出时间变化趋势。多路径统计还必须保证观测值列表里同时包含伪距和相位。有人为了精简只写C1C和L1C忘了D1C和S1C多路径组合照样能算但信噪比那条曲线会缺失。Anubis 不会提示你缺了哪个观测类型它只在报告里留一个空列这种“没报错但结果不完整”的情况是我见过最多的配置翻车现场。4.3 周跳探测阈值设在多少不误报不漏报Anubis 的周跳探测基于电离层残差和 Melbourne-Wübbena 组合这两种方法对采样率很敏感。30 秒采样数据阈值设太严会把正常电离层变化误判成周跳1 秒高频数据阈值设太松又会漏掉真实周跳。实践中我的经验值30 秒采样时电离层残差阈值取 25 左右Melbourne-Wübbena 阈值取 1001 秒采样时两者都可以收紧 30%~50%。但具体阈值在 Anubis 配置里是全局参数修改后必须重新跑同样的数据段做前后对比。判断标准很简单一个 24 小时静态文件报告的周跳数应该在个位数如果出来几百个先检查是不是阈值太紧或数据本身被截断。高频数据还有另一个坑接收机钟跳。部分接收机在内部钟差超限时会重置钟面时间这在 RINEX 里表现为所有卫星同时发生“周跳”。Anubis 的钟跳检测如果被关闭这些伪周跳会全部算成周跳污染整个统计。处理 1 秒采样数据前确认配置里启用了钟跳检测并在报告里检查钟跳计数。5. 避坑指南从解压到出报告最常见的 5 个问题5.1 7z 压缩包密码正确却一直报错现象解压时输入从发布页复制的密码工具却提示“密码错误”或“数据错误”多试几次一样。原因最常见的是压缩时勾选了“加密文件名”。这种包在解压前必须先验证密码而部分解压工具在文件名加密状态下对密码的编码处理有差异尤其密码含特殊符号时会把 UTF-8 的符号转成 GBK 再校验导致明明密码正确却报错。另一个原因是复制密码时首尾带了空格。解决改用命令行完整版 7z先列目录再解压7z l archive.7z # 先验证能否列出内容 7z x archive.7z -o./out -p粘贴密码 -aoa-p后直接跟密码密码含空格时用双引号包住。7z l能列出文件说明密码正确再解压一般不会出问题。如果密码真的忘了唯一的后悔药是找发布方重新索要暴力破解 LZMA2 的加密在当前算力下不现实。收到加密包的第一时间就验证密码不要等到处理数据当天才解压。5.2 Linux 下解压 7z 文件却提示工具缺失现象执行7z x报错command not found或者提示7za不支持该格式。原因最小化安装的 Linux 没有装 p7zip装了p7zip而不是p7zip-full只提供了7za。7za只支持 7z 格式的一部分功能遇到 LZMA2 和加密头时能力不足虽然大多数情况能解压普通 7z但遇到不支持的压缩参数就直接退出。解决Debian/Ubuntu 上装完整版sudo apt install p7zip-full新版本发行版如果提示找不到该包改用sudo apt install 7zip。装完用7z i查看编译参数确认有 LZMA2 字样。另外 Fedora/RHEL 系用sudo dnf install p7zip p7zip-plugins只装 p7zip 主包同样会缺插件。5.3 配置文件编码问题UTF-8 BOM 与中文引号现象Anubis 启动后立刻退出终端提示 JSON 解析错误但配置文件用文本编辑器打开很正常。原因Windows 记事本保存 JSON 时会写入 UTF-8 BOM 头Anubis 的 JSON 解析器认不出 BOM把它当成非法字符。同理在中文输入法状态下写的冒号和引号是全角字符JSON 解析器只认半角。解决用 VS Code 或 Notepad 打开配置文件右下角确认编码为 UTF-8另存时选择“UTF-8 无 BOM”。打开 Anubis 包的示例配置对照检查引号和冒号是否为半角。每次修改配置后用一条短命令验证python3 -m json.tool anubis.json /dev/null echo JSON OK这个命令利用 Python 做 JSON 语法校验返回JSON OK再交给 Anubis能省掉大量无用功。5.4 RINEX 版本与文件名后缀混用现象同一个文件在 RINEX 2 软件里能打开在 Anubis 里却提示“无法识别文件格式”或“文件版本不支持”。原因Anubis 同时支持 RINEX 2 和 RINEX 3但识别版本时高度依赖文件名约定。RINEX 2 文件名是小写格式abcd0010.20oRINEX 3 是ABCD00USA_R_20200010000_01D_30S_MO.rnx两者命名规则完全不同。有人把 RINEX 3 文件改名为data.obs或site.rnxAnubis 会无法准确解析版本和时间信息。解决保持原始文件名避免重命名。如果必须从别人手里接收已改名的文件打开文件头看第二行RINEX 3 头文件第二行会明确写RINEX VERSION / TYPE。另一个常见问题是 Hatanaka 压缩格式.crx部分版本不直接支持需要先解压回标准 RINEX再交给 Anubis。命令行解压 Hatanaka 有专门工具不展开但要记住.crx和.rnx在 Anubis 眼里是两类东西。5.5 跑了半天才发现输出目录里什么都没有现象命令执行完没有任何报错终端也滚动了统计信息但指定的输出目录为空。原因检查-o参数指定的目录是否已经存在。Anubis 不会自动创建多级不存在的目录如果写的是-o qc/report/而qc目录不存在程序可能把输出写到当前目录或直接丢弃。另外检查配置里output.directory字段是否和命令行-o同时存在两者冲突时不同版本处理方式不同。解决命令执行前先用mkdir -p qc/report创建好目录并且保持命令行-o与配置里output.directory路径一致。跑完看输出目录的文件生成时间如果是最新的再打开 XML 确认里面的测站名和日期正确。养成跑完批量任务后用一条命令检查输出数量的习惯别只看终端滚屏。6. 进阶用脚本批量跑完整测站的 QC并快速定位异常6.1 先串行后并行一套简单的批量处理脚本单个文件跑通后年度数据批量处理就可以交给脚本。先写串行版本确认流程可靠for rnx in /data/rinex/2024/*.rnx; do base$(basename $rnx .rnx) mkdir -p /data/qc_out/$base anubis -x qc_config.json -i $rnx -o /data/qc_out/$base/ echo $(date %H:%M) done $base done每个文件输出到独立目录basename去掉后缀用来命名目录避免多个文件的报告互相覆盖。echo打印进度跑挂了一看输出就知道停在哪。串行版确认无异常后换成并行版for rnx in /data/rinex/2024/*.rnx; do base$(basename $rnx .rnx) mkdir -p /data/qc_out/$base anubis -x qc_config.json -i $rnx -o /data/qc_out/$base/ if [ $(jobs -r | wc -l) -ge 4 ]; then wait fi done wait把anubis命令丢到后台执行jobs -r统计正在运行的任务数满 4 个就wait等一轮控制并发数。并发太高容易内存不足4 到 8 个对普通工作站是安全范围。跑完后检查 XML 文件数量是否与输入 RINEX 数量一致数量对不上就是有文件在静默失败。6.2 用报告里的三个指标快速判断站点健康批量结果出来后用脚本解析 XML 比逐个打开报告更高效。我一般只提取三个指标多路径 MP1 日均值、周跳比、信噪比中位数。这三个指标组合起来能覆盖大部分测站故障MP1 超过 0.5 米且有渐变趋势查天线净空周跳比低于 1000 且伴随 SNR 下降查射频线缆和接头所有系统 SNR 集体偏低但多路径正常查接收机本身。把这些阈值写进巡检脚本每天定时跑一遍超过阈值就输出告警。这套流程我用了几年最大教训是任何批量任务开始前先手动跑一条数据确认配置和输入文件匹配再放开全量跑。曾经因为文件名大小写混用一批数据被静默跳过浪费了一个晚上的算力。数据质检是解算的前置门槛门槛守不住后面的定位精度分析都是在猜。Anubis 本身不复杂复杂的是使用者有没有一套固定的验证习惯。希望这篇笔记帮你在拿到这个 7z 包的第一天就少走我当年走过的那些弯路。本文还有配套的精品资源点击获取 G-Nut/Anubis GNSS数据质量分析：从7z解压到QC报告实战
简介面向GNSS数据质量分析场景G-nut Anubis 2.3.0压缩包是一套覆盖Windows、Linux及源码编译的完整工具集。该软件用于GPS及多系统GNSS观测数据质量检核适合测绘、地球科学、交通监控与精准农业等领域的科研和工程人员使用。压缩包内含30个文件总大小7.88MB主要文件类型包括两个Windows可执行程序、Perl源码模块、PDF教程与官方手册、XML配置模板、Linux安装文档、示例数据及经验分享PPT兼顾直接运行、学习文档和二次开发三种需求。已有2088人学习下载。使用这套资源新手可按教程和配置介绍快速上手完成多星数据质量评估进阶用户可结合源码、VS2019编译指导及zlib依赖自行定制功能深入了解Anubis的运行机制与统计输出方式。1. G-Nut/Anubis 是什么一个 7z 压缩包背后的 GNSS 数据质量分析利器做 CORS 站运维和 PPP 解算的人大概都遇到过这种场景手里的 RINEX 观测文件看起来没问题但定位精度突然掉到分米级说不清是接收机坏了、天线被遮挡还是当天电离层活动异常。G-Nut/Anubis 就是用来回答这个问题的开源工具——它读入 RINEX 2/3 观测文件把多路径误差、信噪比、周跳、卫星可见性、钟跳这些指标逐项统计出来生成一份可以直接存档的质量报告。这个版本以 7z 压缩包形式分发2.3.0 不算新但胜在稳定至今仍是不少测绘单位做数据质量分析的默认选择。适合三类人基准站运维工程师、解算前的数据预处理环节、以及接收机进场验收的技术员。2. 先过解压这一关7z 包安装与运行环境准备2.1 为什么是 7z以及解压工具怎么选以 7z 格式分发图的是 LZMA2 压缩率高在网盘和邮件之间传递省流量。但很多人在 Windows 下直接用 WinRAR 去解 7z偶尔会报“数据错误”或干脆不识别尤其当压缩时勾选了加密文件名、或者用了分卷。我见过不少同事把包重新下载两三遍最后才发现是解压工具实现不完整——这不是包坏了是工具没选对。常见做法是装官方 7-Zip而不是各种“增强版”。增强版多出来的功能主要是更多压缩算法和右键菜单美化对解压这个包没有实际帮助反而可能因为你系统里同时装了两套 7z 关联双击时调用了旧版而翻车。安装时注意勾选“添加到系统 PATH”或者装完手动把C:\Program Files\7-Zip加进环境变量。这一步不做后面脚本里直接敲7z x会提示找不到命令很多 7z 安装教程都栽在这一句上。下载安装后先在命令行验证一下7z | head -n 5能看到版本号和命令列表就说明 PATH 有效。这里有个细节7-Zip 的命令行程序有三个7z.exe、7za.exe、7zr.exe。7z.exe功能最全支持 LZMA2 和加密头后两个是精简版遇到带密码、带加密文件名的包可能解不动。所以 PATH 里优先保证7z指向的是完整版7z.exe。2.2 Windows 与 Linux 下把 Anubis 跑起来的两种姿势解压之后先别急着处理自己的数据打开包里文件看一眼。这个 7z 压缩包可能只带源码也可能带 Windows 下直接执行的程序。判断方法很直接在命令行敲anubis -v或anubis --version能回显版本号就直接用提示找不到命令就走编译路线。Windows 下最省事的做法是用别人构建好的可执行文件解压后放进一个固定目录比如D:\gnss\anubis再把该目录加入 PATH。注意不要和别的 GNSS 工具混在一个目录里Anubis 的可执行文件名比较通用很容易和系统里其他程序重名。Linux 下先把 7z 解压工具装上再处理源码sudo apt install p7zip-full build-essential # Debian/Ubuntu 系 7z x G-nut_anubis2.3.0.7z -o./anubis-src # 注意 -o 后面没有空格 cd ./anubis-src ./configure # 如果存在该脚本 make -j$(nproc) sudo make install这四步里最容易出问题的是参数格式。7z x的-o指定解压输出目录-o与目录路径之间不能有空格写成-o ./anubis-src没问题写成-o ./anubis-src也常见但写成分开的-o ./dir会被当作两个参数解压路径就乱了。make -j$(nproc)用全部 CPU 核心并行编译如果编译中途报错先降级成make -j2再试并行度高时偶发内存不足导致的编译失败属于正常现象。Anubis 的源码构建只依赖标准 C 工具链不需要额外装库这点比很多 GNSS 项目省心。但这也意味着它默认没有图形界面所有操作都在终端里完成。新发行版上如果apt搜不到p7zip-full换成sudo apt install 7zip包名在 2023 年之后的 Debian/Ubuntu 里改过。2.3 验证安装跑通自带的示例数据源码包里通常会带 example 目录和测试 RINEX 文件。拿到包的第一步不是处理自己的数据而是先把示例跑通确认编译结果和运行环境没有隐藏问题。mkdir -p ~/gnss-qc cd ~/gnss-qc cp -r ~/anubis-src/example/* . anubis -x example.json -i example.rnx -o output/-x指定配置文件-i指定输入 RINEX 文件-o指定输出目录。执行后终端会滚动输出每个 GNSS 系统的卫星数、信噪比分段统计等数字output/目录下出现 XML 报告就说明环境正常。如果提示找不到输入文件先ls看看示例目录里的实际文件名Anubis 对 RINEX 3 文件名后缀非常敏感.rnx和.obs不能随便改这是第一次运行最容易踩的坑。3. 第一次正式处理从 RINEX 文件到 QC 报告的完整命令3.1 配置文件先于命令anubis.json 的关键字段Anubis 用 JSON 文件做配置命令本身很简洁真正的工作量在配置里。先给一份我常用的最小配置把四大全球系统的主力信号都列上{ observations: { gps: [C1C, L1C, D1C, S1C, C2W, L2W, D2W, S2W], glo: [C1C, L1C, D1C, S1C, C2P, L2P, D2P, S2P], gal: [C1X, L1X, D1X, S1X, C5X, L5X, D5X, S5X], bds: [C2I, L2I, D2I, S2I, C7I, L7I, D7I, S7I] }, interval: 30, mask: 10, snr: [0, 55], output: { directory: ./qc } }这份配置里observations是最核心的字段。每个系统后面对应一组观测值C是伪距L是载波相位D是多普勒S是信噪比。很多人只填了C和L结果报告里多路径组合和信噪比统计全是空的——多路径计算必须同时有伪距和相位信噪比必须显式列出S开头的观测值缺一个对应的统计列就静默消失。interval是统计的时间间隔单位秒。对静态观测数据设 30 秒足够如果你手里的 RINEX 是 1 秒采样这里设 30 秒相当于每 30 秒做一个快照统计报告文件大小会小很多。mask是高度角掩蔽角低于该角度的卫星不参与统计市区观测建议设 10 度山区的测站可以放宽到 5 度。snr是信噪比分段的上限Anubis 默认按 0~50 dB-Hz 分段统计有些新接收机信噪比能到 55设 55 能让高段位不至于全部堆在最后一档。3.2 执行命令从原始观测文件到报告输出的完整流程配置写好后执行命令很简单anubis -x anubis.json -i ISDD00RUS_S_20240010000_01D_30S_MO.rnx -o qc/这个命令里-x后面是配置文件名-i是输入的 RINEX 3 文件-o是输出目录。RINEX 3 文件名本身携带信息ISDD是测站号00RUS是国家和机构20240010000是时间戳01D表示一天的数据30S表示采样率。Anubis 会从文件名里解析这些元数据所以拿到数据后不要自作主张改名改成test1.rnx这种通用名会让输出报告的站点信息全是乱的。执行期间终端会逐小时打印统计进度。数据量大的时候一小时 RINEX 在普通电脑上大约跑几秒到几十秒取决于卫星数量和信号频点数。跑完后qc/目录下会生成以测站和日期命名的 XML 报告。终端摘要和 XML 之间的关系需要注意终端里看到的是总览XML 才是完整的逐卫星、逐时段的明细后续写脚本做批量质检解析的就是这个 XML。Windows 下命令完全一致只是可执行文件换成anubis.exe。如果提示缺少 DLL通常是系统缺 Visual C 运行库去微软官网装最新的 VC Redistributable 就能解决这属于通用问题和 Anubis 本身无关。3.3 看懂结果先看哪几个指标报告生成后不要先盯着定位精度那是结果不是原因。质量分析里最值得先看的是四个指标指标说明健康参考范围MP1 / MP2L1、L2 上的多路径误差小于 0.5 米SNR各系统信号信噪比中位数GPS 高于 40 dB-Hz周跳比观测历元数与周跳数之比大于 1000 为佳钟跳接收机钟跳次数尽量为 0多路径数值突然变大优先怀疑天线净空条件变化比如附近立了新楼、树叶遮挡而不是接收机坏了。信噪比整体偏低但多路径正常则怀疑天线增益或馈线衰减。周跳比骤降且伴随 SNR 低多半是测站被人动过天线或线缆松动。这套排查顺序能把故障范围缩小到环境、天线、接收机三选一后面的批量脚本也是按这个思路写判断条件的。4. 把报告调到能用的状态频点、高度角与周跳参数设置4.1 观测值选择不同系统该盯哪些信号配置里的观测值表决定了报告能给出哪些统计。GPS 通常用 L1 C/A 和 L2 半无码C1C/L1C与C2W/L2W两个频点都存在才能算多路径和电离层残差。GLONASS 的C2P对应老式接收机的 P 码观测新接收机可能输出C2C要根据实际数据头文件里的观测类型列表来填不要照抄我上面的表。Galileo 和 BDS 的信号命名最容易搞错。Galileo 的C1X、C5X是 E1 和 E5a 频点C7X才是 E5bBDS 老信号是 B1I/B2I对应C2I、C7I新一代接收机输出 B1C/B2a 时对应C1X、C5X。填错了不会报错只是报告里对应卫星的统计永远是零这种静默失败比报错更坑人。建议在配置前先打开 RINEX 头文件看每个系统实际输出了哪些观测类型。用下面的命令提取head -n 50 ISDD00RUS_S_20240010000_01D_30S_MO.rnx | grep -A 5 SYS / # / OBS TYPES这一步花两分钟能避免整份报告因为观测值列表不匹配而白跑。观测值不是越多越好列表太长会拖慢处理速度常规数据质检盯每个系统两到三个频点就够。4.2 高度角掩蔽与信噪比阈值mask参数直接影响统计样本。设 10 度意味着 10 度以下的卫星全都不进入多路径和周跳统计。好处是剔除了低高度角噪声数据坏处是如果测站本身净空条件差高角度卫星本来就不多再一掩蔽可用卫星数太少报告统计数据波动反而变大。我一般在平原开阔环境用 10 度城区或山区降到 5 度。注意 Anubis 的掩蔽角是硬性过滤不同于后处理解算里的高度角加权它不会把低角度卫星折算权重而是直接不统计。snr的用法也需要理解。[0, 55]不是过滤条件而是统计分段的界限低于 0 和高于 55 的信噪比不会进统计表。对大多数测站保持默认分段即可。真正需要调它的是那种用了信号放大器的测站信噪比整体偏高如果不把上限扩到 60高段位卫星全堆积在最后一档看不出时间变化趋势。多路径统计还必须保证观测值列表里同时包含伪距和相位。有人为了精简只写C1C和L1C忘了D1C和S1C多路径组合照样能算但信噪比那条曲线会缺失。Anubis 不会提示你缺了哪个观测类型它只在报告里留一个空列这种“没报错但结果不完整”的情况是我见过最多的配置翻车现场。4.3 周跳探测阈值设在多少不误报不漏报Anubis 的周跳探测基于电离层残差和 Melbourne-Wübbena 组合这两种方法对采样率很敏感。30 秒采样数据阈值设太严会把正常电离层变化误判成周跳1 秒高频数据阈值设太松又会漏掉真实周跳。实践中我的经验值30 秒采样时电离层残差阈值取 25 左右Melbourne-Wübbena 阈值取 1001 秒采样时两者都可以收紧 30%~50%。但具体阈值在 Anubis 配置里是全局参数修改后必须重新跑同样的数据段做前后对比。判断标准很简单一个 24 小时静态文件报告的周跳数应该在个位数如果出来几百个先检查是不是阈值太紧或数据本身被截断。高频数据还有另一个坑接收机钟跳。部分接收机在内部钟差超限时会重置钟面时间这在 RINEX 里表现为所有卫星同时发生“周跳”。Anubis 的钟跳检测如果被关闭这些伪周跳会全部算成周跳污染整个统计。处理 1 秒采样数据前确认配置里启用了钟跳检测并在报告里检查钟跳计数。5. 避坑指南从解压到出报告最常见的 5 个问题5.1 7z 压缩包密码正确却一直报错现象解压时输入从发布页复制的密码工具却提示“密码错误”或“数据错误”多试几次一样。原因最常见的是压缩时勾选了“加密文件名”。这种包在解压前必须先验证密码而部分解压工具在文件名加密状态下对密码的编码处理有差异尤其密码含特殊符号时会把 UTF-8 的符号转成 GBK 再校验导致明明密码正确却报错。另一个原因是复制密码时首尾带了空格。解决改用命令行完整版 7z先列目录再解压7z l archive.7z # 先验证能否列出内容 7z x archive.7z -o./out -p粘贴密码 -aoa-p后直接跟密码密码含空格时用双引号包住。7z l能列出文件说明密码正确再解压一般不会出问题。如果密码真的忘了唯一的后悔药是找发布方重新索要暴力破解 LZMA2 的加密在当前算力下不现实。收到加密包的第一时间就验证密码不要等到处理数据当天才解压。5.2 Linux 下解压 7z 文件却提示工具缺失现象执行7z x报错command not found或者提示7za不支持该格式。原因最小化安装的 Linux 没有装 p7zip装了p7zip而不是p7zip-full只提供了7za。7za只支持 7z 格式的一部分功能遇到 LZMA2 和加密头时能力不足虽然大多数情况能解压普通 7z但遇到不支持的压缩参数就直接退出。解决Debian/Ubuntu 上装完整版sudo apt install p7zip-full新版本发行版如果提示找不到该包改用sudo apt install 7zip。装完用7z i查看编译参数确认有 LZMA2 字样。另外 Fedora/RHEL 系用sudo dnf install p7zip p7zip-plugins只装 p7zip 主包同样会缺插件。5.3 配置文件编码问题UTF-8 BOM 与中文引号现象Anubis 启动后立刻退出终端提示 JSON 解析错误但配置文件用文本编辑器打开很正常。原因Windows 记事本保存 JSON 时会写入 UTF-8 BOM 头Anubis 的 JSON 解析器认不出 BOM把它当成非法字符。同理在中文输入法状态下写的冒号和引号是全角字符JSON 解析器只认半角。解决用 VS Code 或 Notepad 打开配置文件右下角确认编码为 UTF-8另存时选择“UTF-8 无 BOM”。打开 Anubis 包的示例配置对照检查引号和冒号是否为半角。每次修改配置后用一条短命令验证python3 -m json.tool anubis.json /dev/null echo JSON OK这个命令利用 Python 做 JSON 语法校验返回JSON OK再交给 Anubis能省掉大量无用功。5.4 RINEX 版本与文件名后缀混用现象同一个文件在 RINEX 2 软件里能打开在 Anubis 里却提示“无法识别文件格式”或“文件版本不支持”。原因Anubis 同时支持 RINEX 2 和 RINEX 3但识别版本时高度依赖文件名约定。RINEX 2 文件名是小写格式abcd0010.20oRINEX 3 是ABCD00USA_R_20200010000_01D_30S_MO.rnx两者命名规则完全不同。有人把 RINEX 3 文件改名为data.obs或site.rnxAnubis 会无法准确解析版本和时间信息。解决保持原始文件名避免重命名。如果必须从别人手里接收已改名的文件打开文件头看第二行RINEX 3 头文件第二行会明确写RINEX VERSION / TYPE。另一个常见问题是 Hatanaka 压缩格式.crx部分版本不直接支持需要先解压回标准 RINEX再交给 Anubis。命令行解压 Hatanaka 有专门工具不展开但要记住.crx和.rnx在 Anubis 眼里是两类东西。5.5 跑了半天才发现输出目录里什么都没有现象命令执行完没有任何报错终端也滚动了统计信息但指定的输出目录为空。原因检查-o参数指定的目录是否已经存在。Anubis 不会自动创建多级不存在的目录如果写的是-o qc/report/而qc目录不存在程序可能把输出写到当前目录或直接丢弃。另外检查配置里output.directory字段是否和命令行-o同时存在两者冲突时不同版本处理方式不同。解决命令执行前先用mkdir -p qc/report创建好目录并且保持命令行-o与配置里output.directory路径一致。跑完看输出目录的文件生成时间如果是最新的再打开 XML 确认里面的测站名和日期正确。养成跑完批量任务后用一条命令检查输出数量的习惯别只看终端滚屏。6. 进阶用脚本批量跑完整测站的 QC并快速定位异常6.1 先串行后并行一套简单的批量处理脚本单个文件跑通后年度数据批量处理就可以交给脚本。先写串行版本确认流程可靠for rnx in /data/rinex/2024/*.rnx; do base$(basename $rnx .rnx) mkdir -p /data/qc_out/$base anubis -x qc_config.json -i $rnx -o /data/qc_out/$base/ echo $(date %H:%M) done $base done每个文件输出到独立目录basename去掉后缀用来命名目录避免多个文件的报告互相覆盖。echo打印进度跑挂了一看输出就知道停在哪。串行版确认无异常后换成并行版for rnx in /data/rinex/2024/*.rnx; do base$(basename $rnx .rnx) mkdir -p /data/qc_out/$base anubis -x qc_config.json -i $rnx -o /data/qc_out/$base/ if [ $(jobs -r | wc -l) -ge 4 ]; then wait fi done wait把anubis命令丢到后台执行jobs -r统计正在运行的任务数满 4 个就wait等一轮控制并发数。并发太高容易内存不足4 到 8 个对普通工作站是安全范围。跑完后检查 XML 文件数量是否与输入 RINEX 数量一致数量对不上就是有文件在静默失败。6.2 用报告里的三个指标快速判断站点健康批量结果出来后用脚本解析 XML 比逐个打开报告更高效。我一般只提取三个指标多路径 MP1 日均值、周跳比、信噪比中位数。这三个指标组合起来能覆盖大部分测站故障MP1 超过 0.5 米且有渐变趋势查天线净空周跳比低于 1000 且伴随 SNR 下降查射频线缆和接头所有系统 SNR 集体偏低但多路径正常查接收机本身。把这些阈值写进巡检脚本每天定时跑一遍超过阈值就输出告警。这套流程我用了几年最大教训是任何批量任务开始前先手动跑一条数据确认配置和输入文件匹配再放开全量跑。曾经因为文件名大小写混用一批数据被静默跳过浪费了一个晚上的算力。数据质检是解算的前置门槛门槛守不住后面的定位精度分析都是在猜。Anubis 本身不复杂复杂的是使用者有没有一套固定的验证习惯。希望这篇笔记帮你在拿到这个 7z 包的第一天就少走我当年走过的那些弯路。本文还有配套的精品资源点击获取