スピーカアンプのICモジュールは複数のIC製造メーカから色々な種類が出ているが、 それらの多くは、入力・出力両方か少なくともどちらかがコンデンサでカップリングされたACアンプとなっている。 音声用のアンプとしては問題ないが、加振器をドライブするためのアンプとしては、DCまで出力できるアンプが必要になる。 DCまで出力可能なアンプとなると、市販品では高価なものが多く、できたら安価なICモジュールで制作したい。 TDA1517はアンプモジュールの一つで、上記の通り基本的にはACアンプである。安価にDCアンプを作るために、 オフセットをオペアンプで調整し、DCアンプとして使用するための方法を考えてみる。
アンプモジュールには、オペアンプタイプと、ゲインが固定されているタイプがあり、今回取り上げたTDA1517は、 ゲインは20dBに固定されており、負帰還を調整する必要がない。 オペアンプのタイプのICモジュールの場合は、負帰還と位相補償の調整を行う必要があり、 ゲインが固定されているタイプに比べてオフセットを安定させるのがやや難しいことがある。 TDA1517の場合、BTLでは入力のみ、ステレオ出力では入出力でコンデンサカップリングであり、 DCアンプとするためには入力でのオフセットを調整した上で出力はBTLを使用する必要がある。 データシートには明示されていないが、BTL時の出力の基準電圧は電源電圧の約半分で(Vcc/2)、 入力端子のオフセットは、電源電圧が12Vの時大体2V程度となっている。 正入力と負入力にそれぞれオペアンプでオフセットを調整して入力すれば良い。 左右のオフセットは調整されていないので、両入力のオフセットとも別個に調整できるようにする必要がある。 ちなみに、TDA1516だと、入力の基準電圧が外部に出ており、これを使うこともできるが、 それでも左右のオフセットの誤差が無視できないことがあるので、調整は出来るようにした方が良い。 一番簡単な方法は、半固定抵抗で2V程度あたりに仮想GNDを設定し、入力は仮想GNDを中心とした信号として入力し、 正入力はオペアンプのボルテージフォロワで受け、負入力はオペアンプの反転増幅回路で作成し、オフセットはオペアンプの非反転入力で調整する。 ゲインが20dBあるので、ノイズについては注意する必要があり、使用する帯域によって、位相補償を行う。 入力インピーダンスがかなり適当になっているのと、入力のグランドとはフロートにする必要があるのに注意。 オペアンプはグランド付近まで入力・出力可能なタイプを選定すれば良く、必ずしもR2Rでなくて良い。 今回は手元にあったAD8666を使用した。AD8666は、入力はグランド-0.1Vから電源電圧-2V、出力はR2R対応である。
ちなみに、今回のアンプでドライブする加振器はS-0105 (WaveMaker Mobile) という有限会社旭製作所が製造・販売している機種で、周波数特性は下図の実線のようになる。点線は一般的なACアンプで、特に100Hz以下の低周波の出力が不足していることがわかる。 加振器に附属する電力増幅器+ファンクションジェネレーター+振動計も販売されているが、最新機種ではD級アンプになっており、通常用途では問題ないのだろうが、 今回の研究では高周波ノイズが問題になるため、自前で用意することになった。旧型アンプではデジタルアンプでなくてノイズは少なかったようだが、 発熱等の問題が大きく切り替えられたと思われる。
For example, I was taught in college that one ought to figure out a program
completely on paper before even going near a computer. I found that I did not
program this way. I found that I liked to program sitting in front of a
computer, not a piece of paper. Worse still, instead of patiently writing out
a complete program and assuring myself it was correct, I tended to just spew
out code that was hopelessly broken, and gradually beat it into shape.
Debugging, I was taught, was a kind of final pass where you caught typos and
oversights. The way I worked, it seemed like programming consisted of
debugging.
For a long time I felt bad about this, just as I once felt bad that I didn't
hold my pencil the way they taught me to in elementary school. If I had only
looked over at the other makers, the painters or the architects, I would have
realized that there was a name for what I was doing: sketching. As far as I
can tell, the way they taught me to program in college was all wrong. You
should figure out programs as you're writing them, just as writers and
painters and architects do.
-- Paul Graham
-- "Hackers and Painters" ( http://www.paulgraham.com/hp.html )
A lot of software developers are seduced by the old "80/20" rule. It seems to
make a lot of sense: 80% of the people use 20% of the features. So you
convince yourself that you only need to implement 20% of the features, and you
can still sell 80% as many copies.
Unfortunately, it's never the same 20%. Everybody uses a different set of
features. In the last 10 years I have probably heard of dozens of companies
who, determined not to learn from each other, tried to release "lite" word
processors that only implement 20% of the features. This story is as old as
the PC. Most of the time, what happens is that they give their program to a
journalist to review, and the journalist reviews it by writing their review
using the new word processor, and then the journalist tries to find the "word
count" feature which they need because most journalists have precise word
count requirements, and it's not there, because it's in the "80% that nobody
uses," and the journalist ends up writing a story that attempts to claim
simultaneously that lite programs are good, bloat is bad, and I can't use this
damn thing 'cause it won't count my words. If I had a dollar for every time
this has happened I would be very happy.
-- Joel Spolsky
-- "Strategy Letter IV: Bloatware and the 80/20 Myth" ( http://www.joelonsoftware.com/articles/fog0000000020.html )