HADES-SA CHECK27.grc 今後の実験方針 ― 2026年11月13日 13:46

(N6RFM局からの直接示唆)

[60923hda.wav バースト開始付近調査結果]

  11.006秒   トレーニングパターンが始まる。
  11.166秒   最初の同期信号 0xBF35 が現れる。
  0.160秒の差 800 baud × 0.160秒 = 128ビット。

  (補足) 60923hda.wav
   このファイル名にあるように、SatNOGs 2026年9月23日の AFSK音声WAV 録音。
   SatNOGSの2026年9月21日~23日付近の観測ログに、GENESIS FSK 800 と記載。
   デコードに成功した SoundModem は、UZ7HO の "FSK GENESIS 800bd" v0.05。

[調整係数]

  位相補正: t += 0.15 * e
  トレーニング中の周期補正: T += 0.01 * e
  データ中の周期補正: T += 0.0005 * e
  トレーニング中の周期制限: 公称周期の±3%
  データ中の周期制限: トレーニングで得た周期の±0.5%
  800 baudの場合、公称周期60 samples なので、
  トレーニング中: 58.2~61.8 samples
  データ中: トレーニングで決めた周期の±0.5%



[GRC 具体的実験方針]

 (1) トレーニングパターンの役割

    HADES-SAでは、バースト開始時に128ビットのトレーニングパターン(0xAAを
    16回繰り返したもの) が送信される。この規則的な信号を利用して、受信側
    はシンボルの読み取りタイミングと周期を推定する。

 (2) バーストごとのタイミング初期化

    N6RFM局の説明によれば、バースト開始時にはシンボル周期を公称値の(800
    baudの場合は 60samples)にリセットする。その後、トレーニングパターン
    を使って周期を調整する。

 (3) データ受信中の周期安定化

    トレーニング終了後は、データ信号の変化に過剰に追従しないように周期
    補正を弱め、トレーニング中に得られた周期の ±0.5%以内に維持する。

 (4) GRC への実装と確認

    GNU Radio Companion (GRC) では、最初にトレーニングパターンの検出と、
    シンボル周期の推定を行い、その後、N6RFM局が示したDPLL方式を実装する。
    最終的には、同期信号 "0xBF35" が、320ビット(800 baudで 0.4秒) 間隔
    で正しく検出されることを確認する。

HADES-SA 今後の構想案 ― 2026年11月12日 22:30

HADES-SA 解析の全体的な流れ ― 2026年11月11日 17:06


      図右:自局が現在居住する沖縄県石垣島, コロナ最中の2020年5月6日撮影


[No.1201: 音声スクランブル構造の解析]

"60923hda.wav" の「HADES-SA CODEC2 音声スクランブル構造」の解析は成功し、
公式サイトの手法により、CODEC2 の音声復元に完成した。

https://www.asahi-net.or.jp/~ei7m-wkt/numb1201.htm
https://www.ne.jp/asahi/hamradio/je9pel/hadesagr.htm


[No.1202: CODEC2 音声復号に成功]

HADES-SA CODEC2 公式デコーダーによる音声復号実験に成功した。並行して進め
ていた 「GNU Radio GRC」 による再現実験の途中で、「HADESx Decoder」 の記述で
次の問題があることを発見した。

> 従来のビットタイミング回復処理の問題と改善 (HADESx Decoder前文)
> 
> 従来のビットタイミング回復処理では、次の問題が発生することがあった。
> スクランブルされていないデータでは、シンボルクロックが最大3%ずれること
> があった。同期語の直後で数ビット分の位置ずれが発生し、フレームを正しく
> 切り出せなくなる場合があった。この問題に対しては、バースト開始時に、
> クロックをリセットし、トレーニングパターンからタイミングを学習する方式
> を導入して、改善した。

https://www.asahi-net.or.jp/~ei7m-wkt/numb1202.htm
https://www.ne.jp/asahi/hamradio/je9pel/hadesaen.htm


[No.1203: 「HADESx Decoder」 による SSDV_JPEG画像復元に成功]

従来のビットタイミング回復の問題を踏まえ、「HADESx Decoder」 に視点を変え、
このデコーダーによる SSDV_JPEG画像の生成に成功した。

https://www.asahi-net.or.jp/~ei7m-wkt/numb1203.htm
https://www.ne.jp/asahi/hamradio/je9pel/hadesxgd.htm


以上の 「No.1201 → No.1202 → No.1203」 が、ここまでの全体的な流れである。
これらを 「GNU Radio GRC」 で再現しよう という現在の実験の途中で生じている
大きな課題が 「シンボルクロックずれを GNU GRC で解決できるか?」 ということ
である。現在 "HADES_SA_800bps_FSK_WAV_CHECK27.grc" の段階まで進んでいる。

HADESx によるSSDVパケットのJPEG画像再構成 ― 2026年11月10日 20:04

 

前回は、"HADESx Generic Decoder v1.7.2" を Windows 11 にインストールし、公式サンプルWAVから
5個の HADES-SA SSDVパケットを正常に復号できることを確認した。今回は、その5 個のSSDVパケット
を結合し、JPEG画像ファイルを生成する実験を行った。

 1. [HADESx Decoder によるSSDVパケットの復号]

使用したファイルは、HADESx に付属する公式WAVサンプルである。

    "C:\Program Files\hadesx\HADESx-Decoder-1.7.2\examples\iq\hades_sa_ssdv_pass.wav"

CMDを起動し、HADESxのインストールフォルダーに移動する。

    cd /d "C:\Program Files\hadesx\HADESx-Decoder-1.7.2"

公式サンプルを復号する。

    py -m hadesx examples\iq\hades_sa_ssdv_pass.wav



実行結果:

  - 衛星:SpinnyONE HADES-SA
  - 変調方式:FSK 800 baud
  - パケット種別:Type 10 (SSDV image packet)
  - 画像ID:0
  - 画像サイズ:320 x 240
  - 受信パケット:2,3,4,5,6
  - CRC:5個すべて OK
  - 5 valid frame(s)

 2. [SSDVパケットをファイルに保存]

次に、復号したパケットをファイルに保存するため、出力フォルダーを指定して再実行した。

    py -m hadesx examples\iq\hades_sa_ssdv_pass.wav --outdir ssdv_result

今回は 5個のSSDVパケットが、個別のBINファイルとして保存された。

ファイル名の例: 各ファイルは256 bytesである。

    sat_03_type_10_ssdv_img_000_packet_0002.bin
    sat_03_type_10_ssdv_img_000_packet_0003.bin
    sat_03_type_10_ssdv_img_000_packet_0004.bin
    sat_03_type_10_ssdv_img_000_packet_0005.bin
    sat_03_type_10_ssdv_img_000_packet_0006.bin

出力フォルダーの内容を確認する。

    dir ssdv_result

 3. [hadesx-ssdv.exe の確認]

HADESx には、出力されたSSDVパケットを結合してJPEG画像化するための "hadesx-ssdv.exe" が
用意されている。次に、実行ファイルの場所を確認する。

    dir "C:\Users\user\AppData\Local\Programs\Python\Python314\Scripts\hadesx-ssdv*"

次のファイルが確認できた。

    "C:\Users\user\AppData\Local\Programs\Python\Python314\Scripts\hadesx-ssdv.exe"

"hadesx-ssdv.exe" のヘルプを表示する。

    "C:\Users\user\AppData\Local\Programs\Python\Python314\Scripts\hadesx-ssdv.exe" --help

この hadesx-ssdv.exeプログラムは、HADESx Decoder の出力フォルダーを指定し、画像IDごとにSSDV
パケットを結合して、指定した出力フォルダー内に、SSDVファイルとJPEG画像ファイルを自動生成する。

 4. [SSDVパケットの結合とJPEG生成]

画像再構成には、今回新たに HADESx に付属する "hadesx-ssdv.exe" を利用した。このプログラムは
内部処理で、以前HADES-SA用に使用していた "ssdv.exe" を利用する。他の3ファイルは実際には使用
していないが、念のため以下の4ファイルを HADESx のインストールフォルダーにコピーした。

    run_ssdv.bat
    ssdv.exe
    ssdv-x86.exe
    ssdv-merge-windows-x86.exe

コピー元:

    "C:\Program Files\hadesa\SSDV-minimodem\SSDVs\ssdv.exe"
    "C:\Program Files\hadesa\AMSAT-EA_HADES-SA_SpinnyONE_SSDV_utilities\run_ssdv.bat"
    "C:\Program Files\hadesa\AMSAT-EA_HADES-SA_SpinnyONE_SSDV_utilities\ssdv-x86.exe"
    "C:\Program Files\hadesa\AMSAT-EA_HADES-SA_SpinnyONE_SSDV_utilities\ssdv-merge-windows-x86.exe"

画像ID "0" を指定して、JPEG画像を生成する。

    "C:\Users\user\AppData\Local\Programs\Python\Python314\Scripts\hadesx-ssdv.exe" ssdv_result --image 0 --ssdv "C:\Program Files\hadesx\HADESx-Decoder-1.7.2\ssdv.exe"

実行結果:

    image 0: 5 packet(s), highest number 6, 2 missing -> ssdv_result\hades_sa_image_000.ssdv
    packets: ..#####?
    missing: 0-1
    packet 0-1: about 0 % to 2 % down the picture (rows 0-6 of 240)
    after packet 6: not received (the end of the image has not arrived): from about 8 % down, rows 20-240 of 240
    picture: ssdv_result\hades_sa_image_000.jpg

 5. [生成されたJPEG画像ファイルの確認]

    dir ssdv_result\*.jpg

実行結果:

    2026/11/10  14:35       2,831 hades_sa_image_000.jpg
    1個のファイル           2,831 バイト

生成されたファイル:

    C:\Program Files\hadesx\HADESx-Decoder-1.7.2\ssdv_result\hades_sa_image_000.jpg

実際にこのJPEG画像を開いてみると、画像上部に一部の映像が現れ、その下は未復元部分となっていた。
画像サイズは 320 x 240 pixel で、受信できたのはパケット2~6 の5個であり、パケット0, 1 および、
パケット7以降のデータは未受信である。そのため、画像全体の約8%に相当する部分だけが表示された。
完全な画像復元には至っていないが、SSDVパケットからJPEG画像ファイルを実際に生成できた。

 6. [過去の画像復元方法との比較]

これまでの No.1182, No.1183では、SoundModem や SatNOGS のCSVデータから SSDVパケットを取り出し、
画像を再構成していた。今回の HADESx による方法は、I/Q WAVファイルから直接SSDVパケットを復号し、
画像再構成まで進めるものである。

    項目               No.1182 / No.1183                今回 No.1203
    ----------------------------------------------------------------------
    入力データ         SDR受信 / SatNOGS CSV            I/Q WAV
    パケット抽出       SoundModem / CSV解析ツール       HADESx v1.7.2
    パケット保存       個別の.binファイル               個別の.binファイル
    パケット結合       cat等による番号順結合            hadesx-ssdv.exe
    JPEG変換           ssdv.exe                         ssdv.exe
    ----------------------------------------------------------------------
    No.1182, No.1183, No.1203

No.1183では、SatNOGS のCSVファイルから専用ツールで .binファイルを抽出し、次のコマンドで
結合していた。

    cat *.bin > combined.bin
    ssdv -d combined.bin output.jpg

今回は、HADESxがパケット抽出を担当し、"hadesx-ssdv.exe" が結合と画像再構成を担当する。

    "C:\Users\user\AppData\Local\Programs\Python\Python314\Scripts\hadesx-ssdv.exe"

 7. [今回の実験結果]

今回の実験により、Windows 11 / Python 3.14.3 / HADESx Generic Decoder v1.7.2 の環境で、
次の一連の処理が正常に動作することを確認した。

    (1) I/Q WAVファイルからHADES-SAのSSDVパケットを復号
    (2) CRCが正常な5個のパケットを ".bin" ファイルとして保存
    (3) "hadesx-ssdv.exe" でパケットを結合
    (4) 内部で "ssdv.exe" を使用してJPEG画像ファイルを生成
    (5) 生成されたJPEG画像を実際に表示

今回の公式サンプルでは、受信できたパケットが 5個だけだったため、画像全体の約8%の復元に
とどまった。しかし、HADESxを利用して I/Q WAV からSSDV画像をJPEG化する一連の処理が実現で
きたことは大きな成果である。今後は、実際の衛星受信データから、より多くの SSDVパケットを
収集し、画像全体の復元に挑戦したい。

HADESx Generic Decoder(v1.7.0)導入・動作確認記録 ― 2026年11月10日 09:00

 1. HADESx Generic Decoder のインストール

    今回、HADES-SA / HADES-L などの復号に対応した "HADESx Generic Decoder v1.7.0" を、
    Windows 11 にインストールして動作確認を行った。

    インストール環境

       項目            内容
       --------------------------
       OS              Windows 11
       Python          3.14.3
       HADESx          v1.7.0
       インストール先  C:\Program Files\hadesx\HADESx-Decoder-1.7.0
       ------------------------------------------------------------

     * インストールに先立ち、"C:\Program Files\hadesx"フォルダーへのアクセス権限を設定した。

       アクセス権限の設定手順

       (1) hadesxフォルダーを右クリックし、「プロパティ」を開く。
       (2)「セキュリティ」タブを選択する。
       (3)「グループ名またはユーザー名」から "User" を選択する。
       (4) 下半分のアクセス許可欄で、読み取りと書き込みの許可欄にチェックを入れる。
       (5)「適用」→「OK」で確定する。

    この設定後、HADESx のインストールコマンドが正常に実行できた。


 2. 公式サンプルによる復号テスト

    インストール後、HADESx に付属する公式サンプルを使用して、実際に復号できることを確認
    した。このファイルは、HADES-SA の受信データを収録したステレオ I/Q WAV ファイルである。

    使用ファイル: "examples\iq\hades_sa_ssdv_pass.wav"


 3. CMD で実行したコマンド

    以下の手順で、Pythonの確認からサンプルWAVの復号までを実施した。

       (1) Pythonのバージョン確認
           py --version

       (2) Pythonの実行ファイル確認
           py -c "import sys; print(sys.executable)"

       (3) HADESxフォルダーへ移動
           cd /d "C:\Program Files\hadesx\HADESx-Decoder-1.7.0"

       (4) HADESxのインストール
           py -m pip install -e .

       (5) HADESxのヘルプ表示
           py -m hadesx --help

       (6) サンプルフォルダーの確認
           dir examples

       (7) サンプルIQフォルダーの確認
           dir examples\iq

       (8) サンプルのREADME表示
           type examples\iq\README.md

       (9) HADES-SAサンプルWAVの復号
           py -m hadesx examples\iq\hades_sa_ssdv_pass.wav

    以上のコマンドを実行し、HADESx の起動とサンプルデータの読み込み・復号が
    正常に行われることを確認した。


 4. HADES-SA公式サンプルの復号結果

    公式サンプルWAVから、5個のSSDVパケットを正常に復号することができた。

       項目                 実行結果
       ---------------------------------------
       衛星                 SpinnyONE HADES-SA
       変調方式・ボーレート  FSK / 800 baud
       受信形式             ステレオ I/Q WAV
       サンプルレート       50,000 samples/s
       パケット種別         Type 10 (SSDV画像)
       CRC                  5個すべて OK
       有効フレーム         5 frames
       ---------------------------------------


今回のテストにより、Windows 11/Python 3.14.3 の環境で、"HADESx Generic Decoder v1.7.0"
が動作し、HADES-SA SSDVパケットを復号できることを確認した。今回確認できたのは、パケット
の復号までであり、JPEG画像ファイルの再構成については、別途、"hadesx-ssdv" および "ssdv"
を使用した確認が必要である。次回は、復号した 5個のSSDVパケットからJPEG画像を再構成する
実験を行う。

HADESx Generic Decoder ― 2026年11月09日 21:00

(参考) HADESx Generic Decoder v1.7.0 @N6RFM

公式ページ:   HADESx-Decoder GitHub
リリース一覧: HADESx Releases

  - UNNE-1B だけでなく、HADES-SA、HADES-Lにも対応
  - SDR のI/Q録音や音声WAVファイルから直接処理可能
  - CODEC2 音声の復元に対応
  - 従来のGNU Radio方式で問題になりやすかったビットタイミングのずれを改善

従来のビットタイミング回復処理の問題と改善

    従来のビットタイミング回復処理では、次のような問題が発生することがあった。
    スクランブルされていないデータでは、シンボルクロックが最大3%ずれることがあった。
    同期語の直後で数ビット分の位置ずれが発生し、フレームを正しく切り出せなくなる場合
    があった。この問題に対しては、バースト開始時にクロックをリセットし、トレーニング
    パターンからタイミングを学習する方式を導入して改善した。

Decoder v1.7.0 の主な変更点

 1. 各受信フレームの受信時刻を記録
    コンソール表示と .tlm ファイルに、UTCの受信時刻を追加した。

 2. 衛星時計との時刻照合
    UNNE-1Bの起動後経過秒数と録音時刻を照合し、時刻設定の誤りなどを警告表示した。

 3. フレームの生データ表示
    フィールド別デコーダーが用意されていない UNNE-1B のテレメトリーについても、
    SoundModem, Direwolf と同様に、フレーム全体のHEXデータを表示するようにした。

37バイトTXTファイルを自動生成するRubyプログラム ― 2026年11月08日 20:12

GRCのCHECK26_bits2.binファイルから、連続する40バイト単位のフレームを抜粋して作成したHEX_TXT
ファイルを入力データとし、各フレームに対して"XOR 0xFF"の反転処理を行い、さらに先頭の3バイト
をカットして、フレームごとに37バイトの候補ファイルを自動生成する Rubyプログラムを作成した。

生成された複数のファイルのうち、Frame1(Frame017)について、前回作成したTXTファイルと、今回
Rubyプログラムで生成したTXTファイルの中身を比較したところ、完全に一致することを確認した。他
の Frame*(Frame***)についても同様に一致した。

Rubyプログラム
https://www.ne.jp/asahi/hamradio/je9pel/hades_hex_to_candidates_v2.rb

実行コマンド
ruby hades_hex_to_candidates_v2.rb CHECK26_D_11frames_40bytes_hex.txt

(前回) hadesフォルダ:CHECK26_Frame1_type11_candidate_37bytes_hex.txt
B3 11 E5 F5 E4 70 30 E9 E6 7B 7F FE 21 4A 41 7C C4 CF E3 C9 2F 91 FE 7E 6B 87 54 D3 D8 11 8A 6F AC 02 93 9B 58

(今回) rubyフォルダ:Frame01_F017_candidate_37bytes_hex.txt
B3 11 E5 F5 E4 70 30 E9 E6 7B 7F FE 21 4A 41 7C C4 CF E3 C9 2F 91 FE 7E 6B 87 54 D3 D8 11 8A 6F AC 02 93 9B 58

ビット・バイトの話し ― 2026年11月08日 17:16

 1. 例として、16進数の 40 をビットで表す。

    16進数は1桁(1文字)が 4ビットである。

    16進数     2進数	     ビット数
    4	       0100	     4ビット
    0          0000	     4ビット
    40	       0100 0000     8ビット=1バイト

    つまり、16進数の 40 は、
    4ビット+4ビット=8ビット=1バイト!

    つまり、バイナリデータとしての 0x40 は、

               0100 0000
               8ビット=1バイト

 2. なぜテキストでは、40 は 2バイトなのか?
    テキストファイルに 40 と書いた場合、PC は文字を2個保存する。
    テキストとしての 40 の解釈は、

              4                          0
    文字コード 00110100(34)    文字コード 00110000(30)
    8ビット=1バイト           8ビット=1バイト

               ゆえに、合計16ビット=2バイト

 3. 今回の HADES-SA データに当てはめると、

    TXTファイル:文字 560個 → 560バイト
    その文字を16進数として解釈:2文字ずつを 1バイトに変換
    変換後のバイナリ:280バイト
    280バイト÷40バイト=7フレーム

 4. 改行 CR+LF と LF について

    Windowsでは「改行はCR+LF設定」、LINUXでは「改行はLF設定」として扱う、
    CR, LF はそれぞれ 1バイト、半角スペースも 1バイト。
    次の保存実験をして、Windowsプロパティ表示の数値変化の違いをみてみた。

    CR:Carriage Return (復帰)   16進数 0D
    LF:Line Feed (改行)         16進数 0A

    改行形式                     実際に保存されるバイト
    Windows形式    CR+LF         0D 0A
    Linux形式      LF            0A

    (16進数40 について)

    理論的には、BINでは 1バイト、TXTでは 2バイト。
    このまま保存すると、"40" はTXTで 2バイト(Windowsプロパティ表示)。
    エンターキーを押して "40(エンター)"としてから改めて保存すると、Windowsで
    改行CR+LF設定だと 2+2=4バイト表示、改行LF設定だと 2+1=3バイト表示となる。

    (16進数:40 CA について)

    理論的には、BIN では 1+1=2バイト、TXTでは 2+2=4バイト。
    このまま保存すると、"40 CA" はTXTで 2+1+2=5バイト(Windowsプロパティ表示)。
    エンターキーを押して "40 CA(エンター)"としてから改めて保存すると、Windowsで
    改行CR+LF設定だと 2+1+2+2=7バイト表示、改行LF設定だと 2+1+2+1=6バイト表示となる。

 5. 今回の HADES-SA の Ruby作業では、

    TXTの CR+LF と LF の違いは、今回のRuby処理では問題なし。
    BINは バイト列を変えずに読み込む。
    Windows のプロパティに表示されるファイルサイズが違っても、
    HEXデータの中身が同じなら処理結果も同じ。

HADES-SA CODEC2 追加9フレーム結合と音声復元 ― 2026年11月07日 21:40

[追加:CMD入力コマンドを含む作業一覧]



 1. 40バイトをXOR処理し、先頭3バイトを除去して37バイト入力ファイルを作成
    CHECK26_Frame1_type11_candidate_37bytes_hex.txt
    CHECK26_Frame2_type11_candidate_37bytes_hex.txt
                 ;

 2. byte_versionフォルダーへ移動
    cd /d "C:\Program Files\hadesa\byte_version"

 3. 公式デコーダーを実行
    unified-bytes-decoder-hades-sa-windows-x86.exe CHECK26_Frame1_type11_candidate_37bytes_hex.txt
    unified-bytes-decoder-hades-sa-windows-x86.exe CHECK26_Frame2_type11_candidate_37bytes_hex.txt
                                                                :

 4. byte_versionフォルダーにBINファイルが生成されていることを確認                                                            :
    sat_03_type_11_codec2_frame_017.bin
    sat_03_type_11_codec2_frame_018.bin
                                 :

 5. 全てのBINファイルを、satフォルダーに移動
    C:\Program Files\hadesa\AMSAT-EA_HADES-SA_SpinnyONE_CODEC2_utilities_new\sat

 6. satフォルダー内を確認
    dir sat\*.bin

 7. 作業フォルダーへ移動
    cd /d "C:\Program Files\hadesa\AMSAT-EA_HADES-SA_SpinnyONE_CODEC2_utilities_new"

 8. 作業フォルダ内の CODEC2 Merge の使用方法を確認
    codec2-merge-windows-x86.exe --help

 9. 以前使用した5フレームの入力リストを確認
    type codec2_file_list.txt

10. 新しい9フレーム用入力リストを作成
    (
    echo sat\sat_03_type_11_codec2_frame_017.bin
    echo sat\sat_03_type_11_codec2_frame_018.bin
    echo sat\sat_03_type_11_codec2_frame_019.bin
    echo sat\sat_03_type_11_codec2_frame_020.bin
    echo sat\sat_03_type_11_codec2_frame_029.bin
    echo sat\sat_03_type_11_codec2_frame_030.bin
    echo sat\sat_03_type_11_codec2_frame_031.bin
    echo sat\sat_03_type_11_codec2_frame_033.bin
    echo sat\sat_03_type_11_codec2_frame_035.bin
    ) > codec2_file_list_9frames.txt

11. 追加した9フレーム用リストを確認
    type codec2_file_list_9frames.txt

12. 9フレームを結合
    codec2-merge-windows-x86.exe codec2_file_list_9frames.txt hades_sa_9frames.c2

13. CODEC2をRAW音声にデコード
    c2dec 700C hades_sa_9frames.c2 hades_sa_9frames.raw

14. RAW音声をWAVに変換
    ffmpeg\bin\ffmpeg.exe -f s16le -ar 8000 -ac 1 -i hades_sa_9frames.raw hades_sa_9frames.wav

[生成された音声ファイル]

     hades_sa_9frames.wav (中央付近と終端付近に音声信号)
    音声仕様:14.40秒、8,000 Hz、モノラル、16-bit PCM