« 2011年7月 | トップページ

2011年9月 5日 (月曜日)

沈黙の赤外線解析リモコン(最終回)

ようやく沈黙を破ってリモコンとしての役目を果たしたのもつかの間、NECフォーマットの機器に全く取り合ってくれず、またしても原因究明モードの赤外線解析リモコンの続きです。

Ir

ここで再び、UART経由で信号の状態などを見てみますが、やっぱり相変わらずのじゃじゃ馬ぶり。繋いでいる回路が悪いのか、何故かUARTを繋ぐとかなりの確率で、電源を入れた途端に(リモコン信号を送出しなくとも)「学習開始」のLEDが付いてしまいます。おそらくノイズでも乗っているんだとは思いますが詳細は不明。

そして実際のリモコン信号を学習させても家電製品協会フォーマット(以下家電協フォーマット)のリモコンのはずなのにNECフォーマットになったり家電協フォーマットになったりとフラフラ。正直表示があてになりません。

と言う事で、結局ロジアナに頼ります。波形を見る限り、概ね問題なさそう。唯一おかしなところと言えば

なぜがリーダの信号のOnの時間が異常に短い

くらいです。具体的には学習元のリモコンの1/4と言ったところ。とにかくここを何とかすればヨサゲです。

とは言うものの、「なんでこうなるの?」と言われるとサッパリ原因がわかりません。まぁ「動きゃいいんだろ?」とNECフォーマットのリーダ部Onの時間を決める変数の値を4倍するコードを書くのは簡単ですが、やっぱり理屈が伴わないとすっきりしないのでもう少し粘ります。

ふと書籍に載っていた「UARTで接続してNECフォーマットの信号を受信した時の画面」が目に留まりました。この画面ではir_readhは140になっています。これが規格通りの値なら

ir_readh = 140 → 9ms

となるはずです。
んで、この作例のプログラムではこの値を加工してir_shotと言う関数に渡すのですが、その時のロジックが

623倍してから256で割る

です。8bitマイコンならではの帳尻合わせの処理なのですが、仮に上記の値で計算すると

140 * 623 / 256 = 340(小数切り捨て)

ここで違和感を覚えます。「あれ、ちょっと待て。計算後の値を格納する変数の型なんだっけ?」と確認すると

char…

そうです。オーバーフローしてました。上位が切り捨てられて

340 - 256 = 84

となっていた模様。本来のデータと比較をすると

340 / 84 = 4(小数切り捨て)

1/4の理由がわかりました…。

データ型を見直せば最良なのですが、この変数(ir_readh)があちこちで基準となっていたのを理由に上記のとおりのコザカシイ修正で対応をした結果、手持ちのリモコンは全戦全勝と言う素晴らしいモノに仕上がりました(ちなみに著者の方は「失敗する原因はよくわかりません」「半分は成功していますから、これをもって完成とさせてください」と敗北宣言してますが、まぁ色々とお忙しかったのでしょう)

…ここまで長かった。ブログに載せるまでにかなりタイムラグがあったのですが、G.W.直前あたりから着手していて、全戦全勝確認できたのが7月下旬だったのでかれこれ3ヶ月近く。追加の設備投資(ロジアナ購入)も行った結構なプロジェクトになってしまいました(まぁ原因さえ分かってしまえばコードレビューで分かる程度の問題ではありましたが)。

つーか、最初の作例がこれってのはどうなんでしょうね?相変わらずサポートページにも言及が無い様ですし。この機会に進言してもいいのですが出版されてからもう2年経ってますしね。

と言う事で「PICとC言語の電子工作」の最初の作例のせいで「PIC('A`)マンドクセ ヤーメタ」となってしまう事を阻止すべく、「赤外線解析リモコン 動かない」で検索できるようにここに書いておきますw(さっき「赤外線解析リモコン 動きません」で検索トップに出たけど検索するなら「動かない」でしょうからね)。

あと、最初の作例で挫折した方へ朗報。この本の2番目の作例(デジタル電圧計)はサンプルが一発で動きますので売り払う前にちょっと試してみてください。まぁ、PIC12F683じゃなくてPIC16F88なので新たに買わないといけませんが(地方在住者はここが一番イタイかも)。

と言う事でこのシリーズは一旦終了です。

| | コメント (0) | トラックバック (0)

2011年9月 4日 (日曜日)

沈黙の赤外線解析リモコン(その2)

さて、UARTでデータを覗いてみれば一発で解決するかと思われた赤外線解析リモコンですが、却ってワケワカラン状態となってしまった前回。その後の顛末を記します。

結局、埒があかないのでロジックアナライザを導入する事にしました。前々からオシロも含めて「欲しいなー」と思っていた機材の一つでしたがついにその時が来たようです。まぁ、そんなに大それたものは買えないし、買っても使いこなせなかった(\(^o^)/オワタ)となっても困るので、入門機にはちょうどいいであろう、ZEROPLUSのLAP-C(16032)をチョイスしました。

購入後しばらくは使い方に戸惑い、若干の失敗(試しにやってみたUARTのbaud rate設定の仕方が分からなかった)も経験しつつ、ようやく慣れてきたところで検証再開です。まずはリモコン信号の受信センサに電源供給するだけの回路を作り、プローブを受信信号端子にかませてリモコン本体の信号を取り込みます。その後、解析リモコンに学習させた信号も取り込んで両方を比較します。

すると、「リーダとトレーラ部以外のデータは完璧」と言う、「なんだそりゃ?」的な結論が出ました。
もっと具体的に言うと、

  • リーダ部はLレベルの時間がとにかく短い
  • トレーラ部は…なんと、それらしい部分がありませんでした。

とりあえず場当たり的に、リーダ部のLレベルの時間を目測で対比し8倍の値にセット。トレーラ部はそもそも実装が無かったので追加。この2点を修正してから再度動作確認をするとようやく動作!試しにアサインしたTVの電源が付きました。ここまで来るのが長かった…。

しばし感慨に浸ってから改めてソースコードを振り返りますが、トレーラ部は「言われてみれば無いよねー」と華麗にスルーしてました。リーダ部もよくよく見ると、リーダ部の検出後に時間カウント用のタイマ分周比を変更(8bitタイマと言う事もあり、余裕でカウントオーバーフローしちゃうので最長にしていると理解)しているのですが、信号学習後の実際の送信時に分周比を戻していない!こりゃ上手く行く筈がありません。ちなみに分周比の変更前/後の比はちょうど8:1で、上記の目測の根拠はここにありました。

さて、これで一仕事終わりと行きたいところだったのですが、まだ一部のリモコンの信号しか学習出来ていません。具体的には手元にあるパナソニック製品(CATVのSTBとTV)と照明のリモコンくらい。その他の東芝製DVD&HDDレコーダやエアコン、車のオーディオやナビのリモコンは一応学習はする素振りを見せるものの、学習したデータがおかしいor送信の仕方がおかしいのか、機器が信号を全く受け付けてくれません。書籍では「勝率は50%でしたがまぁこんなもんでしょう」的記述もあるのですが、何かが引っかかりますのでもう少し粘ってみます。

現状分析すると、上手く学習出来るリモコンの信号は前回導入したロジアナで見る限り、いわゆる「家電製品協会フォーマット(以下、家電協フォーマット)」の様で、学習出来ないリモコンの信号は家電協フォーマットと双璧をなす「NECフォーマット」の様です(他にSONYフォーマットもあるんですが、この作例のプログラムでは最初から未対応を表明しているため、今回は除外とします)。

と言う事で、再び原因の究明モードに入るところで次回へ続く。

| | コメント (0) | トラックバック (1)

« 2011年7月 | トップページ