ファイル読み込みが出来上がる

とりあえず、ファイルから読み込んでデータを取り出すところが完成しました。具体的に何をしていたのかは、こちらの記事をご覧ください(かなり見づらいですが^^;)。 で、やっと本題に取りかかる訳ですが、SELCALはデュアルトーンなので、FFTで処理をしてみようかと思っています。実際にやってみてだめぽなら、別な方法でいきます。 信号の長さが１秒もあるので、FFTでざっくり解析して比較してもそれほどCPUに負担はないのではないかと思っています。アクセラレータを使うので問題ないでしょう。 詳細な仕様はまだなんにも考えていませんw。44.1kHzでもってくるので、最低でも2048のFFTが必要なことはわかっています。精度を考えるとその倍の4096かもしれません。 あとは、HFなので振幅の変動を考慮したほうがよさそうだと思っています。どうするかというと、位相で比較するのはどうかと思ってはいるのですが、そうするとCPUに負荷がかかりそうなので、その辺は実験していくしかないのかと思っています。 今日はとりあえず、進捗報告ということでこの辺で…

航空用のSELCALデコーダーを作ろうと思う

前にちょっとだけ書いた航空用のSELCAL(ANNEX SELCAL)のデコーダーを作ってみようと思う。 デコーダを作る時間がいっぱいあればいいのだが、そうもいかないくて、ここの書き込みもごぶさたしてしまっているのである。ANNEX SELCALは仕様が大体わかっているため、調査する時間がなくても作れそうなので、これにすることにした。

A:312.6 B:346.7 C:384.6 D:426.6 E:473.2 F:524.8 G:582.1 H:645.7

J:716.1 K:794.3 L:881 M:977.2 P:1083.9 Q:1202.3 R:1333.5 S:1479.1

出どこがどこだか、忘れてしまったが、前に調べた仕様では、次のような周波数がデュアルで、信号が送られる時間は１秒間となっている。 まずはこの仕様で作ってみようかと思っていたのだが、ACARSと違って頻繁に受信できるものでもなさそうなので、いくつか実際に受信してサンプルを録音している。 録音してそれをデコードするのはいいのだが、ファイルから読み込んでデコードするのをやったことがなかっため、そこから作らなくてはならないことになる。 フォーマット変換があるので、ちょっと面倒ではまりモードになってきそうな感じになってきた。それができれば、一気にいきそうなのだが…。

余談だのだが、TOKYO RADIO（洋上管制）でなんか、やたらに声がかわいく聞こえるオペレーターがいるのだが、「OK♡」みないな話し方するひと… SSBだとそう聞こえるのか、マイクコンプレッサーのおかげなのか、地声がかわいいのかはわかりませんけど。ACCのほうも出てきているのかな？ いかん、完全にヲタ化しておるorz

NRZIとソフトデコード

過去記事「 VHF ACARSのデコード」で、ACARSのプロトコルがNRZI(Non Return to Zero Inverse)と書きました。よくよく考えてみるとNRZIというは、電線に電気が通るようなときに使う用語なような気がして、ソフトデコードでNRZIというのはおかしいのかな？という気もしましたが、ACARSはNRZIと同じように符号化されるということなのです。 NRZIは別に難しいものではないのですが、ACARSを例に書いてみようかと思います。 NRZIは、「I」がInverseを意味するように、信号が「１」のときに符号が反転し、「０」のときは符号が変わらないということです。 これをFSKのデコードで話をすると、まず、周波数の高いほうをスペースといいここでは「B」、低いほうをマークといい、「Y」という記号とします。マークの信号の場合を「１」として、マークの信号が来たら符号が反転するとします。 仮に「BBYYBYBB」という信号がきたとすると、そのままだと「00110100」ということになります。NRZIの場合は、「同同反反同反同同」（同＝変わらない、反＝反転）という意味になります。初期値が「０」であれば、「00100111」という結果になります。 ACARSを例にとるとACARSは最初のビットシンクをとるところは、ASCIIコードで「+」(2BH)「*」(2AH)が送られてきます。ビットは下位ビットから送出されるので、「1101010」「0101010」となりますが、パリティが「1」で固定なので、続けると「1101010101010101」となります。これをNRZIにすると「？同反反反反反反反反反反反反反反」（初期値を意識して最初は？とした）となります。 実際には「BBYYYYYYYYYYYYYY」となります。さらにビットシンクよりの前の信号はスペース(「B」)なので、デコーダーとしては、「YYYYYYYYYYYYYY」(14個の「Y」）を待つことでビットシンクをするということになります。

HF ACARS(HFDL)のデコーダーを作ってみようかと考え中

VHF ACARSのデコーダーすらまともに完成させていないのに他のものを作ってみるのもどうかと思うのではあるが、かなり気になっているので調査ぐらいはしてみようかと。 HFDLやHF ACARSでグーグルって見ると、ARINC 635と753というのがプロトコルで使われているようだ。これらの仕様書はARINCで販売されているがやたらに高い。

ACARS

山本無線ＣＱ 秋葉原にあるアマチュア無線ショップ アペックスラジオ AOR受信機、航空、気象受信関連商品販売

下位のレイヤーでは、SSB(USB)で1440HzでPSKで変調している。2PSK,4PSK,8PSKのモードがあり、1800、1200、600、300bpsの転送速度のモードがある。変調速度は1800ボーで固定である。 ということらしい。変調速度とモードと転送速度が違っているように思えるかもしれないが、おそらくFEC(Forward Error Correction)をつかっているのであろう。FECはSITORでも使われている方法。 これだけの情報だとどうにもなりそうにない。PSKのデコーダまでか、遅延のシンボル数がわかればFECまでぐらいかもしれない。あとは、PC-HFDLとかをなめるように使ってみて何をやっているか探るとかしかないのか？ やるとすれば、まず1440Hzで8PSKのデコードをするモジュールから作るしかない。ビットまで拾えればなんとかなるかもしれないが、いずれにしろ試行錯誤になるのは間違えなさそうだ。

ACARS HFDL

ソフトデコーダーでいろいろ受信してみる（２）

前回は船舶系で終わってしまったので、今回は航空系です。

ACARS

Kinetic Avionic SBS-1 SSR(二次監視レーダー)の受信 アペックスラジオ AOR受信機、航空、気象受信関連商品販売

航空系だと最もメジャーなのがVHF ACARSではないでしょうか。デコーダーもWACARSをはじめ、有償なものまでいろいろあります。日本国内では周波数は、131.45MHzがメインで、他に131.25MHzと131.95MHzがあります。131.95MHzは最近運用が始まったのですが、東京や大阪などの過密地帯向けに運用されているようです。東京では比較的よく受信できますが、通信頻度は高くありません。 あとは、HF ACARSといわれているHFDLというのがあります。名称通りHF（短波）で通信されているもので、現状ではデコードできるのは、PC-HFDLというソフトぐらいはないでしょうか。HFという電波の性格上、近くでも受信できなかったり、遠くの飛行機のデータが受信できたりということがあります。

SELCAL

SELCALというと、航空系と船舶系と両方あります。航空系は、プロトコルからANNEX SELCALといわれることもあります。このSELCALは、航空機側から管制へ自機の識別のため送信されるもので、通常はHFの管制（洋上管制）の音声通信で使われているものです。AirNavという有償のソフトウエアでデコードできます。その他にもあるようですが、特に有名なものはないようです。

SELCALはいわゆるデュアルトーン（２つの音を同時に出す、DTMLともいえる）で２回送るだけで、データー通信とはいえるかどうかはわかりません（しかし、作成は試みたことはないですが、デコードは意外に難しいかもしれません）。

こんなところでしょうか、航空系は船舶系よりもあまりデータ通信が多くないと思えるのですが、航空機からの電波は陸でよく受信できるということもあり、趣味とされている方も多いようです。

デコーダー 航空無線

ソフトデコーダーでいろいろ受信してみる

ソフトモデムを使って通信するのはアマチュア無線ではかなりあります。CWに始まり、RTTYやパケットなどのFSKやPSK31などのPSK、SSTVもあります。最近ではデジタル通信として、PSKの多重（直交なのか？）を使ったものもあります。アマチュア無線は開局してないと楽しめませんし、HFだとアンテナもそれなりのものが必要でしょう。

とりあえず、お手軽なところで受信だけで楽しめるのは何があるかというと、船舶か航空系になってしまうと思います。VHFやUHFのデジタル系の受信はソフトデコーダーでは、おそらく無理ですから。

船舶系FSK

山本無線ＣＱ アマチュア無線、ハンディGPS製品などの販売 パソコンGPSショップ GPS関連商品専門店

船舶でいわゆるRTTYでの通信はあまり多くないと思います。おそらくSITOR-Aといわれる形式(100ボー180Hzシフト）が多いのではないでしょうか。通報であるNAVTEXはSITOR-Bで同じく100ボー180Hzシフトです。これらはRTTYとエンコードの形式が違うため、RTTYのデコーダーではデコードできません。NAVTEXはデコードできるソフトがいくつかありますが、SITOR-Aの場合、ビットで同期するので、NAVTEXのデコーダーではデコードできないかもしれません。 NAVTEXは、基本的に518kHzか424kHzでSSBで受信するので、それなりの受信機とアンテナが必要です。アメリカではHFでも送信されていますので、ハワイかグアムからの通報は受信できます。

気象FAX

HFでのFAXの受信は、気象FAXが最も受信しやすいと思います。日本では気象庁が船舶向けにFAXを送っています。詳しくは、同サイトのトップの下のほうに「気象資料の閲覧・入手方法」というリンクがありますので参照してください。日本以外には、韓国、中国、台湾などが受信しやすいと思います。

気象FAXという意味では、NOAAの衛星からの画像受信があります。こちらはVHFですが、FMでIFのバンド幅が広いものが必要となり、ちょっと特殊な受信機が必要になります。あとこれらの衛星は、地上からみて静止しているのではなく、１日に２回ぐらい上空を横切ります（南北方向なので縦切り？w）。そのため高い所からの受信となるため、GPやディスコーンなどのアンテナだとうまく受信できない場合があります（この手の垂直なアンテナは真上からの電波は得意でない）。気象衛星用のデコーダもフリーなものも含めていくつかあります。受信機やアンテナなどいろいろ条件が厳しいのではまり度が高いのではないでしょうか。

今日のところは...続きはまた書きます。

CRC-CCITTの計算

モデム等の通信で多く使われているエラーチェックアルゴリズムとしてCRC(巡回冗長検査)があります。このアルゴリズムは、ハード的に比較的簡単なロジックで実現できて、検出能力も比較的高いためよく使われているようです。 CRCの原理については、面倒なのでここでは書きませんw。グーグルってもらえれば、詳しく解説されています。
CRC-CCITTは、CCITTで規格化されたCRCということになります。CCITTは現在ではITUという団体に変わっています。CRCのアルゴリズムを使って何を規格化したかというと、CRCの計算のパラメタとなる、「ビット長」「多項式(polynominal)」「初期値」「ビットを送る方向」ということになります。
CRC-CCITTでは、ビット長は16bit、多項式は1+X^5+X^12+X^16、初期値はFFFF、送りはLSB First（右送り）となります(LSB Firstはプロトコルに依存するかも)。ただし、プロトコルによっては初期値が違う場合もあるようです。
実装コードは、テーブルを使って高速化したもの等が検索するといくつかあるようですが、すなおに簡単なコードで書くと、以下のようになります。

static unsigned short _crcValue=0xFFFF;
static unsigned short _polynomial=0x8408;

unsigned short crcCalc(unsigned char data)
{
 for(unsigned i=0;i<8;i++){
  bool flag=((_crcValue^data)&0x0001)!=0;
  _crcValue>>=1;
  if(flag) _crcValue^=_polynomial;
  data>>=1;
 }
 return _crcValue;
}

１回計算すると_crcValueが変わるかもしれないので、0xFFFFで初期化してから計算するようにします。チェックするデータを順にパラメタにいれて関数を呼び出します。戻り値にCRCの値を返してますが必要なのは最後だけです(0xFFFFになっている）。
実装するときにはもっと賢いコードに書き換えてくださいねw。

WACARSのデコード

WACARSと自前デコーダーとでデコード能力を比較しているので、WACARSの「くせ」がある程度わかってきたので書いてみます。

IFのバンド幅による影響

Kinetic Avionic SBS-1 SSR(二次監視レーダー)の受信 鳳文書林出版販売 航空図、航空関連書籍販売

通常のAMの場合、6kHzのバンド幅になっている受信機がほとんどですが、6kHzの場合2400Hzの信号がやや減衰されます。どのくらい落ちるかは受信機によって異なりますが、一般的に考えると減衰するほうがよい受信機であるともいえます。WACARSでデコードする場合、1200Hzとの振幅の差が大きいと失敗しやすくなりますが、極端に悪くなることはなさそうです。おそらく、他の条件（S/Nの悪化）などが重なると影響が大きくなる傾向があるようです。

振幅の変動

ACARSはVHFなのでHFの様に信号が強弱することは基本的にはなく、ましては信号を送る時間が長くても２秒ぐらいなので、受信信号の強さが変動することは、ほぼないと思われます。

受信機によってはAGCが効くため、復調された信号の最初のほうに振幅が安定しないところが現れます。WACARSの場合、どうやらFrame Syncまでの間に振幅が変動すると失敗しやすくなる傾向があるようです。AGCの効きかたが（時間軸に対して）緩やかなだと、このような状態になるものだと思われます。

ノイズ

あえて悪い環境として、ハンディ機でPCから１mぐらい離して、付属のアンテナで受信してみると、WACARSもかなりデコードできません。波形レベルでみると弱い信号はかなり歪んで、デコードできる感じがしません。耳で聞いた感じでは信号がきているのはわかるのではあるのですが。

おそらく、ノイズが多いとIFのバンド幅などの影響が大きくなるようです。これはWACARSというよりもデコーダーでは一般的なことになります。

振幅の大きさ

要はボリューム調整のことです。受信する信号によって復調した信号の大きさ（音の大きさ）が変わりますが、特にハンディ機などでAGCが効いてない場合、その差が大きくなります。

上記の悪条件をなるべく除いてWACARSでデコードした場合、レベルインジケーターが右のほうに（大きめに）しても左にほうにしても違いはありませんでした。おそらく、条件が悪い信号をデコードするときにボリュームがあのインジケーターの真ん中にくるほうがよいという意図なのかもしれません。

終わりに

WACARSは、受信側の条件が整えば、デコード能力は低くありません。波形が多少歪んでいてもちゃんとデコードします。そういう意味ではWACARSと同等な能力を持つデコーダーを作るは簡単ではないようです。

ビットシンク

ビットシンク（正しくはBit Frame SyncかSymbol Frame Syncかも）は、変調された信号を変調速度に合わせて（同期）１か０（多値の場合には１以外もあるが）を検出することである。 これをソフトウエアで実装するのはどうすればいいのかということが書いてある文章がほとんど見つからなかったのだが、ハードウエア的にはだいたい次のようになるらしい。 まずは、信号処理で比較をして、結果が１か０になる（デジタル的になる）。０→１もしくは１→０のタイミングを検出して、そこから変調速度に合わせたクロックと同期をさせる。場合によっては、０→１と１→０の両方（順番はどちらでもよい）を検出してから同期を取る場合もあるらしい。 同期が開始されると、クロックが上がるときもしくは下がるときに１か０かどちらかであるかをチェックする。ただし、信号処理でどちらかともつかない信号が来た場合には、同期を中断して最初の状態になり１か０から状態が変わるのを待つようにする。 といった感じになるようだ、ソフトウエアでもおおかた同じようにすればよさそうである。ただ、このままだと最初の信号が不安定な時は同期に失敗するので、パケットのように最初のピットパターンだけで同期を取るような場合には、もうちょっと工夫しないと、デコードの能力はあまり高くならないかもしれない。

デコーダー/同期

ACARSデコーダーのプロトタイプ

前回ACARSのデコーダーがプロトタイプまでといったのが、ネタと思われるのもなんなので、画面のキャプチャを出してみます。あくまでもデコーダーのプロトタイプで、デコード能力のチェックやチューニング用のUIなので、説明はなしとします（質問もなしにしてくださいね）。 受信した時間が遅かったのであまりレコードはありませんが、だいたいこんな感じです。WACARSと同時にデコードすると、ほとんどは同じような結果になるのですが、ぎりぎりのところでの性能が全く逆で、WACARSが成功するとこっちが失敗して、こちらが成功するとWACARSが失敗するということが多いです。おそらく、信号処理の根本が全く違うのだと思われます。 デコード能力は、WACARSの得意な環境だと、ぎりぎりで失敗するところがWACARSのほうが少なく、ざっとみた感じでは100:95ぐらいで負けています（両方ともエラーはフルチェック）。 欠点は大体予想はついているのですが、現在パフォーマンスチューニング中のためデコード能力の改善はやってません。UseVecというのは、VelocityEngineを使うか否かという意味で、現在のチューニングのために入れています。 アクセラレータを入れずにデバッグすると、サウンドデータの取りこぼしが多くなるので、こっちを先にやっています。

ACARS デコーダー

VHF ACARSのデコード

Kinetic Avionic SBS-1 SSR(二次監視レーダー)の受信 鳳文書林出版販売 航空図、航空関連書籍販売

ACARSのデコードは、有名なWACARSやacarsdなどのデコードエンジンが使えますが、あえて自作してみようというためには、ある程度仕様がわかっていないと作れません。 VHFもHFのACARSもARINCで仕様が定められていて、仕様書は有料で入手できるようです。しかし、わざわざ購入するのもなんなので、VHFのACARSについてはネット上に情報があったので、まとめてみると以下のようなことになっています。 変調方式：AM変調　MSK 2400ボー（1200Hz/2400Hz) 符号化：NRZI　ASCII 7bit パリティ奇数 LSBから送出してからパリティ（フレーム長8bit) ビットシンク：「+」「*」の２文字でビットシンクはパリティは１で固定 フレームシンク：<SYN><SYN>の２文字 メッセージ：<SOH>から<ETX>か<ETB>まで エラーチェック：16bit　CRC-CCITT（パリティ込みでチェック） バケットの終わり：<DEL>でパリティは１で固定 となっているようです。 ビットシンクの前に2400Hzが16フレーム長を送ることになっていますが、実際にはもっと長く送っている場合もあります。仕様上1200ボーもあるようですが、実際に受信した所では聞いたことがありません。 VHFのACARSのデコードですが、MSK2400ボーというのはちょっと難しいと思います。2400ボーで1200Hzですから、１ビットで半周期しか信号はないわけです。仮にゼロクロスでデコードしようとしても、余裕はありませんからノイズ等でクロスが増えてしまったり、ビットシンクがずれてしまうとエラーになってしまうでしょう。 ACARSのデコーダーは、プロトタイプまで作成していますが、デコード能力がWACARSよりちょっと劣っていたので、現在お蔵入り状態で、チューニングしないとだめかなと思ってます。 ただし、WACARSよりはボリューム調整は、簡単（というかほぼ調整不要）に設計はしてあります。そのせいなのか能力がいまいちなのかもしれません。

サウンドデバイスのクロックは正しくない

ソフトで信号処理をするということは、サウンドデバイスから音をキャプチャーして解析するということですが、サウンドデバイスは音をA/D変換してパソコンに取り込みます。A/D変換するときのサンプルレートは、ほとんどがデバイスによって決まっていて、よくある周波数が44.1kHzです（他には22.05、11.024、48kHzや8kHzなどもある）。 しかし、44.1kHzで取り込むように指定しても、サウンドデバイスのクロックが正確でないため、44.1kHzだと思って処理をすると結果が違ってきます。 例えば、アマチュア無線のSSTVや気象FAXのような場合、サウンドデバイスのクロックを基準に処理をすると、垂直方向の同期が狂ってしまうため、見た目でおかしいことがわかります。SSTVで有名なMMSSTVというソフトでは、サウンドデバイスのクロック誤差を検出するために、標準電波（かつてのJJYの類い）を利用して垂直方向の同期を合わせる機能があります。いまはHFでのJJYがないのですが、気象庁がやっている気象FAX（JMH)で合わせるという方法あります(120rpmなので0.5秒間隔で黒いところが現れる）。 FSKの場合にも、サウンドデバイスのクロック誤差が問題にはなりますが、比較的簡単な方法で回避できたりします。例えば、ゼロクロスの場合、クロックがずれるとカウント数が変わってしまいますが、検出しようとしている周波数が２つある場合、両方のカウント数がずれることになります。正確な周波数がわからなくても、カウント数の違いだけで処理をしてしまえばよいわけです。 変調速度への同期ですが、ボーレートが遅ければさほど問題にはなりませんし、はやい場合だとサンプル誤差がそもそもあるので、1か2サンプルはズレていると仮定しておいたほうが同期させやすいです。サウンドデバイスのクロック誤差もそれで吸収させてしまうという方法があります。

FSKのデコード

激安中古 激安アウトレットPC-WRAP 中古PC,測定器,ジャンク品の販売 Joshinの中古PC J＆Pテクノランド 中古PC,周辺機器販売

FSKは周波数で信号を送っているので、解析は周波数の解析となる。FSKは１と０の状態をそれぞれ決められた周波数（または周波数間隔）で変調するので、復調は特的の周波数の信号があるかどうかを解析することである。 信号の周波数の解析方法はいくつかあるので、いくつかみてみる。

FFT（高速フーリエ変換)

FFTについては、あちこちに情報があるのでここでは詳細は述べませんが、時間軸上にあるデータ（サンプル）を周波数軸上に変換するものである。 FFTの場合、周波数の分解能力はサンプリング周波数から、変換するサンプル数を除算したもの（F/N）である。従って、解析すべき信号の周波数の差が小さいときは、それだけ多くのサンプル数を使って変換しなければならない。しかし、変調速度により解析できる時間が限られる（変調速度が速い＝サンプル数が少ない）ため、FFTで解析が利用できる場合が限られる。

デジタルフィルタ

デジタルフィルタは、入力されたサンプル列から特定の周波数以下を減衰させるHPFや低い周波数を減衰させるLPFなど必要な周波数以外を減衰させる。デジタルフィルタの設計の方法も情報が多くあるので、ここでは詳細は述べないが、設計についてはいろいろ難しい理論があるが、デジタルフィルタ設計ツールがあって、必要な情報を入れるだけでフィルタのパラメータを得ることができる。 デジタルフィルタもFFTと似たような性質を持ち、入力するサンプル数が少ないと減衰させる周波数曲線が緩やかになり、周波数幅が狭いと解析が難しくなる。

ゼロクロス(Zero crossing)

ゼロクロスというのは、信号がプラスからマイナス、またマイナスからプラスへ移るところを意味する。周期信号は１周期でかならず２回ゼロを超えるのでゼロクロスした回数を数えると入力された信号の周波数がわかるというものである。この方法はDTMFのような複数の周波数成分を持たない信号であれば周波数の組み合わせの条件により不可であるが、比較的簡単に周波数を測定することができる。 理論的には、半周期でサンプリング周波数の逆数の時間の誤差があるため、f*f/(f+2NF)[fが測定する周波数、Fがサンプリング周波数、測定する周期数]の誤差となる。 例えば、44.1kHzで1kHzを1周期でカウントとすると誤差が8.52Hzの精度で検出できる。 あとは、PLLみたいなほうほうとかあるんですが、それはまた後ほどに...

開発するための基本的な知識

カバンのセレクション ゼロ・ハリバートン,リモア,吉田カバン正規取扱店 レアもの・ユニークギフト専門店 ボブルビーなど各種グッズ取り扱い

デコーダーを作るにあたり少なくとも音を取り込まなければ、どうにもならない。 ターゲットとするOSなどの開発知識は当然必要であるが、サウンド系APIも必要である。Win32であればDirect Sound、Mac OS Xであれば、Core Audioということになる。 サウンドの取り込みは、APIからのコールバックとなるのであるが、これらはマルチスレッド(MT)で呼ばれてくるので、MTプログラミングが必須となってくる。MTプログラミングというと、セマフォ等のLockオブジェクトの使い方ということになるのだが、それ以外にOSのAPIをMTでちゃんと呼び出せるようになっていないとうまくいかない。UIがらみでのMTは結構はまりやすいように思える(特にMac OS X)。 サウンドの信号処理は、場合によってはかなりのCPUパワーを必要とする場合がある。そのため、いずれ何だかのチューニングが必要となってくる。アルゴリズム的なチューニングだとある程度の限界に達してしまうことが多く、最終的にはアクセラレータのような信号処理に特化したAPIなどを使うことになる。 Mac OS Xだと、Velocity Engineといわれるベクトル演算ユニットがある。これを使うにはvDSPなどAPIを利用する。Velocity Engineなどは、10.4ではAccelerator Frameworkに含まれている。Win32のベクトル演算ライブラリでSSE系を使うものがあればいいが、なければSSE系の命令を使うようにコンパイルするか、直接SSE系のコードを書くことになる。 いずれにしろ、ベクトル演算で計算しておくことは、信号処理のチューニングでは有効であるため、最初からコーディングしておいたほうがよいだろう。

ソフトデコーダーを作ろうとしてみる

ソフトデコーダーといってもいろいろあるのだが、とりあえずはメジャーな所としてACARSがよさそうだと思っている。 ただ、ACARSの場合、他のソフトも多いのでそれなりのデコード能力がないと、相手にされそうにもないので、作った所で使ってもらえるかどうかというのもある。ACARSは、MSK2400ボーで通信されているのであるが、これが結構デコードするのが難しそうだ。 あとは、NAVTEXの類いが良さそうだと思うのであるが、MWの受信環境を持っている人があまり多くはないし、SWで一部あるのだが、世界的な規模でもなさそうである。船舶系のセルコールも同じような方式なので、それも取り込むというのもありかもしれない。 それ以前にまともにデコードできるものが作れるのかというのもあるのだが...