前回から引き続きの「巡回型移動平均」の２回目は、「巡回型に潜む魔物」を「かいまみる」予定でした。しかし魔物の召喚に失敗した模様。フツーに動いてしまいました。これではいけない、と無理やり魔物を登場させてみましたが、本当に無理やり、何やっているの？という感じ。こういう意外な挙動も「巡回型」？
※「手習ひデジタル信号処理」投稿順 Indexはこちら
例によって、勝手に手習ひさせていただいとりますご本へのリンクをまず掲げます。
三上直樹先生著、工学社『「Armマイコン」プログラムで学ぶデジタル信号処理』
例によってご本のネタバレにならぬようソースの引用等は行いませんが、三上先生の御ソースはArm社のMbed環境上で公開されています。
今回のブロックダイアグラム
今回使用のブロックダイアグラムを冒頭のアイキャッチ画像に掲げました。前回の櫛型フィルタから積分器という流れをヒックリ返し、積分器から櫛型フィルタとなっております。
要素の順序をヒックリ返しても基本的に同じ、とはいうものの、個人の感覚的には今回の順番の方がなにかシックリきますな。無限に続く積分の、あるところまでの結果から、N個まえまでの結果を差っ引けば、N個分の積算値が残るだろ～という感じ。それをNで割れば平均値だよね、と。そんなボーっとした感覚で良いのか。
そこで気づくのが積分器です。基本「無限に足し込んで」いってしまうので何かDC的なオフセットがあればきっと有限なビット長の変数メモリを溢れてしまいそう。そんなところが今回の魔物の正体なのかしらん、と想像する次第。そして今回使用のブロックダイアグラムには積分器の「フィードバック」のところに定数0.999という値ありです。教科書によると、原理通りのブロックダイアグラムとしては1.0（つまりはそこの三角など不要）であるべきところ、1.0であるとフィルタが動作せず「一定値を吐き出す」ようになるので、0.999とせよ、と。積算した結果を「少しづつ削ってやれば」微妙に値は不正確になるかもですが、溢れは防げるのではないかと想像します。そんな理解で良いのか？
プログラムをビルド
Arm MBedのWeb環境を使ったビルド結果は以下に。まだまだSTM32F446REのメモリには余裕ありです。
実行結果
まずは、積分器のフィードバックに教科書ご指示の0.999を挿入してある場合。入力信号としては前回もテストで使用した250Hz、1V振幅の信号を入れてます（黄色C1）。青色（C2）が出力です。
前回同様にフツーに動いているようです。
ボーデ線図も取得してみます。
これまた前回同様。
さてフィードバックのところを1.00に変更してみた
当然ながら正弦波が出てこなくなることを期待して動かしてみました。しかし御覧じろ。
期待は「一定値」だけれど、動作しているじゃん！
無理矢理「ダメ」な様子を作ってみた
予定と違って1.0でフツーに動いてしまっているので、「ダメ」になったときの様子がみれません。無理やりフィードバックを1.01にしてみました。これであれば１より大なのできっと「ダメ」になる筈。
期待どおり出力がオナクナリになりました。でもまあ、人為的、当然ですかね。１より大きな値でフィードバックかけたら溢れるに決まっている。予定どおりであれば1.0でこうなったのかな？
魔物をカイマ見たというより、「仕込み」「やらせ」の類の今回であったので、切実さがありませなんだ。第３回に期待を込めて、今回はここまで。