オーディオ/ミニアンプ0.3/改善

不満な点を改良/改善していきたいと思います。当初考えたよりもコストパフォーマンスが悪るかった。スピーカドライバをもっと簡単にできなか。アナログB入力が実用レベルではない。

スピーカドライバの再考

スピーカドライバはゲートドライバ+パワーFETブリッジの構成にしています。これは、確実なスイッチングを実現していますし、部品表で見ても大したコストでもなく、十分良い設計と思われます。

しかしながら、自作のしやすさを考えたら、もっと安く単純にしたいと思いました。

  • 内蔵DACとD級アンプでスピーカ駆動
  • I2S経由のスピーカ駆動
  • 入手性の良いモータドライバを利用
  • Hブリッジ直結

内蔵DAC+D級アンプ

ESP32には8bitのDACが2チャネルあるので、直接ステレオのアナログ音を出力する事ができます。これを、省電力型のD級アンプICでスピーカを駆動すれば良いのです。解像度には若干不安はあります。

D級アンプのICは豊富に提供されており、かつ低価格なので、作りやすく一番コストダウンできる構成だと思われます。が、私的にはそそりません。途中にアナログが介在してしますためです。

I2S出力デバイス

I2S経由で直接スピーカをドライブするICがあり、かなりのコストダウンできる可能性がありました。

  • たまたま低価格で入手できるデバイスがあった(出物的商品)
  • 結局内部ではDAC+D級アンプ
  • 高価なモジュール、もしくはパッケージが手ハンダ困難

1品物の工作なら良いと思います。特定のデバイスに制約されてしまうので、2番手の構成と考えます。

モータドライバ

スピーカのPWM駆動は、Hブリッジでスイッチングするだけなので、モータードライバも全く同じ回路構成になっていますので流用が可能と考えました。これは、たくさんの品種があり保護機能が充実、価格も安いものがあるので注目していました。

初代BTSP01で使いましたが、3値制御ができませんでしたので、省電力上不利でした。論理上は問題ないはずなので、腑に落ちません。原因を考えると

  • 制御信号の与え方が間違っている/制約がある
  • スイッチングスピード

制御信号の使い方のミスがあるかどうかについては、中音量以上では割と良い音が出ていますので、間違っているという訳ではないと思います。

そもそも、モータドライバのデータシートにタイミングに関する事柄の記述が十分ではなく、44.1kHzのPWM駆動が完全に出来るのか確信が持てない部分がありました。具体的には、PWMピリオド周波数のMAXを超えない範囲にしていますが、あるデバイスでは最小パルス幅という項目があり、これが最小デューティー値で問題があるかもしれません。44.1kHzで10bitの場合1/(44100*1024)=22nsが最小パルス幅となります。

以下に、入手しやすいデバイスのPWM周りのタイミング仕様一覧です。

最小パルス幅が明確になっていないものは全て問題ありです。モータドライバ系は、概ねダメなようです。それどころか、直FET駆動でも気をつけないといけないレベルです。とは言え、データシート上明確になっている訳ではないので、もしかしたら使えるかもしれません。(まわりの数値から無理っぽいとは思いますが)という事で、2つのデバイスを実際テストしてみました。

  • TB6612(100kHz)
  • TC78H653(500kHz)

テスト環境は、デバイスは秋月電子のモジュール基板を利用し、ブレッドボードでESP32開発ボードとスピーカを配線します。BTSP03のソフトウェアをそのまま使い3値制御された44.1kHzのPWMを生成し、音源はBluetoothで440Hz正弦波を与えます。

TB6612はきたない「ポー」音でした。やはり、BD6211と同じような感じです。

TC78H653はきれいな「ポー」音でした。やはり、違いました。以下は、スピーカー出力のシグナルをオシロスコープで観察したものです。これを見る限り、きれいなスイッチング波形です。

予想通り良さそうなので、次に音楽などの音源を入れてみます。

  • 小音量領域になるとざらつき感が出てきます
  • 音量が大きいと全く問題なく聞く事ができます
  • Hi-Fiレベルとは言えません

ボリュームを絞ると顕著です。予想するに、小duty値でのスイッチングが不十分なのかもしれません。私の感想では、平均音圧が大きい音楽やテレビ放送では、使えると感じました。

モータードライバでも、PWM周波数が大きい品種は省電力オーディオにも使える可能性を持っているようです。Hi-Fiには無理でしょうが、使える場面は多いと思います。結果としては、消費電力を気にするアプリケーションで、さほど音質にこだわらない場合は、安価にできるデバイスだと思われます。

ESP32のADC性能を再調査

ESP32のADC性能が良くないという判定になっていましたが、本当にこんな製品を出す訳はないはずだと思い、再再度の確認作業を実施することにしました。

調査項目

無音時のノイズが一番気になるので、この部分を中心に調べたいと思います。また、入力レンジについても確認していきます。

  • 無音時のノイズ
  • 入力レンジ(電圧幅)

テスト環境

ESP32-DevKitに、固定電圧とシグナルジェネレータで生成した正弦波を与えて、ADCでの連続キャプチャを行わせます。実際のオーディオキャプチャの状況にしたいので、2CH×44100kHzでの条件にします。数値データだけでは、ノイズが減ったのか増えたのか判断しづらいので、スピーカに出力して実際耳で聞いてみたいものです。

今回は、BTSP03のソフトウェアをそのまま使い、PCMデータをダンプするデバッグ機能で、キャプチャデータを記録したり、スピーカ出力での確認をしていきます。固定電圧は可変抵抗器で作り、シグナルジェネレータはADALM2000を使います。

  • 無音データとして、仮想グラウンドレベル電圧を与える
  • レンジぎりぎりの正弦波シグナルを計測器で生成
  • ステレオ44.1kHzでサンプリング

テスト項目

テスト数を最小に、漏れがないように、テスト項目を整理しました。

確認したいことを要約すると以下の通りです。

  • アナログ入力ピン(チャネル)毎の違い
  • 変換ビット数の影響
  • サンプリング速度との関係
  • 内部アッテネータ適用でノイズが減るか
  • 仮想アナロググラウンド(AGND)生成用分圧抵抗値の影響(バイアス電流の確認)
  • 外部信号処理(パスコンの有効性、それ以上の外部回路が必要か)

テスト実施

「idf.py -p /dev/cu.zzz monitor」で、波形データのダンプが出るまで2〜3秒待ちます。この表示されたダンプデータをコピペ、編集してcsvデータに変換(grep,awk,sedを駆使すれば1行コマンド)します。それを表計算ソフトに取り込みます。折れ線グラフにするのは1操作で済みます。

レンジ確認

計測を進めると以下の問題が発生しました。

  • 入力レンジとADC出力値の相違
  • チャネルが変わるとAGNDレベルが変わる
  • オーバーシグナルで反転する

入力信号は、無音用に一定電圧のAGNDを用意します。アッテネータの設定によって、電圧レベルが異なりますが、データシート上の各アッテネータ設定時の電圧範囲のまん中では、ADCの出力は2048(12bitの中間)にはならず、かなりズレるようです。どう計算するのかドキュメントを洗いましたが判明しません。結局、レンジを調べる為のSIN波をダンプから折れ線グラフにしつつ、逆設定となりました。

ADC入力チャネル毎に平均値が変わってしまう事案が確認されました。元々は、AGNDは固定電圧との想定のもと、左チャネルの平均値を内部のAGND値としていました。色々なケースでデータを取ると、右チャネルデータは何割かシフトしていました。そこで、チャネル毎にAGND値を取得するソフトウェア改修を行いました。

test#1(CH0+3、基本)
test#2(CH4+5)

今回、限界シグナルレベルを確認する事を行いましたが、上限/下限をオーバすると、現状維持か、0値となるようです。マイナス側では結果的に大きな歪み感がないかもしれませんが、プラス側でいきなり0(=-max)になってしまうので、聞いていられない音になるでしょうでしょう。ドキュメントを精査すると、12bitの場合4096カウント全てを使うわけではなく、3000ぐらいで有効範囲があるようです。波形を見ながら、試行錯誤で一定値(4080)を超えるデータは信頼できないと判断するロジックをソフトウェアに組入れ、とんでもない波形にならないようにしました。この辺りは調整項目です。

test#3(CH6+7)

詳しくは、添付の表計算ファイルのグラフを参照ください。

ノイズ確認

1テストは3回実施し平均値を取り、つまらない間違いで混乱しないようにします。

データは1000サンプリングを対象にしています。数値はRAWデータではなく、PCM16ビットに変換した後の値です。元のADCデータにするにはn/16+2048で計算します。

良い悪いの判断を数値的に行うためには、どのような見方をすれば良いか考えました。

  • 平均値は基本的に0になるはず(test#10はプログラムバグによるものだった)
  • 最大/最小の差を見ましたが、実聴とは合わないような気がする
  • 最大ー最小差では全体の傾向を掴むのは不十分
  • データの分布を調べれば、より正確に見られると思い、標準偏差で見てみた
  • 実聴と合致している感じなので、これで判断

以下、テスト項目と付き合わせた結果、有効な対策優先順位です

順位対策標準偏差
1アッテネータ適用(-12dB)350
2パスコン適用(0.1uF)450
3マルチサンプリング(x3)600
4特定のチャネルを使う(CH4+5)700

test#4,#5の変換ビット数の項目については、非常に良い数値が出ていますが、それぞれx2, x4で考えなければなりません。それでも10bitがノイズに強い感じです。とは言え精度が減るので気がすすみませんので除外する事にしました。

test#99-4(全対策後)

1〜4を全て適用した追加試験「test#99-4」をしたところ、標準偏差100まで減りました。グラフでも一目瞭然、スムーズな線です。実聴ではプチプチ音はありますが、ほぼ聞こえない状態となり、うれしい限りです。最大ボリュームでは聞こえるレベルですが。全ての対策を行う事で、実用レベルの性能があると判断できました。ただし、入力レベルが高いので、多くの音源に対応するには、プリアンプの装備が必要です。

その後、1〜2日実生活で使ってみたところ、「チ、チ、、プチ、、、プチ、、、」とい感じで、100ms~1sぐらいの周期でランダムなプチ音が入っている事が気になってきました。また、1時間以上の周期で「ブチッ」という大きなノイズも入ります。ダンプで波形を確認すると確かに入っています。ADCのRAWデータを確認するため、マルチサンプリングを止めてみました。そうするとプチプチ音が全く無くなるという偶然に当たりました。x2までは大丈夫なようです。原因は未確認です。タイミング的なものと想定しています。

なぜ当初検討時にはダメだったのか

今回は良好な結果を得られましたが、なぜ前の開発ではノイズが多かったのかが腑に落ちません。


投稿日

カテゴリー:

, ,

投稿者:

タグ:

コメント

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です