千葉工業大学「KASHIWA」TLM受信とその後
4月
21
2024
2024年4月11日 ISSより放出された千葉工業大学のCubeSat「KASHIWA」からのテレメトリーを受信した。
（4月23日から4月29日までの追記有り）
この画像は、受信したテレメトリーの生データを、HEX変換したファイルをエディタで開いたもの
受信データ : ZIPファイル
CubeSat KASHIWA 初めての受信
KASHIWAのコールサインは JS1YMX なのでテレメトリー内のコールサインが違っている。 何れも九州工業大学の衛星 FUTABA(JG6YBW)とTSURU(JG6YMX)のものだ。テレメトリーデータの作業(bit操作)忘れかも知れない。 <NON-AX25 frame Len=86> の原因か。
- TNC
- High Speed SoundModem by UZ7HO ver.0.27
- Mode
- FSK G3RUH 4800bd
- Terminal
- TLMForwarder v.2.0.3 (自作アプリ パッケージ化出来ないため配布していない）
- hex file
- Terminalの Raw data ログファイルをコマンドでHEX化したもの
- TLE
- KASHIWA
1 59508U 98067WH 24111.58406964 .00101296 00000-0 16048-2 0 9998
2 59508 51.6381 240.9452 0002762 103.6316 256.4982 15.52590375 1500 - Doppler.SQF
- KASHIWA,145825,145825,FM,FM,NOR,0,0,APRS Digipeater
KASHIWA,437375,,FM,,NOR,0,0,GMSK 4K8 AX25 - アンテナ
- GreenCube特化型15エレクロス八木
- リグ
- ICOM IC-7100
初めてのSatNOGS DBアップロード（2024.4.23追記）
KASHIWAに無関係の<NON-AX25 frame>を排除するため、コールサイン(JG6YBW)でフィルタリングした。 従って、もしコールサインが入っていない KASHIWA のテレメトリーが有れば破棄されているかも知れない。
全部で9パケットのテレメトリーデータを SatNOGS に転送した。
TLEのNoradIDは59508であるが、テレメトリを転送するときは Temporary NORAD ID : 99197 を使用する。
異常なテレメトリー文字列を転送してしまった（2024.4.24追記）
図の赤枠内が（分かりやすくするため編集している）c0c000 又は c0c010 の部分で、本来分割して受信されるべきところ連続受信して、繋がってしまっている。 最初の c0 はその先の文字列の終わりを表し、続く c000 又は c010 は次の文字列の先頭文字である。 本来別々（少しのタイムラグが有れば）受信されれば問題は起こらない。 そうすれば受信直後に行う 先頭文字と末尾文字の3文字を省く処理で正しい文字列として送信できていたことになる。
そこで、繋がった複数文字列の3文字処理だけは終了した状態で、データを受け取り本体プログラムで、"c0c000"又は"c0c010" をセパレータとして Split することにした。
これで、86バイトの文字列と、30バイトの2形式となる。明朝テストすることにする。
いつもと異なる83バイトデータを受信（2024.4.25追記）
このデータは、SoundModem自体が83バイトで受信しており、プログラムのフィルタリングでコールサイン部を指定しているので、実際 KASHIWA から送信されたデータが83バイトだったと推察。連続データが有ったとした上でセパレート出来たかは不明なため後日、KSS データを使ってファイル読み込みでテストする。
繋がった受信データのKSSファイルを新アルゴリズムで試す（2024.4.29追記）
4月24日の転送ログを解析した図の赤枠部分(接続パケット）は、上記 KSSファイルの赤枠に該当する。 同様に転送ログでは同じ部分が分離されていてアルゴリズムが機能していることが分かる。
実際のSoundModemでの受信ではなく、KSSファイルを読ませるシミュレーションなので、実は全部連続して読み込み、すべてが接続していた事になる。
このアルゴリズムで連続パケットに対応できると思われるのではあるが、転送に対して返答を待つなどを考慮すると一瞬に受信したデータの送信に数秒から数十秒掛かる事になる。 つまり極端な場合、その間にも次々に受信が有り、バッファオーバーランを起こす危険がある。
今回の場合衛星側もテスト段階であり、このようにパケットが連続するケースは他の衛星でも有りはするが希である。 （テレメトリーパケットにダブって交信データが入ってきたようなケースがGreenCubeで経験された。） たとえは数十ミリ秒であっても明らかなギャップが有れば区切られると思う。それを越える連続性における対処法としては充分なのではないかと思われる。
