1. v10.75 在多系统解算里的真实位置我接触过不少做形变监测和地壳运动分析的小团队提起北斗数据处理第一反应是买一套商业软件或者干脆用开源方案凑合。真到要出毫米级坐标的时候才发现能算出结果和算得准完全是两码事。GAMIT/GLOBK v10.75 这套老牌 GNSS 数据处理软件在北斗时代的价值恰恰在于它把每一处误差源都摊开给你看、也允许你逐项关掉或者改正——这对追求数据处理精度的人来说是缺点也是最大的优点。它不像某些一站式软件那样把参数全藏在界面后面你配置里少写一行结果里就会多出几毫米的偏差而你能通过残差把它追回来。先说清楚这套东西适合谁。如果你做的是厘米级导航定位、车载监控、普通 RTK 放样那它对你来说属于杀鸡用牛刀配置成本远大于收益。但如果你的活儿是区域地壳形变监测网、大型构筑物健康监测、高精度大地控制网复测、卫星轨道测定支撑需要出的是亚厘米甚至毫米级的日均坐标和速度场那 GAMIT/GLOBK 至今仍是绕不开的选项之一。它的核心逻辑是双差解算加单日松弛解、再用卡尔曼滤波做多天联合平差这条链路本身没有秘密秘密全在配置文件和表文件里。1.1 从能不能算北斗到算得准不准中间隔着什么GAMIT 对北斗的支持是分阶段推进的。早期版本里北斗只是一个可选系统卫星编号、信号类型、天线改正都还处在能用但不够精细的阶段。到 v10.75 这个版本北斗三号的 MEO 和 IGSO 卫星基本都能正常纳入解算B1I 和 B3I 这对经典组合的处理流程已经比较成熟B1C 和 B2a 这些新信号在 RINEX 3 观测文件里也能被正确识别和组合。这是硬件和文件格式层面的进步但离精度提升还有相当距离。真正的差距体现在三个地方。第一是观测值权重北斗的伪距噪声和载波噪声特性跟 GPS 不完全一样尤其 B1I 信号在某些接收机上的码噪声明显偏大如果直接套用 GPS 的默认权重解算出来的法方程会被拉偏。第二是卫星几何构型北斗二号那几颗 GEO 卫星位置几乎不动高度角变化范围极小观测几何非常差强行纳入解算会让法方程条件数变坏残差看着不大但坐标被悄悄拖走。第三是时间和坐标框架的一致性北斗系统时和国际通用时间系统之间差着一个固定量这一点处理错了整天的数据都会错位。我用过一套老配置跑北斗数据NRMS 看着是 0.28 左右属于看起来还行的水平但把同一批站点的 GPS 单独解拿出来对比东西向重复率差了将近一倍。后来逐项排查问题出在两处一是 station.info 里天线类型写的是厂家型号简称跟天线改正表里的标准名称对不上程序默默退回到默认相位中心高程方向偏了两三厘米二是 sestbl. 里多系统开关虽然打开了但随机模型那一栏还是 GPS 的默认值。改完之后 NRMS 降到 0.19东西向重复率从 6 毫米进到 3 毫米出头。这个教训说明一件事多系统支持是能算随机模型和表文件才是算准。1.2 精度账本误差源清单与可控项排序在动手改配置之前先得知道自己手上这笔账怎么算。我把影响北斗数据处理精度的因素按可控程度和影响量级做了个粗略排序这个排序是多年折腾下来形成的经验判断不是严格的误差传播推导但对排优先级很管用。误差源典型影响量级是否可控主要控制手段天线相位中心与天线高毫米到厘米完全可控atx 表 station.info 精确匹配卫星轨道与钟差产品毫米到厘米完全可控换用多系统精密产品、注意产品覆盖的卫星时间系统错位分米到米级完全可控检查 RINEX 时间标签与处理时标对流层延迟模型毫米到厘米高度可控映射函数选型 天顶延迟估计间隔电离层高阶项毫米级部分可控双频无电离层组合 二阶项改正潮汐与负荷形变毫米到厘米高度可控固体潮、海潮、极潮、大气负荷开关多路径与环境效应毫米到分米部分可控高度角截止、加权、站点选址北斗 GEO 卫星几何毫米到厘米可规避降权或直接剔除这张表里最容易被低估的是第三行。时间系统出问题的时候程序不报错解算照常跑完残差也在可接受范围内但坐标就是不对而且不同方向的偏移还不一样非常迷惑人。第二容易被低估的是第一行很多人觉得天线信息填个大概就行实际上相位中心偏差在水平方向可能有几毫米垂直方向能到厘米级而且不同厂家、不同型号之间差异很大靠估是估不出来的。至于轨道产品的影响我个人的经验是对于几百公里尺度的区域网事后精密星历和快速星历之间的差异对基线重复率的影响通常在亚毫米量级不值得花时间去纠结但如果你的网跨度超过一千公里或者做的是高精度定轨支撑那产品选择就值得认真对待了不同分析中心的多系统产品在北斗卫星的处理策略上差别不小。2. 编译与运行环境装不上的九成原因不在源码我见过太多人在第一步就卡死。GAMIT/GLOBK 的安装脚本是交互式的问一堆问题选错一个后面全乱。更麻烦的是它的报错信息往往指向症状而不是病因cannot find -lX11这种还算直白undefined reference to xxx_这种就得靠经验了。这一节把环境准备里最容易翻车的几个点拎出来说。2.1 编译器、库与shell的最小组合这套软件的代码主体是 Fortran 加一部分 C历史包袱很重对编译器的宽容度不高。我试过在几个不同发行版上装最后稳定下来的一套组合是这样的# 以常见的 Debian 系为例依赖包一次性装齐 sudo apt update sudo apt install -y gfortran gcc make csh tcsh \ libx11-dev libxext-dev libxmu-dev libxt-dev \ libncurses5-dev liblapack-dev libblas-dev \ python3 python3-numpy注意几个细节。第一csh和tcsh必须装GAMIT 的sh_系列脚本大量依赖 csh 语法没有它连脚本都跑不起来。第二X11 相关的开发库要装全很多人只装了libx11-dev结果链接阶段报一堆-lXmu、-lXt找不到。第三LAPACK 和 BLAS 建议装系统的开发包虽然软件自带了一份参考实现但系统优化的版本在平差环节能省不少时间。至于编译器版本这是个玄学问题。太老的 gfortran 不支持某些语法太新的又会对一些历史代码报错。经验上gfortran 9 到 12 这个区间比较稳。如果你用的是更新的版本编译时可能会遇到参数不匹配的报错可以在编译选项里加上-fallow-argument-mismatch这个宽容开关绕过去。这个开关治标不治本但对这种历史代码库来说是性价比最高的做法。安装过程本身是用install_software脚本跑的交互式问答里最关键的是几个路径配置和 X11 库的位置。我的建议是第一次装的时候全部用默认值装完能跑通再说优化。很多人一上来就改安装路径改到带空格的目录下然后被各种路径解析问题折磨一整天。2.2 三类高频编译报错的具体定位手法下面这三种报错我见过太多次直接把定位路径写出来照着查就行。第一类链接阶段找不到 X11 库。报错形如cannot find -lX11或者undefined reference to XOpenDisplay。这时候别急着怀疑装没装先用find / -name libX11*确认库文件到底在哪。如果库在/usr/lib/x86_64-linux-gnu/下那问题就是编译配置里的库路径没指对。回到install_software里把 X11 的库目录改成实际路径重新跑一遍。第二类Fortran 模块编译顺序出错。报错形如Cannot open module file xxx.mod。GAMIT 的源码依赖关系写在一堆 makefile 里正常情况下会自动排序但如果你改动过源码目录结构或者缺了某个子目录顺序就会乱。最快的排查方式是去libraries/和gamit/目录下分别看makefile里列出的源文件是不是都存在缺一个就会连带后面全崩。第三类大小写敏感导致的符号未定义。在 Linux 下这个特别常见报错形如undefined reference to sio_open_。Fortran 默认会给符号加下划线如果某处编译选项里加了-fno-underscoring符号就对不上了。这个选项在配置文件里是全局生效的翻一遍Makefile.config里的FFLAGS和CFLAGS把可疑的选项去掉重编。提醒编译之前先把Makefile.config备份一份改坏了直接还原比逐行回滚快得多。环境装好之后建议立刻做一次冒烟测试——用官方示例数据跑一遍单日解算确认从数据准备、解算到平差的整条链路都通。这一步花的时间不多但能把环境问题和配置问题彻底分开省下后面大量的扯皮时间。3. 北斗数据的输入准备从RINEX到可解算目录环境通了之后下一个拦路虎是数据。GAMIT 对输入数据的目录结构和命名有严格要求一个字符不对就是找不到文件。而北斗数据又比 GPS 多几层麻烦主要是文件格式、卫星编号和时间系统三件事。3.1 观测、星历、钟差的配对与命名规则GAMIT 处理一天的数据需要几类文件同时到位观测文件RINEX 2 或 3、广播星历、精密星历、精密钟差、地球自转参数、天线改正表、海潮负荷文件、站信息表。这些东西的存放位置在process.defaults里配置默认的目录结构是expt、brdc、igs、tables这几层。命名上最容易出错的是测站名。GAMIT 内部用 4 字符站名而 RINEX 3 文件里是 9 字符站名加年份天数的长文件名。转换靠sh_rx2apr和sh_get_nav这些脚本但脚本认的是你在sites.defaults里登记的 4 字符名。我见过有人直接把ABCD00CHN_R_20230010000_01D_30S_MO.rnx丢进目录就开跑结果程序一直在找abcd0010.23o当然找不到。正确的做法是在sites.defaults里把 9 字符名和 4 字符名的对应关系写清楚然后用脚本批量转换# 把当天所有 RINEX3 观测文件转成 GAMIT 认识的短名格式 sh_rx2apr -site sites.defaults -nav brdc0010.23n -apr apr0010.23 # 批量把 RINEX3 观测转 RINEX2部分老流程需要 for f in *.rnx; do gfzrnx -finp $f -fout ${f%%.rnx}.23o -vo 2 done北斗数据还有个特殊之处RINEX 3 里北斗的观测类型标识和 GPS 不一样B1I、B3I、B1C、B2a 各自有独立的观测码。如果你的观测文件是精简过的版本只保留了部分观测类型那在 sestbl. 里配置频点组合之前先用teqc qc或者gfzrnx -freq看一眼到底有哪些观测值别配置了半天发现数据里根本没有这个频点。3.2 表文件更新的优先级atx、station.info、海潮表文件这一块我的建议是按影响量级排序处理别一上来就追求完美。天线改正表atx排第一。这个直接影响坐标而且影响的是系统性偏差不是随机误差重复率指标看不出来但绝对坐标是错的。用绝对相位中心模型的时候接收机和卫星天线都要查表北斗卫星的天线相位中心在早期产品里可能缺失这时候要么换用包含北斗卫星改正的产品要么在配置里明确说明按零处理并接受相应偏差。这个取舍必须记录在你的处理日志里不然以后没法复现。站信息表station.info排第二。每一行对应一个测站一个时段的天线类型、天线高、接收机类型、量取方式。天线高的量取方式分垂直和斜距两种写错会引入固定偏差。GAMIT 有个sh_gamit -update的选项可以根据观测文件头自动生成这个表但自动生成的东西经常不完整天线序列号缺失、天线类型写成厂家简称都得手工核对一遍。我一般的做法是自动生成之后用脚本对比一遍头文件里的原始字段把不一致的挑出来人工确认。海潮负荷文件排第三。在沿海站点这个影响能到厘米级内陆站点通常只有毫米级。用otl.grid配合全球海潮模型配置里把开关打开就行。需要注意的是这个改正跟站点位置强相关如果你的站点在内陆深处为了省时间关掉也问题不大但沿海站点一个都不能漏。极潮、大气潮、非潮汐海洋负荷这些影响量级更小做高精度速度场的时候值得打开日常单日解可以酌情。这就是典型的性价比问题——打开不费多少事但会对结果产生一个虽然小但系统的偏移。3.3 时间系统这一关BDT与GPST的14秒这个坑我踩过而且踩得很难看。北斗系统时和 GPS 时之间有一个固定差值北斗时间起点是 2006 年 1 月 1 日两者之间相差 14 秒。RINEX 3 观测文件的文件头里有明确的时间系统标识正常情况下解算软件会自动处理这个转换但在几种情况下会出问题一是 RINEX 2 格式的老数据时间标识不明确二是自己拼装数据或者转换格式的时候时间标签被原样拷贝过去三是混合系统解算时不同系统的时间标签被统一当作一种处理。时间错 14 秒的后果是什么卫星位置会算错因为精密星历是按正确时间给的你拿错位的时间去插值卫星位置就偏了几十公里量级然后所有的残差都爆炸解算要么不收敛要么收敛到一个完全错误的结果上。更麻烦的是如果时段边缘的观测被截断表面上看解算还能跑完NRMS 可能只是略微偏高很难一眼看出问题。排查方法很直接解算之前在观测文件里抽查几颗北斗卫星的信噪比序列看峰值位置是不是和 GPS 卫星的仰角变化对得上。如果整个序列平移了十几秒那就是时间标签的问题。另一个办法是看广播星历和精密星历的钟差对比如果北斗卫星的钟差残差出现一个恒定的巨大偏移基本可以锁定是时间系统错位。# 快速检查观测文件头里的时间系统标识 grep -i TIME SYSTEM *.rnx # 检查北斗卫星的观测时段是否与 GPS 卫星一致 gfzrnx -finp obs.rnx -fout /dev/stdout -satsys C | head -50还有一种情况更隐蔽解算时段跨越了日界而脚本在切分数据时按整点切导致北斗数据的时段和 GPS 数据的时段错开。这种问题在残差里表现为边缘卫星的残差特别大而且总是集中在时段两端。处理办法是统一用同一条时间轴切片或者干脆把解算时段缩短到避开日界。4. sestbl. 配置逐项拆决定精度的六个开关配置文件是整个流程的核心sestbl.这张表里每一行都在回答用什么模型、用不用改正、怎么加权这三个问题。我把它拆成六组来看每组对应一类误差源。4.1 观测模型与频点组合的选择依据观测模型这一行Choice of Observing Model决定了用什么组合去组双差观测值。对北斗来说最常用的是双频无电离层组合这一组可以消掉电离层一阶项代价是观测噪声被放大到单频的三倍左右。频点怎么选北斗二号时期主流是 B1I 加 B3I这两个频点的组合波长、噪声特性都比较均衡精密产品也齐全。北斗三号上来之后B1C 和 B2a 成了新选择好处是这两个频点和 GPS 的 L1、L5 频率非常接近联合解算时大气延迟的相关性更好处理坏处是有些老接收机不支持或者支持了但观测值质量参差不齐。我的一般原则是看你的精密产品覆盖了哪些频点用覆盖最完整的那个组合而不是追求理论最优。还有一点值得提北斗不同频点之间的码偏差DCB差异比其他系统明显一些如果产品里提供了对应的偏差改正文件配置时要挂上去如果没提供在卫星权重上就要保守一点宁可降权也不要让偏差污染法方程。4.2 电离层、对流层的处理策略与取舍电离层这一块双频无电离层组合能消掉一阶项二阶项影响在毫米量级做超高精度的时候值得用 IONEX 文件补上日常应用可以忽略。配置里对应的是电离层模型的选择项选 RINEX 电离层文件的时候要注意文件的时空覆盖范围能不能盖住你的测区。对流层是另一个大头。映射函数的选择直接决定天顶延迟到斜向延迟的转换精度常用的有几种全球映射函数新一代的在低高度角表现更好。我的配置习惯是映射函数用新版的天顶延迟按固定间隔估计间隔不要太密。估太密会让法方程自由度被吃掉解不稳定估太疏又跟不上大气变化。经验值是每两小时估一个天顶延迟参数再叠加一个水平梯度参数这个配置在大部分地区的效果都不错。对流层的先验值来源也要注意。标准大气模型给的先验值在平原地区够用但在高原或者剧烈天气变化的时候偏差不小。如果测区有气象观测数据把实测的气压、温度、湿度接进去能明显改善解算质量。4.3 潮汐与负荷改正的开关这一组开关经常被忽略但它们影响的是系统性偏差。固体潮是必开的影响量级能到几十厘米不开的话结果完全不能用。海潮负荷前面说过沿海站点必须开。极潮影响在毫米量级高精度解算建议打开。大气潮和非潮汐海洋负荷影响更小做速度场的时候打开单日解可以放过。配置里还有个细节海潮负荷文件的格式和插值方式。有些产品给的是格网形式有些给的是站点系数形式配置时对应不同的读取方式。如果格式对不上程序可能不报错但改正值为零等于没开。验证方法很简单把开关打开前后各跑一次对比坐标差异如果差异为零说明改正没生效。4.4 截止高度角、采样间隔与随机模型截止高度角这个参数默认值通常是 10 度或 15 度。设得太低低高度角观测的多路径和大气误差大但能增加观测量设得太高观测量减少几何构型变差。对北斗来说因为 GEO 卫星高度角本身就低如果截止角设得太高可能把 GEO 卫星全部剔掉反而让多系统解算退化成 GPS 单系统。我的建议是截止高度角设 10 度但对低高度角的观测单独降权而不是一刀切剔除。降权的手段是在随机模型里把高度角相关的权函数调陡一些让低高度角观测的权重自然降下来。采样间隔方面30 秒采样对静态解算足够了用 1 秒数据不但不会提升精度反而会让法方程规模暴增处理时间翻好几倍。如果是为了捕捉快速形变那另当别论。随机模型这一块是提升北斗解算精度最有效也最容易被忽略的地方。标准做法是按高度角定权但不同系统的观测噪声不同北斗的码观测噪声普遍比 GPS 大一些如果沿用同一套权函数北斗的观测会被过度信任。合理做法是给不同系统设置不同的权因子或者在同一个系统内部按信号类型分别定权。5. GLOBK 平差把单日松散解变成可交付坐标单日解算出来的只是一个松弛解站点坐标还带着框架约束的自由度而且每天的解是独立的。要把它们变成一条可用的坐标时间序列得靠 GLOBK 这一层的卡尔曼滤波平差。5.1 h文件合并与glred/glorg的分工每一天解算完会生成一个 h 文件里面存的是法方程信息和先验约束。GLOBK 读入多个 h 文件做联合平差。这里有两个脚本经常被混淆glred做的是重复性分析输出的是每天的解和统计量glorg做的是框架约束和坐标合成输出的是最终坐标。流程一般是先跑glred看重复率确认单日解质量没问题再跑glorg做框架约束。顺序反了会很痛苦因为框架约束会把单日解的异常平均掉你看到的重复率是被平滑过的看不出问题。# 第一步合并当天所有 h 文件做重复性检查 glred 6 globk_comb.cmd glorg_comb.cmd hfile.list globk_rep.out glorg_rep.out # 第二步加入框架站点做约束输出最终坐标 glorg 6 glorg_comb.cmd globk_rep.out glorg_final.outh 文件列表的生成也有讲究日期的排序会影响滤波的初始化。如果顺序乱了卡尔曼滤波的初始状态估计会偏前面几天的解质量会明显差于后面几天。5.2 框架约束的两段式做法框架约束这一步我的习惯做法是分两段。第一段用松弛约束跑也就是只对少数几个核心站做强约束其余站点自由。这一步的目的是检查整个网的内部一致性看有没有站点跟其他站点系统性不一致。如果某个站的残差一直偏大说明这个站本身有问题可能是天线信息错了可能是多路径严重也可能是站点发生了真实的形变。第二段用强约束跑把所有参与框架定义的站点都约束住输出最终坐标。这一段的约束策略要跟你的应用场景匹配做形变监测的话约束要松一些保留形变信号做绝对坐标的话约束要紧一些保证框架一致性。框架站点的选择也影响结果。用少量站点定义框架容易受个别站点异常影响用大量站点又容易把区域性的形变信号引入框架。经验做法是选分布均匀、观测历史长、稳定性好的站点数量在十个以上并且用赫尔默特转换参数做一致性检验。5.3 时间序列里的阶跃、粗差与站点异常坐标时间序列出来之后不可能直接拿来用。里面会有阶跃、粗差、周期性的系统误差。阶跃的来源很多天线更换、接收机固件升级、站点周边施工、甚至地震。这些事件如果没有在平差时标记出来会被当成真实的形变信号污染速度场估计。处理方法是在glorg的控制文件里按日期插入阶跃参数让滤波在阶跃前后分段估计。粗差相对好处理看每天解的残差超过阈值就标记剔除。麻烦的是那些看起来正常但系统性偏低的站点残差不大不小剔除可惜保留又影响整体。这种情况我一般会回到单日解算环节去查八成是表文件或者权重的配置问题。还有一类异常是季节性的坐标在一年内呈现周期性起伏幅度能到几毫米。这些主要是大气负荷、地下水变化、热膨胀引起的处理办法是拟合年周期和半年周期项把它们从残差里分离出去。6. 结果验收用哪几个指标判断精度真的上去了调了半天参数总得有个客观标准判断到底有没有用。我一般看三个指标再加上一轮人工的残差图谱检查。6.1 NRMS、模糊度固定率、重复率三件套NRMS 是最直接的指标反映的是单位权中误差。经验上GPS 单系统静态解算能做到 0.15 到 0.20北斗单系统通常略差一些混合系统如果处理得当应该在 0.15 到 0.25 之间。但如果出现 0.12 以下的异常低值反而要警惕可能是观测值被过度平滑或者是权重设置把大部分观测值压得没贡献了。模糊度固定率比 NRMS 更能反映解算质量。北斗的宽巷模糊度固定相对容易窄巷固定难度大一些尤其是 GEO 卫星的窄巷固定率通常明显低于 MEO 和 IGSO。如果发现整体固定率低但 NRMS 还行说明解算收敛到了一个看起来合理的浮点解精度上限被卡住了。这时候该回头检查观测值质量和周跳修复。重复率是最贴近实际应用的指标反映的是相邻几天解算结果的一致性。东亚地区的区域网水平方向做到 2 到 4 毫米、垂直方向 5 到 8 毫米属于比较理想的水平。如果北斗参与解算之后重复率反而变差那基本可以确定是多系统联合的权重没配好。指标合格线良好需要排查NRMS0.30 以下0.15-0.22超过 0.35 或低于 0.12宽巷固定率80% 以上90% 以上低于 70%窄巷固定率60% 以上75% 以上低于 50%水平重复率5 毫米以内3 毫米以内超过 8 毫米垂直重复率10 毫米以内6 毫米以内超过 15 毫米6.2 异常残差谱与根因对照表指标能告诉你有问题但不能告诉你是什么问题。残差图谱才能。我一般看三张图残差随高度角的分布、残差随时间的分布、残差随卫星的分布。残差随高度角分布的形状能直接反映权函数是否合理。如果低高度角残差明显偏大但没有被降权图上会看到一个翘起的尾巴。如果降权过度尾巴被压平了但整体残差反而上升说明正常观测被误伤。残差随时间的分布能看出时段性问题。开头和结尾残差大通常是数据边缘效应或者初始状态估计不准。中间突然变大多半是周跳没修好或者发生了多路径。残差随卫星的分布是北斗解算里最需要看的一张图。如果某几颗卫星的残差系统性偏大而且是固定那几颗很可能就是 GEO 卫星。残差特征可能根因排查方向残差整体偏大且无规律权重设置不当调整随机模型、按系统分别定权低高度角残差呈翘尾权函数太平缓加陡高度角相关权函数特定卫星持续偏大GEO 卫星或天线改正缺失检查卫星类型、降权或剔除时段两端残差偏大边缘效应、初始状态前后各留半小时缓冲残差随时间出现台阶周跳修复不完整重跑周跳检测降低阈值系统性南北向偏移天线相位中心或框架不匹配核对 atx 表和框架版本7. 几个反复咬人的坑前面几节讲的是应该怎么做这一节讲哪里容易做错。这些都是我在实际项目里反复撞上的写下来省得别人再撞一遍。7.1 天线高与相位中心的连锁错误天线这块有两个独立但经常同时出错的点。一是天线高的量取方式垂直量取和斜距量取差一个余弦因子天线高越大差异越明显三米高的天线斜距量和垂直量能差好几毫米。二是天线相位中心需要查表而表里的型号名称和厂家铭牌上的名称往往对不上。这两个错误叠加在一起的时候特别难查因为它们的量级相近、方向不同可能互相抵消一部分导致结果看起来还行。我的做法是每批新数据进来先单独用一种方式解算把天线改正全部关掉看坐标变化量如果变化量符合预期水平几毫米、垂直几厘米说明表文件正确如果变化量明显偏大或者方向反常那就是表文件有问题。还有一点更换天线之后的时间序列必须标记阶跃而且更换前后的天线类型要分别记录在 station.info 里。有些人图省事直接改了这个站的所有记录结果换天线之前的那些天解算出来的坐标全变了时间序列出现一个假的跳变。7.2 GEO卫星把法方程带歪北斗的 GEO 卫星是个绕不开的话题。它们的轨道倾角接近零在地面上看基本是静止的高度角变化范围可能只有几度。这意味着它们在解算中提供的几何信息非常有限但对流层延迟和模糊度的估计会强依赖这些低质量观测。处理方式有几种各有取舍。直接剔除最干净但会损失观测量降权保留能维持观测冗余但要小心权重给得太高还有一种做法是在解算时保留、在平差时降权这个更灵活。我的一般原则是区域网解算并且有足够的 MEO/IGSO 卫星时GEO 卫星直接剔除观测条件差、卫星数不足时降权保留。判断依据看解算报告里的卫星使用情况和法方程条件数。如果剔除 GEO 之后条件数明显改善、重复率也变好那就说明剔除是对的。7.3 跨日界与数据缺口跨日界的处理是个细活。观测数据按天切分的时候如果切分点选在整点那么前一天最后几分钟和后一天最初几分钟的观测会被丢弃。对于连续监测网这没什么影响但对于观测时段本来就不长的数据丢掉这几分钟可能就导致卫星几何构型变差。更麻烦的是数据缺口。北斗的同步轨道卫星在某些地区的观测可能出现规律性的中断尤其是低仰角时段。如果缺口正好落在解算时段中间程序会当作周跳处理但如果缺口太长可能直接导致该卫星被剔除。处理办法是在数据准备阶段就用脚本统计每颗卫星的观测连续性把可用率低于某个阈值的卫星提前标记出来在配置里主动降权或者剔除而不是等程序自己判断。这样至少结果是可控的也便于在报告里说明。还有一个小技巧解算时段前后各留半小时的数据作为缓冲虽然不参与最终解算但有助于周跳检测和初始模糊度估计的收敛。这个做法的代价是处理时间略有增加收益是边缘时段的解算质量明显提升。8. 配置之外的功夫流程化与可复现最后说一点偏工程的东西。这套软件的配置项太多靠手工改配置文件早晚会出错而且出了错很难回溯。我的做法是把整个处理流程脚本化每一批数据的配置文件和表文件都单独存档一份用日期和版本号命名。每次解算完成后把关键统计量NRMS、固定率、重复率、参与解算的卫星数写进一个日志表。这样跑上几个月之后翻开日志就能看出哪次改配置带来了实质提升哪次是白折腾。# 每次解算后归档配置并记录统计量 STAMP$(date %Y%m%d_%H%M) mkdir -p archive/$STAMP cp sestbl. sites.defaults process.defaults station.info archive/$STAMP/ grep -E NRMS|Ambiguity glorg_rep.out archive/$STAMP/summary.txt echo --- $STAMP done --- archive/$STAMP/summary.txt这套做法看起来笨但真到了要复现半年前某个结果、或者排查为什么这个月的数据质量突然变差的时候能救命。我吃过一次亏同一批数据跑了两次结果不一致查了两天才发现是中间有人改过station.info但没记录最后靠文件时间戳才定位到。还有一点是关于配置版本的。GAMIT/GLOBK 不同小版本之间的默认参数会变升级的时候一定要拿同一批数据跑一遍新旧对比看看关键指标有没有变化。别想当然认为升级就是变好有时候新版本的默认设置对某些应用场景反而不如老版本。我的习惯是升级之前先存一份当前版本的完整配置和一组基准数据的解算结果升级后立刻做对比差异超过预期就回退查原因。至于精度提升这件事本身我的体会是换版本、调参数带来的提升通常在百分之十几的量级而把表文件、时间系统和权重模型这三块彻底搞对提升能到一个数量级。北斗数据处理的门槛不在算法在细节谁把这些琐碎的东西一项项抠清楚了谁的结果就稳。
