窓関数

窓関数を今回のアセンブラプログラムに適用するか
どうしようか迷っていたんだけど、とりあえず付けて
見ることに。


窓関数を通さない場合（＝矩形窓）は右端と左端を
ループさせて繋いだ時にその継ぎ目でギャップが生じるので、
そのままFFTに掛けると変な成分が載ってしまうことに
なるんだけど、実は周波数分解能はこれがベスト。

一方何らかの窓関数を通した場合、周波数分解能はちょっと
落ちるけど、ダイナミックレンジが広くなる。つまり
メインローブの太さは太くなるけど、サイドローブの高さ
を低く出来るということ。トレードオフ。


ダイナミックレンジも大事なので、窓関数使おうか…
で、どの窓関数を使ったら良いかなぁ…と迷う。
http://ja.wikipedia.org/wiki/%E7%AA%93%E9%96%A2%E6%95%B0

ガウス窓がヨサゲに見えるんだけど、計算が面倒かなぁ？
まぁ、どうせあらかじめ定数テーブル化して、プログラム中
では掛け算するだけの話だからどれでも同じといえば同じ
なんだけど。


効果を視覚的に眺めてみたい…　で、ここ。
http://laputa.cs.shinshu-u.ac.jp/~yizawa/InfSys1/basic/chap9/index.htm
解り易い。スバラシイ。

ガウス窓ってメインローブが少し太って見えるなぁ。
今回の用途だと、64点FFTっていう選択肢がいろんな意味で
ギリギリの選択だったので、あまり太られると困っちゃう。

周波数分解能もあまり鈍ると困るし、ダイナミックレンジ
も落ちすぎるとどこのフレット弾いてるのか判らなく
なっちゃう…

とするとハニング窓かハミング窓だろう、ってことに
なるんだけど、ハニング窓だと折角サンプリングした
両端をゼロ掛けてしまうって言うのがもったいない
気がするのでハミング窓にしてみる。

ハミング窓の方が少しだけ周波数分解能が高く（メイン
ローブが細い）、ダイナミックレンジが狭い（サイド
ローブが高い）。

例によって、表計算ソフトでハミング窓を書けた場合の
スペクトルを可視化してみる…。
うーん。矩形窓と比べると確かに周波数分解能が若干
劣るんだけど、これならまぁ良いんじゃない？
あくまで感覚だけだけど。


ということで、早速実装。

まずはＰＣ上で定数テーブルを吐き出すスクリプトを書く。
で、そいつをアセンブラのプログラムで読み込んで、
窓を通してからFFTを掛けるように修正。


シミュレーションを掛けてみる。
うん。ちゃんと動いてる。問題なし。


ここまで出来れば、FFTについては終わりでいいや。
あとはアプリケーションを組んでいくだけってことに
なるんだけど、メインアプリ側をこのままアセンブラ
で組み上げるか、それともＣ言語関数化して使いやすく
した方が良いのか…とりあえずアセンブラでいいかな。


ここまでは”論理”の世界だけで考えることが出来た
んだけど、この先は”感性”の領域だからな。うまく
纏められるか心配。がんばろ。


話変わって。

なぜ福島にロボットが投入されないのかな？
放射能が強すぎてコンピュータが正常動作できない
レベルなのかな？と思ってたんだけど…
http://headlines.yahoo.co.jp/hl?a=20110318-00000655-san-soci

どうやらそういうことではないみたい。
申し出はしているのに、活躍の場面が設定されないと
いうことか。ザンネンだ…。

アレだな。優秀なハードは有れど、ソフトが無い…と。

つまり、有能なロボットがアレコレと存在していても、
それを災害時に適用・運用するための手順や協力体制
といったものが未整備になっているんだろうな。

どんなに優秀なハードウェアでも、いきなり現場投入
しちゃうと、効果を上げるどころか七転八倒して混乱に
拍車を掛け兼ねない。
イザというときに役に立てるためには、日ごろからの
関係機関との協調がいるだろうから、今回は仕方ない
と考えて、今後どうするかを今から考えるってことだな。

折角優秀なハードウェアが出来つつあるんだから、
それを生かすことに、今から是非取り組んで欲しいな。
ピンチをチャンスに活かすのだ。
「想定外の災害だ」と繰り返すだけではもったいない。


それにしても、ラジコンヘリくらいないのかなぁ？