摘要：rtklib_java 项目所有定位模式测试已全部完成。本文记录 PPP-RTK 接入 SSR 实时流联调期间发现的两处关键 Bug、修复方案以及 WUH20 实测对比结果。
一、测试背景
rtklib_java 是基于 RTKLIB 2.5.0 demo5 移植增强的 Java 版本 GNSS 解算库。当前全定位模式测试收尾阶段，接入 SSR 实时流开展 PPP-RTK 验证，测试中暴露两个和 BDS 适配相关的底层问题，直接影响模糊度固定率和解算稳定性。
原生 RTKLIB PPP 模块设计偏向 GPS、Galileo，对 BDS-2 信号槽位布局缺少适配，存在隐蔽缺陷。
移植的功能一直没有SSR陷入了等待，今天拿到了CAS账户的权限，接入SSR测试功能。没有预想的顺利，果然实践出真知。
二、Bug1：BDS-2 MW 宽巷组合无法生成【FIX-ALG-037】
根因
detslp_mw() 硬编码采用 code[0]+code[1] 构造 Melbourne-Wübbena 宽巷组合。
- GPS：L1 (0)+L2 (1)、GAL：E1 (0)+E5a (1)，匹配；
- BDS-2：B1I 在槽 0，B3I 在槽 3，不在槽 1，配对失效。
后果：BDS-2 无法形成合法 MW 组合，宽巷模糊度不能累积，AR 模糊度固定失败，退化为浮点 PPP 解。
MW 公式：
\(MW = \frac{f_1 L_1 - f_2 L_2}{f_1-f_2} - \frac{f_1 P_1 + f_2 P_2}{f_1+f_2}\)
修复方案
新增 PppCore.mwFreqIdx() 自动选频函数：
- GPS/GAL：保留原有
code[0]+code[1]逻辑，向下兼容； - BDS 分支：遍历所有观测槽位，优先选取 B1I+B3I 信号对，优先频差最大的有效频率组合。
优化效果
BDS 可用宽巷卫星：14 颗 → 17 颗 MW 组合失败跳过历元：10/119 → 5/119
三、Bug2：异常卫星导致 PPP-RTK 初始化死循环【FIX-ALG-038】
根因
BDS sat=107 出现粗差，初始伪距 - 载波偏差高达 372m（正常 ±20m 以内），卡尔曼滤波持续无法收敛，每历元重复触发卫星初始化，形成死循环，消耗算力、压低固定解数量。
修复：三层熔断防护
- 500m 粗差阈值校验，超阈值直接跳过初始化；
- 前 10 历元拒绝次数计数；
- 短时间内拒绝次数超限 → 永久冻结该卫星，不再参与后续解算，直到会话重启。
优化效果
异常持续影响历元：119 → 7 AR 固定解数量：78 → 92
四、实测数据
测试条件：WUH20 SSR 实时流，119 历元，BDS+GPS+GAL 三系统 PPP-RTK
表格
| 指标 | 修复前 | 修复后 |
|---|---|---|
| BDS 可用宽巷卫星 | 14 颗 | 17 颗 |
| sat=107 异常历元 | 119 | 7 |
| AR 固定解总数 | 78 | 92 |
| ENU 精度 | E=2.1cm, N=2.8cm, U=5.1cm | E=1.9cm, N=2.6cm, U=4.8cm |
- 本次两项修复均隔离生效，不破坏 GPS、Galileo 原有解算逻辑；
- RTKLIB 原生大量下标硬编码默认基于 GPS 假设，移植 BDS-2 时 MW、IF 等观测组合是高频踩坑点；
- PPP-RTK 对伪距载波粗差敏感，仅靠常规粗差探测不够，需要卫星级熔断机制防止单颗坏卫星拖垮整网；
- 至此 rtklib_java 全部定位模式测试完成，PPP-RTK 接入 SSR 实时流功能验证通过。