うまく行かず…

例によってFFTのライブラリをカスタムしながら
シミュレーション。出力数値のワイドレンジ化と
計算誤差を小さくするのをなんとか両立でき
ないかともがく。


表計算ソフトのシミュレーションでは行ってない
パターンも色々試してみると…予想外にレンジを
はみ出るケースがいっぱい。うーん…

やりようによっては両立できないこともないと
思うんだけど、あっちを立てればこっちが立たず…
みたいなことがいっぱいあって悩ましい…


多少の処理時間の長さに目をつぶってしまえば
ある程度の速度は得られるんだけど、最大で
数千クロック単位で長くなっちゃう。うーん。

あと、直流成分はどうしようもないんだよな…


あ、あともう一つ忘れてた。実数と虚数に2組の
信号を投入して、1回のFFT計算で2組の信号を
処理しちまおうと思ってたんだった。これも
加味すると、いま目論んでる方法でどこまで破綻
せずに処理できるのか、もう一度表計算ソフト
で洗いなおしておこうかな。

カスタム版のFFTをシミュレーション掛けてみる

ここのところのメインマシン／サブマシンはともに
windows7マシン（64ビットと32ビット）なんだけど、
とにかく使いにくいところがいっぱい。

特にエクスプローラの機能削減が信じられないほど
ユーザビリティーを損ねちょる。と毎日思っちゃう。

一つ上のフォルダに移るのに専用のボタンがなく
なっちゃったし、フォルダツリーが意図に反して勝手に
スクロールしちゃうし、名前順じゃなくて更新日順に
しておくとフォルダ開くたびにソート処理で10秒くらい
取られるし、ファイル検索は「ファイル名」なのか
「ファイルの中身」なのか明示できなくなっちゃってるし。

さらに、ファイル一覧の自動整列が強制的に適用されちゃう。
オイラはフォルダによってはあっちこっちにアイコンを
グループ分けして置いておきたい派なのに…こればかりは
代替機能らしいものは存在しないのだ…

と思ってたら、こんなソフトが。
http://www.forest.impress.co.jp/docs/serial/okiniiri/20101214_413910.html

やっぱ不便に思っていた人ってあちこちに居るのね…
でも、元々OSの仕様としてユーザーが自由に設定できる
様にしておけばよかったのに。なんで削っちゃうんだろう？


マルツのメルマガから555特集ページに。
https://www.marutsu.co.jp/user/mame/166.htm

これいいねぇ。自分で555を組んじゃうとか。
楽しそう。

前から555を使いこなせたらマイコン使わなくても
アレコレ出来ちゃうだろうからお勉強したかった
んだよな。
マイコンだと単体ではせいぜい5Vまでしか扱えない
けど555ならもっと広い電圧で使えるし…と。

目論んでいるのは、昇圧／降圧回路をコンパクト
に組めないか、ってこと。チャージポンプにしても
チョッパーコイルにしても、555だけで電圧監視
まで行って能動的かつスムーズに電圧を制御
できないかなぁと。


例によってFFTのカスタム化。シミュレーションを
立ち上げて、適当な数値を流し込んでみる…

そこそこちゃんと動いているんだけど、直流は
2倍の数値になるんだったのを忘れてた…。レンジが
溢れた。まぁ直流は参照しないからどうでもいいと
いえばどうでもいいんだけど。

あとは、1/2倍を端折った段があるせいでノイズ
（計算誤差）が捨てられずに残っちゃってるなあ。
このノイズをうまく圧縮しないとレンジを広めた
意味が薄まっちゃうからなぁ…

まぁ、もう少しちゃんとテストケース考えながら
カット＆トライで弄ってみよう…。

PENTAX O-GPS1

なんと頭のいい！！

http://www.pentax.jp/japan/news/2011/201107.html

さすがオイラのペンタックス。凄いことを考える
もんだなぁ。赤道儀が無くても簡易的な追尾撮影
が出来ちゃうなんて…

ペンタックスは撮像素子式の手振れ防止だからできる
仕組み。これがキャノンみたいに光学式手振れ防止だと
原理的に不可能なんだなぁ。こんなことまで考えた
上でペンタックスは撮像素子側の手振れ防止を採用
したのかなぁ？

で、オイラのK-7はこれ使えるのかなぁ？デフォルトで
使えないにしても、ファームアップで使えるようには
出来そうな気がするんだけど…
で、いくらなんだろう？気になる…


ふとまたタイプトリップ。
http://retrocomputerpeople.blog.so-net.ne.jp/2009-09-10
PC-DOSって高校生がつくったんだ…すげぇ。

http://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%A3%E3%83%AA%E3%83%BC%E3%83%A9%E3%83%9C
キャリーラボ。ちゃっくんぽっぷ移植したのって
キャリーラボだったのかぁ。このBASE-80って、
面白いなぁ。アセンブラのプリプロセッサみたいな
感じなのかな？
Z-80だとレジスタの数とか、レジスタの直交性とか
の問題とかからむしろ使い勝手がよくなさそうな…
AVRみたいなレジスタ構成のCPUの方が向いている
んじゃないかな？

そんなプリプロセッサがあれば、命令表とにらめっこ
しながらコード書く必要ないのにな…。



というわけで、今日はオイラ謹製128点FFTアセンブラ
ライブラリのカスタマイズに手を動かす…。命令表と
にらめっこしながら。

8ビットレジスタの加減算で、+127～-128のレンジから
はみ出たら、それぞれ+127、-128に強制的に圧縮して
しまうというロジックを挟み込む。

固定小数点のFFTでは、1段計算するごとに1/2倍（右に
1ビットシフト）することで8ビットレンジから
あふれないようにしているんだけど、窓関数掛けたり
とか色々している都合、どうしても出力レンジが
狭くなっちゃう…その対応として、途中１～２段分は
1/2倍の計算を端折ることにして、いざレンジが
はみ出ちゃったら圧縮しちゃうっていう作戦。

で、まずは落書き帳に表を書いて、計算結果とフラグ
の変化を纏めてみる。うん。Ｖフラグを参照すれば
はみ出ることが検知できそうだ。

で、命令表を見ながらＶフラグでブランチする命令を
探してみると…見つからん…

チョイチョイ使うＣフラグやＺフラグ、はたまた
この間初めて使ったＳフラグ用であればBREQとか
BRGEとか、もはや命令表を見ずにソラで出てくる
命令がある一方、ブランチできないフラグがあるの？
とかしばし呆然としてしまった…

ら、好きなフラグレジスタでブランチ出来る命令が
ちゃんとあった。BRBCとBRBSね。こんな命令、知らん
かった…。データシートはちゃんと見ないとね。

SREG中の何ビット目のフラグかを指定する形式だから
コードの見易さはイマイチだけど、要望どおりの
命令がちゃんとあったよ。まぁ、そりゃそうだよね。

ちなみにコードのバイナリ値を眺めてみると、例えば
Ｃフラグ（SREGの0ビット目）なら、BRBC/BRBS命令を
Ｃフラグで使用するときと同じコード（下位3ビットが000）
になってる。予想どおり。
まぁ、あれだね。Ｖフラグみたいに専用命令が
設けられていないフラグには、見易いマクロでも
組んでおけばいいのかもしれない。おいらマクロは
嫌いなんだけど。


見つかったところでコードを書き進めてみる。

当初より512クロック増加するってレベルで
組み込むことが出来てホクホク。まぁ、+127～-128
からはみ出るケースがあるともっとクロック数は
増える恐れがあるんだけど、そういうケースは
ほぼないし、万一あった場合に計算処理が破綻
しないための作りこみだから、
　　　　　　「通常発生することは無い」
という前提で組んじゃって問題なし。

とりあえずまた1歩前進。


うーん、一つ気になるのは、この出力結果で複数の-128
（2進数で0b10000000）が生じた場合、その後続の
加減算処理でたまたま（(-128)+(-128)）を行うと処理
が破綻しないか？ってこと。
-128の場合には強制的に-127で上書きしてから処理
すれば破綻しないのはわかってるんだけど、毎回それを
やると動作クロックが大幅に増えちゃう…

シミュレーション掛けながらしばらく考えてみよう…
まぁ、いくらでもやりようはあるわけだから、あとは
動作クロックをどれだけ削れるか…だな。

FFTの倍速化

例によってFFTライブラリのチューニング。

今日は、前に作った表計算ソフト用のFFTシートを
ちょこっと作り直して、128個の実数を2組同時に
FFT掛けちゃうとどうなるか…っていうシミュレート。

2つの実数データの組（128個×2組）を、片方を実数データ
として、もう片方を虚数データとして入力しFFTを掛け、
出力データを偶関数・奇関数の性質をうまく使うと
分離できるっていうあれ。
http://www.kurims.kyoto-u.ac.jp/~ooura/fftman/ftmn2_1.html#sec2_1

で、これを愚直に表計算シートに反映していきたいところ
なんだけど、最初で躓く…。

データ数が128点なら、N=128ってこと。それなのに、
データは0～127の計128個。/A(N-k）なら最初の要素は
/A(128)だから、129番目の要素ってことになっちゃう
ジャン！

まぁ、入力するデータは循環していることというのが
FFTの大前提だから、ちょっと考えればすぐに答えは
わかるんだけど、オイラ的にはどこかに何かちゃんと
書いてないかな…って思って探してみる。あった↓。
http://homepage2.nifty.com/m_kamada/math/fftmul.htm#parallelfft

ここの(m=0のとき…）という件。

添え字Nのデータと添え字0のデータは一緒ってこと。
やっぱね。

ということで、表計算シートのFFTに加味してみる。
早速いくつかの波形を入力してみると…　やっぱり
ちゃんと2つの波形の周波数成分に分離できる。ｏｋ！


さて、それが出来たところで何を確認したいのかって
いうと…

実数側と虚数側にどんな波形を入れた場合、丁度山と
山がかち合って、レンジが広がっちゃうのかってこと。

さすがに周波数があまりに違っちゃってるとかち合わ
無いのは想像できるんだけど、同じ周波数のデータを
ためしに入れてみると…　普通に計算できちゃう…。

うーん。位相を90度ずらしてみる…。出た。

どうやら位相を90度ずらしてみる（sinとcosとか）と、
計算途中の数値に実数側、虚数側それぞれに入力した
データが丁度ぶつかってしまうっぽい。

その点だけ気をつけておけば、まぁ今回の用途では
実用上問題無さそう。

で、イザぶつかっちゃった場合の対処方法（処理方法）
なんだけど、とりあえずレンジを越えた分は
　　　「一定のレンジに圧縮しちゃう」
っていう無理やりな方法にしたいんだけど、例によって
数値計算の誤差で問題になるのは「差を取る時」
なので、FFT結果から実数側・虚数側に分離するときに
誤差を拡大してしまう恐れがあるわけ。

で、そういう処理をさせてみた場合を表計算上で
シミュレートしてみると…　まぁ、それなりに
大丈夫っぽい答えが出てきた。よし、よし。


例の出力レンジを広げる（S/N比やダイナミックレンジを
もうちょっと広げたい）っていう話と絡めて、破綻しない
方法に落とし込んで行きたい所。

そこまで出来ればカスタマイズ版のFFTライブラリと
してはバッチリって感じじゃぁないかなぁと。

こうやって2つのデータ群をいっぺんにFFT掛けられちゃう
なら、128点FFT（1回あたり約62000クロック）でも4弦を
4chのまま取り込むことが出来るし、なにより2ch同時だから
2回のFFT計算でｏｋ。
計算上は1秒間に130回近く処理できるはず。まぁ、2chに
分離する処理とか、そのほかメインルーチン側の処理など
もアレコレあるので、実際は100回程度かな。

それでも遅延は1/100秒程度と考えれば、せいぜい3m先
まで手を伸ばして弾いている感覚。怪物くんウクレレ
とまでは行かないんじゃないかな。

FFTライブラリをカスタマイズ

例のアセンブラで書いたFFTライブラリをちょこっと
カスタマイズ。

元々計算過程が8ビット幅（正負値）だから各スペクトル
の出力は直流成分でも最大で127。交流成分ならさらに
半分。そしてハミング窓を掛けているためさらに約半分
のエネルギーに半減。最大で30前後（10進数）しか
出力されないんだけど、これだとレンジが狭いだけ
じゃなく、S/N比が悪すぎ。ノイズなのか信号なのか
判別できん…

ってことで、計算式の途中を弄って出力幅を広げる作戦。

思いつくままちょこっと弄ってみた感じでは、出力幅が
およそ2.8倍（当社比）、ノイズ成分もちょっと大きく
なっちゃっておよそ2倍。
結果的にS/N比は1.4倍程度改善した計算なんだけど、
もうちょっと何とかしたいところだな…

さらにアイデアはあるんだけど、これ以上やるとレンジ
をはみ出ちゃう可能性があり、その場合はみ出た分を
削ったりしないといけない…それを適用しちゃったら
1回のFFT計算で2セット分の信号を扱っちゃうというアレ
http://www.kurims.kyoto-u.ac.jp/~ooura/fftman/ftmn2_1.html#sec2_1_1
が適用できなくならないかなぁ…と。

まぁ、弦の振動なら直流も無視できるし、色々考えれば
大した影響ないと思うんだけど。例によって表計算
ソフトで弄り回してみようかな…



それとは別に、秋月のハイパワーRGB-LED
http://akizukidenshi.com/catalog/g/gI-03745/
をゲットしてあるんだけど、コイツを使って机用の
ミニライトを作りたいところ。

輝度を調整できるだけじゃなく、色温度も変化
出来るように…と。
最初からそういうのが売られてればいいんだけどな。