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

ソフトで信号処理をするということは、サウンドデバイスから音をキャプチャーして解析するということですが、サウンドデバイスは音を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で一部あるのだが、世界的な規模でもなさそうである。船舶系のセルコールも同じような方式なので、それも取り込むというのもありかもしれない。 それ以前にまともにデコードできるものが作れるのかというのもあるのだが...