Baumkuchen’s Workshop

バイオリンと電子工作、DIY、ジョギングなど。

バイオリンタイマーの製作#11-ソフトウェア(オシロ&スペアナ実装)

つぎは、練習判定の基礎となる音処理関連の実装(精緻化)です。簡易オシロと簡易スペアナ機能を作り込んで行きます。本体機能の練習時間積算タイマーは、平行して作業中。

baum-kuchen.hatenablog.com

タスク検討(ADサンプリングの割り込み化)

AD入力周期を正確に実施するため、タイマ割り込みでAD変換をするように、全体のタスク構成を変更しました。スイッチの反応も長押しをちゃんと判定できるように割り込みの中で一定周期(20Hz)で取り込むようにしました。

f:id:Baum_kuchen:20220211164405p:plain

AD変換は、3000Hzサンプリングとし、256サンプル取り込んだら、フラグによりバックグランドタスクとして走っている表示処理に受け渡す感じ。表示処理では、AD変換データが不要になったら、再度の取り込みを同じフラグにより指示。FFT処理は、今のところ、時間が掛かるので表示処理の中で実施してますが、別タスク化するかは今後の検討。

簡易オシロ機能

これで、修正した簡易オシロ機能を構築。横軸が150サンプルになるので時間にして50ms(固定)です。ADサンプリング、グラフ描画の繰り返し。縦軸は10btADCの値を60ドットで表現したもの(3.3V動作なので、PIC入力端で大体1DIV=0.5V相当です)

f:id:Baum_kuchen:20220211164615j:plain

簡易スペアナ機能

続いて、簡易スペアナ機能。横軸は周波数ですが、バーの幅を見やすく2ドットとして間に1ドットスペースを開けたので、全部で50本分のスペクトルになります。分解能が約11.7Hz(=3000Hz/256サンプル)なので、最大で586Hzとなります。

二つの数字のうち、右側がFFT演算に掛かる時間(ms)で、Sin、Cosをテーブル化して高速化したんですが、まだ、結構掛かってしまいます。Aruduinoで試した時は100ms以下だったので不思議です。

f:id:Baum_kuchen:20220211164647j:plain

(赤いドットは、ピークホールドの表示ですが、まだ、実装が上手くいってません)

動作チェック

簡易スペアナまで形ができたので、動作をもう少し正確に確認しよということで、先日、作ったファンクションジェネレータを使っての点検を行いました。

f:id:Baum_kuchen:20220211170656j:plain

デバッグ用に一部ソフトを書き換え、余ったアナログ入力端子にファンクションジェネレータからの信号を注入します。

f:id:Baum_kuchen:20220211170722j:plain

加えた信号は、400Hz、3.3Vppのサイン波。

f:id:Baum_kuchen:20220211170742j:plain

で、結果がこれ(最初の写真と同じ)です。

f:id:Baum_kuchen:20220211164647j:plain

が、よく見ると変です。横軸の4DIVのところにピークが来ていますが、そこは、40個目のバーなので、11.7Hz×40=468Hzを示していることになります。400Hzを入力して468Hzとは、あまりにもズレすぎてます。

トラブルシュート

ということで、トラブルシュートの始まりです。

まず、パッと思ったのが、FFTプログラムがおかしいのかな?と。

ただし、トラブルシュートの王道として、入り口側から順にたどって、どこがおかしいかを確認することにしました。

ADサンプリング周期の確認

最初は、ADのサンプリング周期が正しいか。

f:id:Baum_kuchen:20220211172714j:plain

デバッグ用に、余ったDIOに割り込み周期毎にBIT反転する処理を仕込んでいたので、オシロで確認すると、きっちり3000Hzで割り込みが掛かっていました。

簡易オシロモードでの確認

つぎに、折角作った簡易オシロ機能を活用しない手はない、ということで、波形を確認。

400Hzだと、50msで20波あるはずですが、なんか多いです。

f:id:Baum_kuchen:20220211173047j:plain

分かりやすく三角波として、周波数も200Hzに落としてみたけど、11.3波位あります。明らかに、13%も多いです。400×1.13倍=452Hzで、スペアナの周波数ズレと大体あってます。原因はこれです。

f:id:Baum_kuchen:20220211173209j:plain

でも、割り込み周期は正しいのに、なぜ、簡易オシロの表示がずれるのか、謎が謎を呼んだ形。

考えられることとしては、表示ソフトがバグっているとか。でも、13%ズレるバグってどんなものか相当できず。

入力信号は、本物のオシロで確認しているので、ファンクションジェネレータがおかしいということは無いので、多くの波が記録されるためには、ADサンプリングの周期が遅いことしか考えられないです。でも、割り込み周期は、確認しているし。

AD変換時間の確認

考えていても、らちが明かないので、AD変換時間が異常に掛かっていない確認することにしました。ADCの設定も、まだパラメータをちゃんと考えず、割と遅めにしてしていたのもありです。

先ほどと同じく、AD変換直後に、DIO出力を反転するプログラムを入れて、オシロで波形を見て見ました。

結果です。オシロのトリガをうまく使って、丁度、AD変換が開始されるタイミングを確認しました。ぱっと見、問題なさそうです(AD変換処理に結構時間が掛かてるなとは思いましたが)が、時間をしっかり確認してみると、1周期が380μSもあります。AD変化を実施していないとろが、約332μSでしたので、約50μSも増えています。

f:id:Baum_kuchen:20220211174346j:plain

ここで、ますます謎が深まりました。AD変換の開始タイミングは、タイマ割り込みで作っているので、AD変換を実施するか、しないかで、周期が変わるのは変です。

う~ン。分からん。

AD変換パラメータの見直し

PICのマニュアルのタイマとADCところをつぶさに読みましたが、そんな記述は、当然なしです。Microchipのホームページでエラッタ情報を確認しましたが、何もなし。
仕方無いので、AD変換の時間を短くするため、パラメータを見直すこととしました。(332μSの周期のうち、約140μSもAD変換にかかっていたので)

最初は、TAD=1/64Foscにしてましたが、マニュアルの最小値0.7μSを参考に、TAD=1μ、Fosc=8Mhzなので、1/8Foscと設定しました。これで、AD変換自体は15μSでできるはず。

ちゃんとAD変換時間が短くなっている確認です。うん。ちゃんとAD変換時間は短くなってる。よし、よし。

あれっ!?何と割り込み周期も短くなっているではないですか(336μSで4μSはカーソルの誤差)

f:id:Baum_kuchen:20220211175923j:plain

謎の3乗!!

ともあれ、治ってしまった。じゃあ、どこが影響するのか、TADの値を幾つか変えてみると、TAD=1/32Foscでは正常、TAD=1/64Foscの時だけ異常となることが判明。

そのあと、ソースコードを何回も見直しましたが、特に異常な箇所はないです。

再確認

真の原因が分からずじまいですが、ファンクションジェネレータを使っての再確認をすることに。

描画タイミングと重なってしまいましたが、200Hz入力で50mSにほぼ10波あります。

f:id:Baum_kuchen:20220211180745j:plain

スペアナモードで400Hz入力したこころですが、丁度、35スペクトル目なので約409Hzで概ね妥当な表示になりました。

f:id:Baum_kuchen:20220211180839j:plain

なには、ともあれ、治ってしまった。不思議。

今後の計画

謎が謎のまま残りましたが、これ以上、手の施しようがないので、治ってしまったことで、良しとて進めてしまいます。(製品作っているんじゃ、ダメですけどね)

次からは、本体機能の練習時間積算タイマーを仕上げていきます。それと、省電力化やFFTのさらなる高速化、スイッチ操作の細かい作り込みです。

引き続き、よろしかった、お付き合い願います。