RTK false-fix validation: PPC Nagoya run3 late-window bad FIX clusters

[rsasaki0109]

結論

• PPC Nagoya run3 late-window には false-fix cluster が残っており、validateFixedSolution() と fix reacquisition gate が十分に働いていない。
• まずは tow 554720.x, 554700.x, 554650.x, 554589.x を代表区間として、bad FIX を止める条件を詰める。

確認済み事実

• 再現条件は /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_nagoya_run3_lowcost_late2k_holdcfgfix.pos と /media/sasaki/aiueo/ai_coding_ws/datasets/PPC-Dataset-data/nagoya/run3/reference.csv。
• tow 554720.2 / 554720.4 は libgnss++ が FIX を出す一方、RTKLIB は FLOAT を維持する。
• hold threshold hardcode 修正後も false-fix は残っており、hold だけが主因ではない。
• ratio は誤解ではなく実際に threshold を超えている。例: tow 554720.2 は ratio=3.8。
• fixed-float jump は多くの bad FIX で小さく、bad FLOAT をそのまま FIX に昇格しているケースが多い。
• last_trusted / last_fixed ベースの単純なしきい値では Tokyo run3 の good reacquisition も巻き込む。

未確認/要確認項目

• validateFixedSolution() に追加すべき条件が位置系なのか整数整合性系なのか
• reacquisition 直後の FIX にだけ強めの validation を掛けるべきか
• dual-frequency DD を使った WL/MW consistency を RTK mode 全般に広げる価値があるか

次アクション

• /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/src/algorithms/rtk.cpp の validateFixedSolution() を中心に、bad FIX cluster の通過条件を特定する。
• tests/test_rtk_validation.cpp か /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/tests/test_rtk_legacy.cpp に regression test を追加する。
• Tokyo run3 late-window (skip=13301) で side effect を確認する。

再現コマンド

python3 apps/gnss.py ppc-demo \
  --dataset-root /media/sasaki/aiueo/ai_coding_ws/datasets/PPC-Dataset-data \
  --city nagoya --run run3 --solver rtk \
  --skip-epochs 3201 --max-epochs 2000 \
  --preset low-cost \
  --summary-json output/ppc_nagoya_run3_lowcost_late2k_holdcfgfix_summary.json \
  --out output/ppc_nagoya_run3_lowcost_late2k_holdcfgfix.pos \
  --rtklib-pos output/ppc_nagoya_run3_late2k_rtklib.pos \
  --use-existing-rtklib-solution