简介：PDF文档聚焦商用GNSS数据处理软件的解算精度对比，面向测绘工程、国土空间规划及GNSS数据处理相关技术人员。内容以TBC3.6V、HGO1.1.0V、SGO16.05.26三款软件为对象，利用双星和三星实测数据进行基线解算与整网平差实验，并以GAMIT/GLOBK结果作为精度参考，通过7条长度约1km至86km的基线比较中误差与较差，分析卫星高度角、时间采样率、多模卫星信号组合等因素对解算质量的影响。全文共1个PDF文件，大小478KB，下载后即可直接阅读。已有664人学习下载。读者可从中获得三款商用软件在基线解算和网平差方面的性能差异、参数设置对成果质量的作用规律，以及复杂野外环境下GNSS数据处理软件的选择思路；对开展高精度测量、工程应用或石漠化地区空间开发研究都有一定参考价值。

1. 同样一段数据，两家软件能差上厘米：先把商用GNSS精度对比这件事想清楚

同样一段 48 小时静态观测数据，上周我用 A 软件解出来平面误差 5 毫米，换 B 软件一跑变成 1.1 厘米；高程更夸张，从 8 毫米直接漂到接近 2 厘米。这不是哪个软件坏了，而是精度对比的口径没对齐。商用GNSS数据处理软件解算精度对比分析，核心并不是「谁跑出的数字小谁就赢」，而是你要先回答三个问题：基准是什么、参数是否公平、统计指标是否同口径。这篇笔记写给两类人：一类是拿软件做测量方案选型和投标比测的工程师，另一类是做成果验收、被两份报告数字差异问得头疼的项目负责人。如果你只是想「跑个数据看谁准」，那可以关掉了；如果你想搞清楚「差出来的那几毫米到底从哪来」，下面这套对比流程可以直接照搬。

2. 把对比的账算明白：基准、数据与五个硬指标

2.1 三种对比场景，决定你该信哪个数字

精度对比不是把两个软件的解算结果放一起比大小，场景不同，指标含义完全不同。我做对比时一般先分三类。

第一类是已知点检核，也叫外部符合检验。手上有参考站的精确坐标，比如某机构发布的年度站点成果，把观测数据分别用软件 A、B 解算，算解算坐标和已知坐标的差值。这类场景最直接，适合投标比测和验收，但前提是参考站坐标要足够权威，最好来自多家机构联合解算的长期成果，而不是单次解算值。

第二类是网内闭合检核，适用于没有外部已知点的加密控制网。用两套软件分别解独立基线，再组成闭合环，看环闭合差。闭合差反映的是软件内部自洽性，不能直接换算成绝对精度，但能暴露基线解算的系统性偏差。我见过某种软件固定率很高，但闭合环就是不闭，最后查出来是参考站选取逻辑不同。

第三类是重复性自检，也可以叫内符合检验。同一时段数据，切分成不同子时段，或者把同一基线的不同解算策略结果放一起，算重复性。这一项最考验软硬件稳定性和参数一致性，也是后面自动化脚本里最值得长期跟踪的指标。

三类场景没有谁完全替代谁，我的做法是：选型期做第一类，项目期做第二类，交付前三种各跑一轮。

2.2 五个硬指标，比「误差 5 毫米」这种话靠谱得多

对比报告里最怕只写一句「点位误差优于 1 厘米」。点位误差是合成量，平面和高程误差源完全不同，混在一起等于把信息藏起来。我固定用五个指标，含义和参考阈值如下。

另外还有一个常被略掉的指标叫 NRMS（归一化均方根残差），我习惯在长基线解算里必看。NRMS 反映的是残差相对于理论噪声的比值，接近 0.5 以内说明噪声模型合理，超过 1.0 说明观测值里混进了未建模误差，比如周跳没修干净或电离层残差太大。两个软件如果固定率同为 98%，NRMS 一个 0.3 一个 0.9，我会毫不犹豫选前者，因为后者的「固定」很可能建立在过度宽松的验后残差阈值上。

2.3 数据准备：时长、采样、文件清单，缺一项对比就偏

指标再齐全，数据质量不行也是白做。这里踩过不少坑，按我的习惯整理成硬规矩。

时长上，短基线（20 公里以内）单时段最少 4 小时，长基线（100 公里以上）至少 24 小时。对比实验不能只用一天数据，至少三个连续天、每天两个独立时段，否则相位的多路径周期性和卫星几何重复会掩盖软件差异。采样率统一设置为 15 秒或 30 秒，不要用 1 赫兹高频数据直接灌给静态解算，数据量大且对精度没有贡献。

数据文件方面，按这份清单准备：

补充一条血泪经验：天线量高必须写进文件，而且要让两个软件读同一份测量值。有人把天线高输错 2 毫米，最后对比出来高程差 2 厘米，查了一下午，结果是其中一边单位写成了米。

3. 参数对齐是第一步：三个全局设置和五个必调解算参数

3.1 先统一坐标框架与历元，再谈解算精度

这类对比最容易被忽略的一环是坐标框架。不同软件默认的参考框架和参考历元不同，A 软件可能默认输出最近的框架历元坐标，B 软件则直接输出观测历元坐标。两者在地壳运动活跃区域能差到厘米级，比软件本身的解算差异还大。

我一般这样处理：给两个软件显式指定同一个参考框架和参考历元，比如 ITRF 的某个参考历元；同时打开板块运动模型改正。注意，观测历元坐标和参考历元坐标之间隔着板块运动改正，如果不统一，短基线还好，跨省的长基线上误差是系统性的。

潮汐改正也必须对齐。固体潮对高程影响最大可达 12 厘米，海潮负荷在沿海区域也有 1～3 厘米量级。商用软件通常默认开启，但有的软件默认只开固体潮，海潮要手动选，对比前检查这三个开关状态：固体潮、海潮负荷、极潮。建议全部开启，保持同一配置。

3.2 五个必调参数：统一下来，两边的数字才有的比

参数对齐是精度对比的重头戏，也是扯皮最多的地方。下面五个参数我每次必调，顺序也固定。

截止高度角。默认值五花八门，有的 10 度、有的 15 度。低高度角卫星受多路径影响大，但能增加几何图形强度；设太高则短基线冗余度不足。对比实验统一用 10 度，如果数据来自城市峡谷之类多路径严重的环境，再用 15 度重算一组做敏感性分析。

采样间隔。解算前把观测数据抽稀成 30 秒。很多人以为采样越密越好，实际上静态解算相位观测强相关，加密采样不能显著提高精度，反而放大了电离层闪烁和多路径的短周期噪声。解算时清空原有采样率设置，强制统一为 30 秒。

模糊度固定策略。这是软件差异最大的地方。固定策略通常分连续固定和瞬时固定；对比时统一选「固定解」模式，同时记录固定的检验阈值（比如 Ratio 值下限）。我见过某软件固定率 100%，但解算坐标比浮点解还差，原因是对模糊度残差没有做卡方检验，假固定。

对流层延迟处理。短基线可以用差分方式消掉大部分，但长基线和跨高度角地区必须建模。统一用 Saastamoinen 模型加映射函数，气象参数用标准大气模型，不要一个软件用实测气象、另一个用默认气象，否则高程能差 2 厘米。

电离层处理。双频数据统一用消电离层组合 LC，单频数据则要关闭电离层估计选项。有一点常被忽略：LC 组合放大了相位噪声，所以 LC 解算的 NRMS 会比单频组合略高，这不是软件坏了，是数学特性。

表格汇总一下我在三款软件里的统一配置：

3.3 轨道产品：广播星历和精密星历是两条精度路线

每次对比前先定轨道产品。广播星历是实时产品，精度大概在 1 米量级，误差属于低频系统性偏差，在差分处理中对短基线影响不大，但基线超过 50 公里时误差开始露头；精密星历是事后产品，精度到 2.5～5 厘米，长基线必须用。

这个选择直接影响两个软件的可比性——一个用广播、一个用精密，数字差再大也不说明任何问题。我是这么做的：短基线对比统一用广播星历，模拟实际生产环境；长基线或高精度场景统一用最终精密星历，并给两个软件喂完全相同的 SP3 文件。注意 SP3 文件里可能包含多个系统轨道，要检查两个软件读取的系统数和星历钟差是否一致。

3.4 最小实操：统一文件格式与坐标输出

商用软件输出格式差异很大，有的给 XYZ，有的给 BLH，有的给站心坐标系，还有的单位是度分秒。对比前用一个小脚本统一成同一格式，可以省掉之后所有麻烦。下面是我常用的预处理脚本核心段。

# 统一坐标输出格式：把不同软件的结果转成标准文本 # 输入示例：软件A输出 NEU 分量，软件B输出 BLH import re def normalize_solution(text: str, source: str) -> dict: """ 解析软件输出文本，返回统一格式: { 'station': '站名', 'x': 0.0, 'y': 0.0, 'z': 0.0 } """ sol = {} if source == 'A': # A软件输出形如: NEU_station deltaN deltaE deltaU m = re.search(r'NEU_(\w+)\s+([-\d.]+)\s+([-\d.]+)\s+([-\d.]+)', text) # 简化处理: 这里假设 A 输出的是相对于已知点的增量 sol['station'] = m.group(1) sol['delta'] = (float(m.group(2)), float(m.group(3)), float(m.group(4))) elif source == 'B': # B软件输出形如: station X Y Z m = re.search(r'(\w+)\s+([-\d.]+)\s+([-\d.]+)\s+([-\d.]+)', text) sol['station'] = m.group(1) sol['x'] = float(m.group(2)) sol['y'] = float(m.group(3)) sol['z'] = float(m.group(4)) return sol

这段逻辑很简单，就是把两边的文本输出收拢到同一个字典结构里。注意正则表达式的星号、锚点细节，真实软件输出里站名和数字之间可能有多个空格，用\s+而不是单个空格。我建议把这段脚本扩展成一个小模块，专门处理三家软件各自的注释头、单位标记和参数统计段落，这样后续批量处理时不用每次改正则。

4. 用脚本把对比跑起来：结果解析与 NRMS、重复性统计

4.1 结果解析：别靠肉眼抄数字，写个解析器

商用软件的结果文件长得千奇百怪，有的带表头、有的用空格分列、有的单位是度不是弧度。肉眼抄数字最不靠谱，一是抄错行，二是单位换算错。我把解析逻辑分成两步：先解出测站坐标和固定率，再解出基线向量。

解析思路概括为：按行扫描，匹配关键字所在行，抽取关键字后面的数值列。写代码时有一个容易被绊倒的地方，就是两个软件一个用科学计数法一个用普通小数，统一用正则[+-]?\d*\.?\d+(?:[eE][+-]?\d+)?抽取所有数值。

4.2 计算脚本：NRMS、RMS、重复性一次算齐

拿到坐标之后，就能跑指标计算了。下面这段代码完成三件事：把地心直角坐标差值转到站心 NEU、计算 RMS、计算基线重复性。

# 精度对比指标计算脚本 import numpy as np def ecef_to_neu(dx, dy, dz, lat_deg, lon_deg): """ 地心直角坐标差 (dX,dY,dZ) 转到站心 (dN,dE,dU) lat/lon 是参考站的经纬度 """ lat, lon = np.deg2rad(lat_deg), np.deg2rad(lon_deg) sin_lat, cos_lat = np.sin(lat), np.cos(lat) sin_lon, cos_lon = np.sin(lon), np.cos(lon) dN = -sin_lat * cos_lon * dx - sin_lat * sin_lon * dy + cos_lat * dz dE = -sin_lon * dx + cos_lon * dy dU = cos_lat * cos_lon * dx + cos_lat * sin_lon * dy + sin_lat * dz return dN, dE, dU def rms(values): """RMS = sqrt(mean(v^2))，用于衡量偏差的典型大小""" return float(np.sqrt(np.mean(np.square(values)))) def baseline_repeatability(lengths_m): """ 基线重复性: 多时段解算长度的标准差 / 平均长度 返回 (标准差, 相对 ppm) """ arr = np.array(lengths_m) std = float(np.std(arr, ddof=1)) mean = float(np.mean(arr)) return std, std / mean * 1e6 # 示例：两组软件解算的 dN/dE/dU 列表，单位米 dN_a, dE_a, dU_a = [0.004, 0.005, 0.003], [0.003, 0.002, 0.004], [0.008, 0.010, 0.009] dN_b, dE_b, dU_b = [-0.002, -0.001, 0.001], [0.001, 0.002, 0.000], [0.002, 0.003, 0.001] print("软件A 平面RMS:", rms(dN_a + dE_a), "高程RMS:", rms(dU_a)) print("软件B 平面RMS:", rms(dN_b + dE_b), "高程RMS:", rms(dU_b))

这段代码里的ecef_to_neu是最容易写错的函数，旋转矩阵的行列顺序跟参考椭球的定位有关。我推荐直接抓取参考站的已知经纬度作为旋转参数，这比用待定坐标稳定得多，因为偏差量只在毫米到厘米级时，经纬度取值的微小差异不会影响结果。baseline_repeatability算出来的 ppm 值可以直接对标厂商标称精度，比如标称「5mm + 1ppm」，基线 200 公里时允许误差就是 205 毫米，这个数在长基线工程里经常被大家记错。

4.3 用统计口径说结论：均值、最大值和分布都要看

只报 RMS 是远远不够的。我通常会看三个统计量：RMS（典型偏差）、最大值（最差时段）、符号偏向（正负偏差的分布）。如果是正态分布的偶然误差，正负应该大致对称；如果符号明显偏向一边，哪怕 RMS 很小，也说明存在系统性误差——通常指向坐标框架或对流层模型。

还有一个判断技巧：把同一时段的两个软件解算结果做差值时间序列。如果差值曲线呈现明显的周期波动，周期接近卫星轨道重复周期（约 1 天），说明某个软件的某些时段没有正确修复周跳，导致相位模糊度解算不一致。这种情况光看 RMS 看不出问题，但画出来立刻暴露。

5. GNSS 精度对比的五个坑：现象、原因和对应的解决

5.1 坐标框架不一致，整体偏移 2 厘米

现象：两台软件解算的坐标都通过了单点检核，误差都在 5 毫米内，但两套坐标之间的差值高达 2 厘米，并且所有测站差值方向一致。 原因：A 软件默认输出 ITRF 参考历元坐标，B 软件输出了观测历元坐标，板块运动改正没有对齐。 解决：在两边输出文件里查找参考框架和历元字段，没有字段的就手动加上已知的框架转换参数。最容易的办法是：两套结果统一转到同一历元的同一框架之后再对比，不要直接拿原始输出比。

5.2 模糊度固定率虚高，假固定骗过所有人

现象：某软件报告固定率 99%，但坐标解算结果比另一家浮点解还差，固定率越高偏差反而越大。 原因：模糊度固定的检核阈值没开，或者 Ratio 检验阈值设得太低，把大量未收敛的模糊度「硬固定」了。 解决：检查固定策略里的 Ratio 阈值，静态解算没有特殊理由不要低于 3.0；同时打开验后方差检验。对比时把两家软件的检验阈值统一，并在报告里注明判断标准。

5.3 天线相位中心模型不一致，高程差出 1.5 厘米

现象：平面方向两个软件几乎一致，高程方向稳定差出 1.5 厘米左右。 原因：一个软件默认使用绝对相位中心校正（PCC），另一个软件默认使用相对相位中心模型，再加上天线罩参数读没读对，叠加起来就是厘米级。 解决：统一使用同一份 ANTEX 天线相位中心文件，并检查测站天线类型和天线罩类型是否一致。特别提醒：天线类型写错一个字，改正值就会变成另一个型号的数据，这种错最难查。

5.4 对流层参数不一致，长基线高程被系统性吃低

现象：基线超过 80 公里时，高程方向误差与基线长度强相关，误差还全是负值。 原因：两个软件对天顶湿延迟的处理不同，一个在估计湿延迟，另一个只做了干延迟模型改正；或者映射函数不同导致高仰角权重分配不一致。 解决：长基线对比统一设置「估计天顶湿延迟 + 梯度」，并且两个软件使用相同的气象标准大气参数。如果还不放心，可以额外输出对流层估计值，数值差超过 3 毫米就得回头查参数。

5.5 参考站选取不一致，网成果直接不闭合

现象：同一条基线，A 软件解算结果比 B 软件长 4 毫米，反过来用 B 软件解另一条基线又不闭合；对照 CORS 参考站也不吻合。 原因：软件开发者在参考站自动选取逻辑上有差异，有的默认选最近的 3 个站，有的选观测质量最好的 5 个站，导致网型不同。 解决：对比实验统一手动指定同一组参考站，关闭自动选站。检查选站时顺便看一眼参考站自身的多路径指标，超过某阈值就换成备用站。

6. 把交叉对比变成交付前的例行检查

上面的流程跑通之后，我把这个对比方案做成了一个接近半自动的检查流程，现在每次交付前多花十分钟就能跑完。核心就三步：先跑脚本出指标，再按阈值自动判读是否合格，最后把两套软件结果差异超过阈值的点单独挑出来人工复核。

这里有一个很实用的技巧：与其每次手动比数字，不如给两个软件的解算差值设一个硬门槛。平面差超 8 毫米、高程差超 1.5 厘米时自动告警，超过阈值的一律不合并出报告，先排查是参数问题还是数据问题。写一个简单的 bash 判断就能完成：

# 检查 A/B 两套解算结果的高程差是否超限 # 第3列是高程(单位 m)，第4列是测站名 awk '{if ($3 - prev > 0.015) print "高程超限:", $0, "差值=", $3 - prev}' \ <(paste <(grep -P ".*" dis_A.txt) <(grep -P ".*" dis_B.txt))

这个命令把两套结果按站逐行拼接，直接比较差值。awk 里$3 - prev的写法是简化的示意，真实场景建议写一个 python 脚本做稳健的比较。重点不在命令本身，而在「阈值判读」这个习惯：把对比从人的肉眼判断变成自动化检查，结果更可靠也更能追溯。

我现在的习惯已经固定下来：只要换一版星历、改一次参数配置或者换一个商业软件版本，都会先把同一组静态数据用 A/B 两套软件跑一遍交叉对照，确认差值在阈值内才动项目数据。这个方法帮我挡掉过至少三次让成果返工的隐患。精度对比不是要找「最准的软件」，而是要找到「在你自己参数口径下、结果最可控的方案」。希望帮到你。

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