(2015/2/28 補足) 本文中に部品選択に関する記述がありますが、いろいろな製品で試した結果、現在推奨している赤外線受信ユニットは
GP1UXC41QS、赤外線 LED は
L-53F3BT です。
(2016/7/1 補足) Digispark 赤外線受信シールドに使われている赤外線受信ユニット TSOP38238 も適していますが、国内での入手が難しいかもしれません。
まえがき
AVR マイコンATTiny85 で学習型万能赤外線リモコンを作った。
※ エアコンのリモコンも学習できるようになった
※ 実際に作ってみたい方は
Wiki (←リンク) を参照 。
※ この技術を応用して USB から制御できる赤外線リモコン(
リンク)を作成した。
|
プリント基板版 |
|
ブレッドボード版 |
実際に作ってみるまで分からなかったことが結構あって、今後赤外線リモコンを一から自作する人の参考になるかもしれないので、こちらのブログに、感想とか工夫した点とかノウハウっぽいことを書いておく。
赤外線リモコンの制作は電子工作ワールドでは人気テーマで、検索すると制作例が山のように出てくるので、新しく開発するからには何か特徴がないとおもしろくない。そういうわけで、今回の設計では「リモコンの種類(通信フォーマット)によらずなんでも学習できる」赤外線リモコンを作ることを目標にした。
また、ピン数の足りない安い8pinのマイコンで作れるように、学習と送信とその他の操作を全て1ボタンで操作できるようにした。
「なんでも学習できる」リモコンをわずかなメモリしかないマイコンで作るのは大変だ。受信した赤外線データを生のまま不揮発メモリ(内蔵EEPROM)に記憶して、それを送信する仕組みにすれば「なんでも学習できる」は実現できるが、そのためには生データを記憶しておくための不揮発メモリが大量に必要になるためだ。
これを解決するにはデータを圧縮するしかない。しかし、どんなデータでもきっちり圧縮できる (ZIPみたいな) 本物の圧縮アルゴリズムを作るのは難しいし、特にコード用のメモリも RAM も少ないマイコンで実装するのは簡単ではなさそうだ。そこで「赤外線リモコンに特化した、簡単で万能で効率の良い圧縮アルゴリズムを考える」という作戦にした。
工夫の結果、自分の身の回りのリモコンについてはほとんど学習して不揮発メモリに保存できるようになった。
ただ圧縮がリアルタイムではできない(赤外線信号をサンプリングする速度に追いつかない)ため、圧縮前の生データを一時的にマイコンのメイン RAM に記録する必要があり、そこがネックになっている。メイン RAM のサイズが 512バイトのマイコンでは、1つの信号が RAM サイズを超えるために学習できなかったエアコンのリモコンがある。可能ならいずれ改良したい。 → この問題は、赤外線の受信中にリアルタイムにランレングス圧縮を行う機能を実装して解決した。
赤外線リモコンのフォーマット
赤外線リモコンのフォーマットについては、ELM さんの「
赤外線リモコンの通信フォーマット」がとても詳しい。これによると、日本では主に NECフォーマット、家製協(AEHA)フォーマット、SONYフォーマットが使われているので、この三種類の規格に対応できればよさそうだ。
と思っていたがこれはだいぶ甘くて、実際に身の回りのリモコンの信号をサンプリングして見てみると、微妙に規格に沿っていないものがかなり多かった。
まずは手持ちのリモコンの信号を片っ端からサンプリングして見てみることにする。AVR
マイコンでサンプリングした信号をシリアルで出力して、可視化するプログラムを VisualBasic 2008
で作ってみた。やはり可視化は重要で、生の数字を見るよりはるかに分かりやすい(赤い線と緑の線があるが、圧縮する際の参考用に色を変えているだけなのでここでは無視してよい)。
|
サンプリングした信号を可視化するプログラム(Visual Basic 2008)
Hが点灯、Lが消灯状態。赤外線受信モジュールの出力は負論理でこの図とは逆なので注意。
搬送波は赤外線受信モジュールで除去済み。 |
テレビのリモコンのフォーマットはばらばら
ビデオプレイヤーなどの AV 機器のリモコンにはたいてい他社のテレビを操作する機能がある。試しに Panasonic のブルーレイレコーダ DMR-BR670V のリモコンで、各社のテレビのリモコンの「電源」ボタンの信号をサンプリングしてみた。メーカー名の後のカッコの数字はこのブルーレイレコーダ独自のメーカーコード。同じメーカーに複数のメーカーコードが割り当てられているのは、同じメーカーでもテレビの機種によって送信するデータが異なる場合があるということ。
上の図を元の大きさで表示する
※ 図の1ドット=50[μs]。Hが点灯、Lが消灯状態。赤外線受信モジュールの出力は負論理でこの図とは逆なので注意。
|
各社のテレビのリモコンの赤外線フォーマット(各社対応リモコンからサンプリング) |
サンプリング結果を観察してまとめてみたのが上の表。フォーマットはかなりばらばらだ。特に特殊なのはシャープ、ビクター、三菱のテレビだが、それ以外にも独自フォーマットの機種がある(上の図と対応させるために、全く同じデータの場合も表には重複して載せている)。
独自フォーマットのシャープ(02)とシャープ(11)にはリーダーがない。 また 30~50[ms]の間隔をあけて2つの異なるパターンが連続で送られてくるので、両方記録しないといけない(※図にはないが、シャープのVHSビデオデッキ VC-VS1 もこれと同じフォーマットだった)。シャープ(21)は素直な家製協フォーマット。シャープは昔は独自フォーマットだったが、最近の製品は家製協フォーマットに準拠したということだろうか。
ビクター(14)はリーダに続いてまず16bitのデータを送信する。その後同じデータが反復されて送られてくるが、反復の方にはリーダがなく、いきなり16bitデータから始まっている。手元にあったビクター製VHS/DVDデッキ用リモコン(RM-SHR013J)も同じフォーマットなので、これがビクター独自のフォーマットなのだろう。
三菱(08)と三菱(12)はリーダはなく、データも6bitのみ。必要最小限といった感じ。
受信側の機器の挙動にも注意が必要。Panasonic のアナログテレビ TH-15FA5 は、電源を OFF にするときは、素直な家製協フォーマットの信号に反応する。その直後は同じ信号で電源 ON にできる。しかし、電源を OFF にしたあと数分たつと、テレビが内部的にパワーセーブモード(?)になるらしい。パワーセーブモードからは、電源 ON のパターン1つを受信しただけでは ON にならず、最低1回は同じデータを反復受信しないと電源が入らない。さらにその場合は、最初のデータと反復データの間が40ms以上開いていないと電源が入らなかった。誤動作しないように、電源 ON のボタンだけは厳密に判定しているようだ(※シャープの AQUOS テレビ LC-20DZ3(家製協フォーマット) も同じような挙動)。
テレビ以外のリモコンのフォーマット
テレビ以外の機器のリモコンもサンプリングしてみた。
上の図を元の大きさで表示する
※ 図の1ドット=50[μs]。Hが点灯、Lが消灯状態。赤外線受信モジュールの出力は負論理でこの図とは逆なので注意。
|
テレビ以外のリモコンの赤外線フォーマット |
三洋のプロジェクタ LP-XP100L は天吊りの大型のもの。ビクターの DVD プレイヤー RM-SHR013Jはビクターの独自フォーマットだった。シャープのエアコン(AY-Z22VX)は家製協フォーマットのようだがやたらに長い。蛍光灯のリモコンの信号もやたら長い。
TV会議システム VSX7000 は、米国 POLYCOM 社の製品。
これはちょっとクセのある挙動をする。1つのボタンに2つのパターンが割り当てられていることがあって(数字ボタンなど)、そのボタンを押すたびに2つのパターンが交互に出力される。また、リモコン本体を床から持ち上げるとスイッチが入って、自動でいくつかの信号を送信する。
WOLFVISION の卓上カメラはこういう製品。リモコンのフォーマットはソニーフォーマットに似ていた。(後に自作リモコンが完成した後に試したところ、電源 OFF は確実にできたが、電源 ON に失敗することが多い。原因は不明) → (2015/2/28 補足: 若干長めに学習してしまうバグがあったため。修正したら ON/OFF ともできるようになった。ただし赤外線の到達距離が短く、近距離からのみ)。
赤外線信号の保存形式(EEPROM 保存時の圧縮)
以上の観察結果をふまえて、赤外線信号の保存形式を設計することにする。
万能のリモコンにするためには、どんなフォーマットだったとしても正しく保存・再生ができる必要がある。また、容量の節約のためにできる限り短いデータ形式で保存したい。そこで、受信した赤外線信号を次の形式で EEPROM に保存する。
まず、基本方針として、一連の赤外線パルスの発光時間を、そのまま生で保存することにする。ただし、信号の途中にビット列とみなして短縮(圧縮)形式で保存できる部分が見つかった場合は、その部分は可能な限り短縮形式で保存する。
まずは圧縮せずに、発光時間を生のまま保存する方法について。信号がうまく圧縮できない場合はこの方式で記録することになる (ただし後述の方法で、部分的にでも圧縮できるところは圧縮する)。
どんな赤外線信号でも、最初は赤外線 ON から始まって一定時間継続し、その後にOFF が一定時間継続する。これの繰り返しである。そこで、ONの継続時間と OFF の継続時間を測定して、15bit の値としてそのまま保存する(時間は2バイト値で保存するが、後述する短縮形式との区別のため、最上位ビット(MSB)は常に0にしておく。そのため実際のデータが保存できるのは 15bit)。この形式では必ず ON と OFF のペアで記録することにし、一つの ON+OFF のペアで 4バイトのメモリを消費する。時間の計測は 72kHz の割り込みで行っているので、1[秒]÷72[kHz] = 13[μs] が1単位になる。15bit 値では 32767 まで表現できるので、ON も OFF も最大 32767 * 13[μs] = 425971[μs] = 425.971[ms] までの時間が記録できる。
|
赤外線信号の記録形式 (EEPROM上のフォーマット) |
次に圧縮の方法を考える。圧縮のための短縮形式で記録する方法について。
赤外線信号にはさまざまなフォーマットがあるが、大抵どれも下の図に示した 「短いON」「長いOFF」「長いON」「短いOFF」 の4種類の時間の組み合わせで表現できる(リーダーや区切りなど特殊な部分以外は)。そこで、取り込んだ信号全体を一度プレスキャンして、4種類の時間がそれぞれ何μs になっているかを、パルス長の平均をとるなどしてがんばって求める。そしてこの4種類の長さを EEPROM の別の領域に保存しておく。
|
赤外線信号を構成する4種類の長さ |
実はここに工夫できる余地がある。一種類のリモコンには、普通はこの4種類の時間のうち3種類しか存在しない。なぜかというと、一般的なフォーマット(NEC、家製協、ソニー、ビクターなど) はどれも、ON か OFF
かどちらかの長さは固定で、もう片方の長さで1か0かを表現しているから。そのため、普通は、
プレスキャンした結果を見ると「(A) 短いONと長いONは同じ長さだった」
または「(B) 長いOFFと短いOFFは同じ長さだった」のどちらかの結果になる。つまり4つの値のうち、(A)または(B)は同じ値になる。
同じ値があっても気にせずに、取り込んだ一連の信号と上の4つの値を順次比較し、取り込んだ信号の中に「長いON+長いOFF」 が見つかったら 1 「短いON+短いOFF」が見つかったら 0、としてエンコードする。この2種類以外のパターンは考慮しなくてよい(比較する時には測定誤差を考慮して若干のマージンを持たせる)。
以上の方法で判定すると、結局、下の表の上の段の4つのパターンは1として、下の段の2つのパターンが0として判定される。 これだけで、一般的なフォーマット(NEC、家製協、ソニー、ビクターなど) なら、うまい具合に 0 と 1 のビット列に変換でき、後から同じ波形を再生できる。再生する時は、同じ4つの値を使って、ビットが1なら「長いON+長いOFF」 を、0なら「短いON+短いOFF」を出力すればよい。
※ 分かりにくいので補足: 要するに長いONまたは長いOFFのどちらかを含むパターンは1、どちらも含まないパターンは0とエンコードするということ。一般的なフォーマット(NEC、家製協、ソニー、ビクターなど)ならこの方法で再現できる。
※ ただし1と0のパルス長が同じ長さのフォーマット(変調方式が PPM でない)もあり、その場合はこの方式でビット列化できない 。YUASA の扇風機のリモコンはそうだった。その場合は圧縮できないので生で記録するしかない。
0 と 1 の列に変換したら、ヘッダを付けて 0/1 のビット列を記録する。ヘッダは目印として MSB(最上位ビット) を 1
にする。ヘッダの MSB 以外の 7bit には、その後に続くデータのビット数を格納する。続くデータの長さが中途半端な場合は 8bit
単位でパディングする。
もしこの方法でエンコードしている最中に、0とも1とも判定されない長さのパルスが出てきたら(信号の途中にリーダーや区切りが入っているとそうなる)、一旦パディングしてビット列の短縮記録を止め、その特殊な長さのパルスだけは生のまま4バイトを使って記録す
る。その後にまたヘッダを付けて、ビット列の記録を再開する。
|
受信した信号を 0/1 の列に変換する (EEPROM上のフォーマット) |
一旦ビット列に直せれば、その後はいろいろな圧縮アルゴリズムが適用できるが、今回はこれ以上圧縮せずにそのまま記録している。
最悪のケースでは、全くビットに直せない信号の場合には全て生のまま記録することになるが、ともかくこの方法なら、どんな信号がやってきても記録することができる。
追加: リアルタイムランレングス圧縮 (エアコンのリモコン対策)
上に 「赤外線信号の保存形式(EEPROM 保存時の圧縮)」 として、EEPROM に保存する時に容量を節約する方法について書いた。これによって、保存先の容量は少なくてもよくなった。大抵のリモコンの信号が96バイト以内に収まるようになるので EEPROM が512バイトのマイコンでもある程度の信号が保存可能である。
保存するときはそれでよいが、問題はリアルタイムに学習している最中のメモリ不足。学習中は受信した赤外線を一旦 RAM に記録し、これをあとで上記の方法で圧縮することになる。ところが TINY84 は EEPROM だけでなく、RAM も 512 バイトしかない。しかも、信号の保存専用に使える EEPROM と違って、RAM は変数やスタック (割り込みを使うと、割り込みの前後で多数のレジスタをスタックに PUSH/POP しないといけないため、結構なスタックが必要になる) のために消費されるので、赤外線信号の記録に使える RAM は、実質的には 330バイトくらいしかない。TV などの通常のリモコンなら収まるが、エアコンなどの長い信号は 330 バイトに収まりきらなくなる。そうなると学習できないという事になる。
そこで、学習時には RAM に記録する前にリアルタイムにランレングス圧縮を行い、RAM から読みだす時はリアルタイムに展開するようにした。この方法で、従来の方法では RAM 不足で学習できなかったダイキン、日立製エアコンの学習が可能になった
今回とった方法は以下の通り。まず RAM 上で数値を記録する時の表記方法の規定。下記の3種類のいずれかの形式で表現することにする。
|
RAM 上のフォーマット |
0~63 までの数値は形式1、64~16383 までの数値は形式2で保存する (16384 以上の数値は表現できない)。形式2では、上位-下位の順に記録する。形式3はランレングス圧縮された値を示し、保存してある「直前の値」 を 「繰り返し長」の回数繰り返す。
「直前の値」について、今回の工夫として、RAM の奇数バイト目と偶数バイト目を分けて扱うことで圧縮効率を上げている。RAM に記録すべき生のリモコンの信号は 、ON の時間長と OFF の時間長を交互に並べたデータである。よって、常に偶数バイト目は ON の時間長、奇数バイト目は OFF の時間長を表している。ON 同士、OFF 同士は同じ値になることが多い。そこで、今回は「直前の値」として、着目しているのが奇数バイト目なら直前の奇数バイト目の値、偶数バイト目なら直前の偶数バイト目の値を使うことにした。
上記の表の表現形式でランレングス圧縮を行えば、データは短くなることはあっても長くなることはない。(奇偶ごとに1個おきに)同じ値が頻出する赤外線信号では、これだけで必要な RAM の量はかなり減る。
問題はマイコンでのランレングス圧縮の処理時間だった。赤外線信号の送受信はタイミングが重要なので、72kHz のタイマー割り込みのイベントハンドラ内で行っている。そのため、期間内(13.9μs)に送受信に関する全ての処理を終わらせないといけない。クロック数で言うと 222 クロックしかないわけで、今回そこにランレングス圧縮の処理が加わることになる。これは難しいかと思ったが、AVR-GCC の最適化オプションを速度優先 (-O3) にすることで何とか間に合った。
学習結果の EEPROM への保存
学習結果は AVR 内蔵の EEPROM (容量 512バイト) に保存する。その際、独自に開発した AVR-GCC 用内蔵 EEPROM 簡易ファイルシステム を使っている。ファイルシステムについては別途記事を書いたので、
そちら (←リンク)を参照。
部品の選択
重要な部品は AVR マイコン、赤外線LED、赤外線受光ユニット、ピエゾブザーである。
AVR マイコン
ATTINY85-20PU-ND
回路の心臓部のマイコンには
ATTiny85 を採用した。DIP 8pin(表面実装でないタイプ)の製品。価格は Digikeyで1個買うと199円。25個まとめ買いすると1個当たり161.16円。Aliexpress では 20個まとめ買いで1個当たり
US$1.25 くらいの店があるようだ(Aliexpress は中国の通販サイト。送料無料の店もあるが、その場合注文してから届くまで遅いときには1か月くらいかかる)。マルツだと215円、秋月では扱っていない(2014年6月)。Futurlec は $5 の送料がかかるが(またこちらも届くまでちょっと時間がかかるが) 1個 $1.15 と安い。たくさん買うなら Futurlecで。
スペックは、フラッシュメモリ8KB, RAM512B, EEPROM512B。電源電圧は4.5~5.5V。以前 LAN から操作できる赤外線リモコンをATMega64(フラッシュメモリ64kB, RAM 4kB, EEPROM 2kB) で作成したことがあるが、今回の ATTiny85はそれと比べるとかなり非力。
ATTiny85 は CPU クロックに、内蔵発振回路(外付け部品なし)の 16MHzが使える(High Frequency PLL Clock)。これはとても重要。クロックを遅くすれば消費電力が減るので省電力的には有利なのだが、今回は RAM の少なさをカバーするため、学習中にランレングス圧縮を行うなど結構なことをしていて、72kHz の割り込み時間内にそれらの処理を完了させる必要がある。そのためクロックが 16MHz でないと間に合わないところがあった。
ATTiny85 にはシリアルインタフェースがない。学習したデータを出力して PCで確認する必要があったので、そのために後日ソフトウェア UART (送信部分のみ)を自作した。(追記: 後日受信部分も作成して、PC から本機をコントロールできるようにした)。
ケースの都合上、回路をボタン電池 LR44*3個の 4.5V で駆動する必要があり、 省電力が重要になった。一定時間操作がないときは AVR をパワーダウン状態にしている。パワーダウン中の消費電流は 2μA 以下。消費電力を削減するために、ADC やコンパレータをソフトウェア的に OFF にしている。また、内蔵プルアップ抵抗を使うとパワーダウン中の消費電力が激増するので、内蔵プルアップは使わず、外付けのプルアップ抵抗(10kΩ)にした。
問題はパワーダウン状態にするときに BOD(Brown-out Detector) を無効にしないと、パワーダウン中の消費電流が 20μA 以上に跳ね上がること。ATTiny85 のデータシートには「ソフトウェアで BOD を無効にするためにはリビジョンが C 以降(ATtiny85, revision C, and newer) でないといけない」と書いてあるが、リビジョンの調べ方がわからない。リビジョンについて、まず米国 Digikey に問い合わせてみたが、明確な回答は得られず。次にアトメルジャパンに問い合わせたところ、「リビジョン C 以降にあたる製品は車載用の型番のみで、通常品では BOD をソフトウェアで ON/OFF することはできない」とのこと。やむを得ず、ヒューズビットの設定で BOD を常時無効にした。BOD が常時無効だと、ショックで EEPROM が消えることがあるがしかたがない。
ソフトウェアの開発には GCC (avr-gcc-4.5.1_1) を使った。 開発は FreeBSD9.2 で行った。avr-libc-1.8.0,1 を利用し、ソフトウェアは本当に一から全部作った。AVR への書き込みには FreeBSD でavrdude-5.11 を使い、FreeBSD マシンのパラレルポートと ATTiny85 を直結して書き込んだ。これらの必要なソフト (avr-gcc-4.5.1_1 avr-libc-1.8.0,1 avr-binutils-2.20.1_1 avrdude-5.11) は FreeBSD 9.2 の ports に全部あった。
#追記(2014/6/8)
マイコンに ATTiny85 を選択したのはなかなか絶妙だったかも。DIP 品があり、外付け部品なしでクロック16MHz が実現できる AVR 製品がほかにない。ATTiny85の難点は RAM が 512Byte な点。本当は RAM が 1kByte の品(ATMega8など)を使いたいのだが、ATMega8 を 16MHz で動かすには外付け部品が必要。ATMega8U2 なら、外付け部品なしでも 16MHz で動かせそうだが、DIP 品がない(おまけに高い)。
赤外線LED
OSIR5113A
(現在は L-53F3BT を推奨します)
ボタン電池 LR44*3個の 4.5V 電源で数mの距離から使えるリモコンを作るには、実質この赤外線 LED を選ぶしかなかった(2014/6/25: 電源をリチウムコイン電池 2個直列の 6V にする場合は、東芝の赤外線 LED, TLN105B の方が照射角度が広くてよい。到達距離は結構短くなるが)。
2014/8/20 追記: TLN105B は入手しにくい(ディスコン?)。広角に照射したい場合は共立エレショップで取り扱いのある
L-53F3BT を使う。
赤外線 LEDの使い方は通常の LED と同じだが、光っても肉眼で見えないので選ぶのが難しい。最終的には実際にリモコンとして使ってみて動作を見るしかなかったりする。主なパラメータは順方向電圧(VF)、最大電流、
放射強度、半値全角など。もちろん
小さい電流で放射強度が大きく、半値全角が広い方がよいが、トレードオフになっていて、どれかを犠牲にして選ばなくてはいけない。 TLN105B, TLN103, OSIR5113A などを試して、最終的にOSIR5113A を使うことにした(高輝度版のOSI5FU5113Aというのもあったが試していない→2014/6/21 高輝度版のOSI5FU5113A で試してみたが、大きな違いは見られなかった)。 OSIR5113A は VF=1.25V, 最大電流が 100mA, 半値全角が15度。指向性が強いので受信部を狙わないといけない。秋月で100個まとめ買いすると1個7円。安い。
電源がひ弱なアルカリボタン電池(4.5V)なので、赤外線 LED に直列に入れる電流制限抵抗の選び方は難しい。抵抗値が大きいと赤外線 LED の発光が弱すぎて本当に近くからしか使えなくなる。かといって抵抗値が小さいとボタン電池が電源の場合は、発光時に電源電圧が瞬間的に下がって誤動作するし、スイッチング電源などを電源にすると AVR に過電流が流れてリセットがかかる。ぎりぎりの選択で 51Ωにした。
2014/8/20 追記: 電源が 6V の場合は 100Ω にする。
赤外線受信モジュール
RPM7138-R
(現在は GP1UXC41QS を推奨します)
電源、GND、信号出力(VOUT)の三本足。電源を入れると VOUT が H になり、赤外線を受信している間だけ L になる。これもいろいろな製品が出ている。これまではずっと秋月で 1個50円くらいの製品(OSRB38C9AA等) を買って使っていたが、動作がデリケートで、電気的ノイズ、周囲の明るさや蛍光灯の影響で、赤外線信号が入っていないのに誤検出することがよくあって困っていた。
一度近所のマルツ仙台店で RPM7138-R を買ってみたら、使い勝手がすこぶるよかったので、以後少々高いけれどもずっとそれを使っている。まずこの製品は電源電圧がかなり下がってしまってもなんとか動作してくれる。また、オシロスコープを使って確認してみると、赤外線信号をかなり忠実にサンプリングできている。日本のロームという会社の製品で、
ロームの赤外線モジュールのカタログを読んでみると、正確に受信するためにかなりいろいろな工夫をしていることがわかった。プラスチックパッケージで、電源電圧は 4.5-5.5V。消費電流は 1.5mA。マルツだと1個158円。Digikeyだと1個200円。10個まとめ買いすると1個当たり157.7円。
消費電流の 1.5mA は結構大きいので、赤外線受信モジュールの電源 を AVR の出力ピンからとって、不要なときは電源を切るようにしている。このような使い方をする時の注意点として、赤外線受信モジュールの電源を ON にした直後にすぐに受信を開始してはいけない。誤動作する。動作が安定するまで 100ms くらい待ってから受信をスタートするようにした。
低電圧(2.7V)で動作する版(RPM7238-R)も存在し、本当はそちらを使いたいのだがまだ手に入らない。低電圧版が手に入れば、システム全体を 3V のリチウムコイン電池で駆動できそうなのだが。
2014/7/7 追記: 低電圧で動作するロームの赤外線受信モジュール RPM7238-H8R(電源電圧: 推奨2.7~3.6V, 最大6.3V) を入手して試したところ、システム全体を 3V のリチウムコイン電池で駆動できた。赤外線信号の学習も特に問題なくできた。ただし低電圧版モジュールにはプラスチックパッケージ版がなく、全て金属シールド付きなので、回路はそのままでよいが、部品の配置を変更する必要がある。
2014/7/7 追記: RPM7238-H8R の金属シールドを外せば形状は 5V品の RPM7138-R と同じ。シールドを外してみても一応動作はしたが、ノイズ耐性などは不明。
2014/8/20 追記: 秋月の
GP1UXC41QS が 2.7V~5.5V で動作し、ノイズにも強くてよいことが分かった。金属シールドはなく、外装はプラスチック。ピン配列はロームの赤外線モジュールと同じ。
ピエゾブザー
PKM13EPYH4000-A0
学習開始やエラーなどをビープ音で知らせるために、ムラタのピエゾブザー
PKM13EPYH4000-A0 を使っている。秋月で1個30円。Digikey で1個68円。なぜかこの製品だけ安い。サイズが小さくてよいが音が少し小さい(今回は操作確認音に使うので音は小さくてもよしとする)。ブザー単品(円盤状の金属)だけでも売られていることがあるが、その状態だと本当にかすかな蚊の鳴くような音しか出ない。黒い樹脂ケース部分の設計が重要のようだ。ピエゾブザーは電圧をかけただけでは鳴らず、AVR で鳴らしたい音程のパルスを生成して送る必要がある。今回はタイマ割り込みで 440Hz と 880Hz の矩形波を作って鳴らしている。