7. トラブルとその解決の記録
6.ではSatNOGSメンバーとのやり取りでの気づきを主に記載しました。
ここでは、私自身が試行錯誤した内容を記載します
RSP-03対応のデコーダ開発では、Kaitai StructやGitLab MR提出時にさまざまなトラブルが発生しました。ここでは、発生順に沿って原因と対応策を整理します。
Step 1：Kaitai Structでのパースエラー
TEXT
**エラー例：**
Parse error (ValidationNotEqualError): not equal, expected [126], but got [3]
原因：
- wavファイルから.binファイルを無理やり作成したのですが、GNU Radioで処理した他メンバーがデコードした結果は
KISS形式のままで、0xC0やFCSが残っていた - Kaitai
.ksyがAX.25のデコード部分はSatNOGS標準機能で対応してもらい、通信（ペイロード部分）だけを想定していた
対応：
- 手動で、
.bin整形時にヘッダ・フッタ・FCSを除去 - Kaitai構造に
default:ケースやassertを追加して柔軟化
Step 2：インデントミスによるコンパイルエラー
エラー例：
TEXT
TypeError: Cannot convert undefined or null to object
原因：
-
.ksy内でseq:やtypes:のインデントがずれていた - YAMLとしては有効だが、Kaitaiコンパイラではエラーになるパターン
対応：
- Kaitai IDEで逐次検証
- インデントを2スペース単位に統一
Step 3：GitLab cherry-pick時のコンフリクト
TEXT
**エラー例：**
CONFLICT (rename/delete): rsp03/decode_rsp03_gmsk.py renamed to RSP03/decode_rsp03_gmsk.py in HEAD...
原因：
- リポジトリ側で不要ファイルの削除やリネームが進行しており、手元の変更と競合
- 古いファイルパスを参照していた
対応：
- コンフリクトファイルを確認し、不要ファイルは削除
-
.ksyファイルのみを残して再コミット
Step 4：KISS整形後にサイズが変わる問題
現象：
- KISS整形後の
.binが元より長くなっていた
原因：
- 元のKISSバイナリが途中で切り詰められていた可能性
- 整形時に余分なヌルバイト（
0x00）が付与されていた
対応：
-
wc -cでバイト数を比較 - Kaitaiの
doc:に残すデータ構造コメントを確認
📌 教訓
- Kaitai Structは構文・インデント・データ整合性すべてに厳密
- SatNOGS特有の
:field定義は早めに準備しないとGrafana連携が止まる - MR提出前にフォーラムで背景説明をしておくとレビューが円滑になる
-
.binはKISS整形後に必ずサイズと中身を比較する
関連記事リンク
0. 初めに — リーマンサット RSP-03 受信チャレンジの歩み
6.SatNOGSコミュニティとのやりとり
8.今後の実施項目・メンテナンス