OSC仙台から帰ってきましたら、東京の暑いこと暑いこと!!
さすがにこれは尋常ならざる温度ですので、自宅でもエアコンを使うことにしました。

…で、エアコンを使うという事は赤外線リモコンを使うということなので、OSC仙台のモチベーションを維持している間に、少しでもGVCの赤外線モジュールの開発を先に進めようとがんばることにしました…いや、実際にはこの暑さでモチベーションはかなりダダ下がりなのですが。(^-^;;;

さっそくですが、赤外線には大きく分けて

・NECフォーマット
・家電協フォーマット
・SONYフォーマット

があります。

これらを区別しないと受信や(再)送信の処理が成り立たないので、まずはフォーマットを理解しないといけません。

で、実際に

http://d.hatena.ne.jp/hijouguchi/20101225/1293281541

を参考にして、リモコンデータを読んでみて、

http://elm-chan.org/docs/ir_format.html

を見てフレームの冒頭部分を解析してみました。(-/_は一つ当たり250usごと、のはず)

123456789012345678901234567890123456789012345678901234567890123456
Victor(NECフォーマット)
________________________________-----------------__------__------_…

TOYOTOMI(家電協フォーマット)
_____________------__-----__-__-__-----__-----_--__----__--_--__-_…

SONY(SONYフォーマット)
_________--_____--___--_____--__---____---__--___--_____--___--__-…

まずは冒頭のリーダー部の解析です。

Victorのを見ると、-/_の数が

32×250=8000us、17×250=4250us

となっています。NECフォーマットは冒頭が16T(8992us)、その次が8T(4496us)なので、だいたいあっているかな？ 足りない分はArduinoそのものの処理時間でしょう。

次にTOYOTOMIを見てみると、

13×250=3250us、6×250=1500us

となっています。家電協フォーマットは冒頭が8Tでその次が4Tなのだけど、この1Tの時間が曲者で350～500usもあるらしい。長いほうで計算しても、8T=4000usにもなるのだが、一応割合的には合ってるみたい。

最後にSONYを見てみると、

9×250=2250us

SONYフォーマットはいきなり4T(2400us)のあとにデータが来るんですが、リーダー部としてはこれもだいたい合ってる。

ここで何をしないといけないかと言うと、各フォーマットごとにデータを表す単位『1T』が違うので、最初にフォーマットを判断して、その後はサンプリングデータ数をそれぞれの1Tで比較してビット判定をしないといけないという事です。

例えば家電協の8Tは最短で2800usなので、SONYの4T(2400us)と区別するには冒頭が2600us(？)よりも短かったらSONY、それよりも長いなら今度は4000usちょっとまでなら家電協、それよりも長くて9000us程度までならNEC、それら以外の場合には…どうする？みたいな。

信号のH/L(ここでいう-/_)のサンプリングは1Tが充分に判別くらい(四倍？)で計測しないといけないので、一番1Tが小さい家電協の350usをきちんとサンプリングするとなると、87.5usかそれよりも短い間隔でサンプリングしないといけませんね。

で、フォーマットを検知できたら、あとはそれぞれのフォーマットに従い、データ部分を解析することになります。

更に注意しないといけないのは、SONYはデータ部のH/L構成が、他の二つのフォーマットと異なるということです。

・NECと家電協は信号有り→無しで、1ビット
・SONYは信号無し→有りで、1ビット

これらを理解した上で、赤外線リモコンのデータ(フレーム)を

・データフォーマット
・実際のデータ

として分けて、データは01を寄せ集めてバイト変換することにより、PICでも扱えるだけのデータ量に収められれば言うこと無しなのですが…果たして如何に!?

TOYOTOMIのエアコンリモコンはホントにデータが長いけど、結果として0/1判定をバイトデータに変換できたら多分大丈夫なはず…たぶん。笑