4. SatNOGSでのRSP-03対応：変調方式と復調チャレンジ②

Last updated at 2025-08-17Posted at 2025-08-08

概要

このドキュメントは、アマチュア衛星 RSP-03送信フォーマット を SatNOGS NETWORK に登録し、打ち上げ後に世界中のアマチュア無線家がテレメトリを受信・解析できるようにする手順を説明します。

衛星情報

衛星名: RSP-03
コールサイン: JS1YOY
SatNOGS 衛星ID: SRYX-5008-9935-5872-7958
一時NORAD ID: 98654
ダウンリンク周波数: 437.050 MHz
変調方式: GMSK (9600bps)、AFSK (1200bps)、4FSK (24000bps)、OQPSK (24000bps)、CW (20wpm) ※後者4つはSatNOGS向けには未実装
フレーミング: AX.25 + Little Endian形式のバイナリペイロード

Step 1: Forkとローカル作業環境の構築

GitLabの satnogs-decoders を自分のアカウントにForkし、作業ブランチを作成します。

bash

git clone https://gitlab.com/your_account/satnogs-decoders.git
cd satnogs-decoders
git checkout -b feature/rsp03_clean

Step 2: .ksyファイルの作成

RSP-03のAX.25データ構造とビーコン仕様に基づいて、ksy/rsp03.ksy を作成します。Kaitai Structの構文で定義され、AX.25の中身がPacket 1〜3に応じて切り替えられるように switch 構造を使っています。
ksyファイル名は、シンプルにするようSatNOGSより指摘を受け、rsp03.ksyとしました

yaml

  packet_type:
    seq: ...
    switch-on: packet_type
    cases:
      1: packet1
      2: packet2
      3: packet3

📝 ファイルは自身で作成したブランチfeatre/rsp03_cleanの中のksy/ ディレクトリに保存し、Gitに追加します。

Step 3: Kaitai Web IDEによるデコード検証

Kaitai Struct公式の Web IDE＜https://ide.kaitai.io/#＞に .ksy ファイルと .bin ファイル（AX.25形式）を読み込ませて、構造の整合性を確認します。

補足）WAVファイルから.binフィルへの変換

RSP-03のGMSK信号を受信後、.wav から .bin ファイルへ変換、バイナリデータを整形する必要がありました。まず、リーマンサットメンバーにKISS形式での出力を依頼しました。

本プロジェクトでは以下の手順で .wav → .bin の変換を実施しました：

衛星試験用のwavファイルを準備　ex.RSP-03_GMSK_HKBeaconSample.wav
🔊 SoundEngine Free で .wav をPC再生
HS Soundmodem で復調し、agw_online_kiss_plus によってKISSパケットを抽出
🎧 SoundEngine → Soundmodem 間は VB-Audio Virtual Cable を使用

Kaitai Struct（https://ide.kaitai.io/#）で .ksy の動作検証を行う際には、KISS形式のままではうまくパースできません。そのため、以下のような処理を手作業で行いました：

KISSフレームの先頭 0xC0 0x00（ヘッダ）を除去
フレームの末尾にあるFCS（2バイト）や 0x00（フッタ）を除去
結果として得られた AX.25 UIフレーム部分のみを .bin ファイルとして使用
前の記事「変調方式と復調チャレンジ①」での「 gr-satwllite」のソフトを使うこともお勧めします

📥 KISS形式の `.bin`（整形前）182byte

text

C0 00 00 A6 62 B2 A0 00 60 00 A6 62 B2 00 B2 00
03 00 00 18 AD 80 01 29 4E 7E 68 78 DB DC 01 11
00 54 00 00 00 AE 67 2F 03 00 00 00 00 AD 51 61
2D 00 01 00 00 00 04 0F 08 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 FE FF 00 00 00 01 00 2F 00 00 00 18 00 25
00 24 13 24 0C 64 00 00 00 00 FF 00 00 00 1B 00
00 00 FF 00 00 00 FF 00 00 01 00 CA 1D 00 00 FF
1A 00 D1 1E 04 00 04 AE 17 00 00 1D 00 00 4A 00
1B 00 5F 03 00 FF 70 CA 28 00 7F 30 00 B0 00 3D
0E 00 7C 08 00 01 01 00 21 0E 00 24 00 00 00 00
00 00 00 00 00 C0

上記バイナリには、以下のKISS関連データが含まれています：

区分	値	説明
ヘッダ	`C0 00`	KISSフレーム開始（FEND + コマンド）
フッタ	`00 C0`	KISSフレーム終了（FCS後など）
FCS	`2バイト`	Frame Check Sequence（CRC）部分
AX.25本体	中間部分	UIフレームデータ（下記参照）

🔎 整形後、kaitai検証用のバイナリデータ　200byte

94 A6 62 B2 A0 82 60 94 A6 62 B2 9E B2 E1 03 F0
00 18 AD 80 01 29 4E 7E 68 78 C0 01 11 00 54 00
00 00 AE 67 2F 03 00 00 00 00 AD 51 61 2D 00 01
00 00 00 04 0F 08 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 FE FF 00 00 00 00 01 00 2F 00 00
00 18 00 25 00 24 13 24 0C 64 00 00 00 00 FF 00
00 00 FF 00 00 1B 00 00 00 00 FF 00 00 00 FF 00
00 01 00 00 00 00 00 00 00 CA 1D 00 00 00 FF 1A
00 D1 1E 04 00 04 AE 17 00 00 1D 00 00 4A 00 1B
00 5F 03 00 FF 70 CA 28 00 7F 30 00 B0 00 3D 0E
00 7C 08 00 01 01 00 21 0E 00 24 00 00 00 00 00
00 00 00 00 00 00 00 00

補足：なぜ整形後のバイナリが長いのか？　chatGPTさん回答ですが、、、

KISS整形後の .bin が元のKISS形式より長く見える場合があります。

FCSやKISS除去の方法によって、元のデータが部分的に切り捨てられていた
.bin 出力後に余計なバイト（paddingやnull）が加わった
Kaitai検証用に意図的に追記したデータが含まれていた

→ 検証の際は .bin のバイト数や構造に注意が必要です。