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

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

頭の整理）SatNOGSにおけるサーバーとクライアントの関係と観測スケジュールの流れ

この記事では、地上局受信ネットワーク「SatNOGS（Satellite Networked Open Ground Station）」において、サーバーとクライアントの役割、および観測スケジュールの受信までの一連の流れを調べたのでまとめます。間違いがありましたらご指摘いただけますと幸いです

SatNOGSの基本構成

SatNOGSは大きく分けて2つの構成要素で動いています：

コンポーネント	役割	主な技術要素
SatNOGS Network（サーバー）	衛星データベース、スケジューリング、結果集約と公開	Web（https://network.satnogs.org/）
SatNOGS Client（クライアント）	各地の地上局での自動受信・デコード処理	Raspberry Pi + SDR（PlutoSDR, RTL-SDRなど） + GNURadio + Python

クライアントとサーバーの関係

サーバー（Network）上で観測対象（衛星）とスケジュールが登録される
クライアント（地上局）のRaspberry Piが定期的にスケジュールを受信
GNURadioフローグラフとYAML設定に基づいてSDRで信号を受信
Pythonスクリプトでデコード（例：AX.25やCW）
観測データ・音声・スペクトル・デコード結果をサーバーへアップロード

🔁 スケジュール受信から観測・アップロードまでの流れ

📂 SatNOGS各モジュールの役割（公式構成より）

モジュール	役割（要点）	主な入出力
SatNOGS Network（サーバー）	衛星カタログ・TLE・観測スケジューリング・観測結果の集約/公開（Web/API）	入力: 観測リクエスト / ユーザー投稿 / TLE 更新出力: 観測ジョブ（周波数・モード等） / 観測結果の閲覧ページ
satnogs-client（Rasp Pi 等の地上局）	NetworkのAPIから観測ジョブを定期取得し、適切なフローグラフを起動、デコーダを実行、成果物をアップロード	入力: 観測ジョブ（周波数/モード/衛星ID）出力: デコードJSON / 受信音声(ogg) / スペクトログラム / メタ情報
satnogs-flowgraphs（GNU Radio / gr-satnogs）　RaspPi内	復調パイプラインを提供。モードとボーレートに応じたフローグラフを選択・実行し、AX.25ならフレーム化→KISS化まで行う	入力: SDR/IQ もしくは wav 出力: KISS/フレーム（AX.25 等）・生ビット列
satnogs-decoders（Python / Kaitai）　RaspPi内	フレームのペイロードを解釈（Kaitai .ksy やPythonスクリプト）。衛星ごとのYAML/DB定義に基づきフィールドを抽出	入力: KISS/フレーム（clientから供給）出力: テレメトリJSON
SatNOGS DB（API/データベース）	デコード結果・音声・スペクトラムを受信/保存し、Networkから公開	入力: client からの POST

補足

ksy記述、Kaitaiでのデコーダ検証の際、オリジナルのwavファイルやバイナリファイルに余分なデータがついていろいろ困った部分をメモ書きでのこします。ピュアな？AX.25形式＋ペイロード部分のバイナリファイルを作成が必要

AX.25 … 衛星・地上局のプロトコルの本体。ビーコンやテレメトリはこの構造に従う。https://qiita.com/OzoraKobo/items/e411705f2295d5a6f27d
AX.25のデータの始まりと終わりには0X7Eフラグが付属。SatNOGS クライアントや gr-satnogs（GNU Radio モジュール）には HDLC フレーマが組み込みされ、SDR → ビットストリーム → HDLC デコード処理の中で、ビットスタッフィング解除とフラグ検出 (0x7E)し、フラグ自体は境界の目印なので、この段階で削される
KISS … AX.25 を「TNCやソフトに渡すための入れ物」。通信自体には関与しない。
0xC0 … KISS のフレーム境界を表すシンボル。AX.25内部にあっても必ずエスケープされるので、フレーミングの「目印」として確実に機能する。(エスケープ処理 (0xDB 0xDC に変換)
KISS は「受信安定の目印」だけでなく、AX.25 を安全に上位アプリへ転送するための最小限のフレーミング仕様です。AX.25 本体の解釈よりは一段階下の役割ですが、0xC0 のフレーム区切りは通信処理の要所を担っています。
AX.25とKISSの関係は* 実際に衛星から送信されるのは AX.25フレームのみ で、KISSは含まれていない。
KISSは、地上局側のTNCやソフトモデム（Direwolf、Soundmodem）が「AX.25フレームをPCとやり取りしやすくするためのラッパー」として付与するもの。しかしSatNOGSの場合、GNURadioフローグラフがAX.25を直接処理し、クライアント内で必要に応じてKISSとして扱うため、ユーザーがKISSの追加・削除を意識する必要はありません。
リーマンサットメンバーよりもらったデータにはKISS処理が付帯されていましたが、SatNOGS向けには必要なく、混乱した（笑）
AX.25 G3RUHは標準で組み込み。SatNOGSでは、デコーダ（GNU Radioフローグラフ）において自動的にG3RUHスクランブル解除を行う。G3RUHとはアマチュア衛星通信の標準的な変調・符号化方式

補足２

オリジナルwavファイルからkaitaiチェック用のバイナリファイル（補足の影響を除去するバイナリへ）gr-satellitesのツールを使うことで、一発で作成できる。SatNGOSとは別の方が開発されている
*使い方：以下参考リンクを参照。wavファイルからkaitaihttps://ide.kaitai.io/動作検証用のバイナリファイルが作成できる

bash

gr_satellites ./RSP-03.yml --wavfile ./RSP-03_GMSK_HKBeaconSample.wav --samp_rate 48e3 --hexdump

参考リンク

Direwolf: Software "Soundcard" AX.25 Modem/TNC
Soundmodem by UZ7HO
SatNOGS Docs - Client Flowgraphs
gr-satellites GitHub リポジトリ：ドライバやデコーダの最新ソース一式を確認できます。
gr-satellites ドキュメント（Read the Docs）：インストール手順やフローグラフ、SatYAML の利用方法まで詳細に記載されています。

📂 衛星情報のYAMLファイルについて

注意：SatNOGS DBへのYAML ファイルのアップロードは必要ありません

コミュニティメンバーや、wavファイルのbinデコード用にrsp03.ymlを作成し提供しました

ksyを受領していただいた後は、SatNOGSメンバーの方に登録作業をしていただいたので以下は参考です

SatNOGS DB の公式 Wiki に記載されているのは、Web UI（「Suggest New Transmitter」など）を通して追加・編集する方法のみであり、YAML ファイルを使った登録方法はありません
運用環境での更新（例：周波数や変調方式の変更など）は、SatNOGS の Web UI を通して行うことになります。
(https://wiki.satnogs.org/SatNOGS_DB?utm_source=chatgpt.com)
そのため、「rsp-03.yml」のような YAML ファイルは主に gr-satellites の検証用として使われ、SatNOGS DB の運用には直接関係しません。README.mdファイルも不要でした

✅ まとめ

SatNOGSはサーバーが観測対象とスケジュールを管理し、クライアントが自動で観測・デコード・アップロードする仕組み
衛星情報はYAMLファイルでなく、Web　UIにてSatNOGS-DBを記入

次回は、具体的な rsp03.ksy の実装とGitLabへの登録方法を紹介します。