ユーザー名:

パスワード:


パスワード紛失

新規登録
ビートス オンラインショップへ
アブソリュート株式会社様へ

赤外線送信がドロップされる不具合

前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 .2 .3 | 投稿日時 2017-3-31 21:26
ryahp  <ROOKIE>   投稿数: 2
PCから赤外線命令を送信するときに一定の確率で送信に失敗し、データ無しのIRコードを送信する現象が起きていました。そのため、単発の命令を送っても何も起こらないことがよくありました。

打開策として自作のコマンドラインツールで命令を連続で二重に送ることにしてきましたが、最近コードを読み直していたところ単純なミスに気づきましたので報告いたします。

送信を実施するタイマー駆動の割込み式ルーチンでは送信データの有無を出力バッファ(uc_out_buff)の0番目のバイトにデータが書き込まれているかで判断し0以外の場合に送信を開始する。
しかしUSBから送信データが受信された場合(ReceivedDataBuffer)、出力バッファには0バイト目から順にデータがコピーされます。(2.1.0ソースでは1206行目付近)

> for(fi = 0; fi < OUTBUFFER_SIZE; fi++){
> uc_out_buff[fi] = ReceivedDataBuffer[fi+1];
> }

そのため、出力バッファの書き込みが終了する前に割込み式ルーチンが送信を開始し、フォーマット用のデータが不正だった場合、送信を中断してしまうことが起こりうる。

0バイト目のデータを最後に書き込むようにすると(たとえば次のように後ろから順にコピーする等)、この中断は起こらなくなります。

> for(fi = OUTBUFFER_SIZE-1; 0 <= fi; fi--){
> uc_out_buff[fi] = ReceivedDataBuffer[fi+1];
> }

というわけで、この部分を修正するとますます便利になると思いますので、ご検討よろしくお願いします。




以前からリモコン無しで入手したアンプ等をPCから連携制御するためとても重宝しています。

トップページのFWでは最近入手したONKYOのアンプが反応しなかったため、赤外線信号をUSBオーディオ入力で解析してみたときに実際に空のIR命令が出ることがあることに気付きました。
また、2.1.6でも対応しているそうですが(こちらでは未確認)全体的にタイミングが遅かったためTimer0の初期値を0xff79に調整しています(2.1.0では0xff6A)。
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-4-1 1:19
disklessfu  <EXPERT>   投稿数: 198
全くご指摘のとおりで、uc_out_buff[0]をフラグ代わりにするのであれば、普通、uc_out_buff[0]は最後に書き込む必要があります。

チップの処理速度がある程度あるので、正常データの場合は問題が露呈しないようですが、コード的には危うい状態ですね

BTO社純正最新FW2.1.0はもう更新されないかもしれませんが、
Ver 2.1.6 v3を更新する際には対応しようと思います。



ONKYOについてですが、
私はVer 2.1.6 v3の作成者ですが、ONKYOに対応させたつもりはありません。そもそもONKYOの赤外性フォーマットのデータを持っていません。
ただし、他の追加で対応させた機器と同一フォーマットだった場合、図らずも対応している可能性はあります。



Timer0周期についてですが、そもそも純正FWは、丁度100us周期を狙って値を設定していると思われます。
しかし実際には処理が間に合わなくて、117us周期あたりになっています。

私はBTO社や各ユーザーが、117us周期版で既に使用していることを踏まえて、
ずっとTimer0設定値を変えないまま、改良版FWを随時公開してきています。
(BTO社がVer2.1.0公開時に周期が(意図しない?)117usであることに気づいていたかは定かではありません)

Ver 2.1.6では、NECフォーマットがさすがに既定と違い過ぎていると判断して、Timer0設定値はそのままに、
NECフォーマット用のカウント値を変更し、波形を既定のものに近づけています。
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2017-4-1 11:28
ryahp  <ROOKIE>   投稿数: 2
以前使っていたPioneerのミニコンポでは8バイトで、(1バイトごとに反転した確認パターン)REMOCON_CT_TRANS v2.exeでも結構な頻度で2−3回ボタンを押さないと反応しなかったりしていました。これは命令の長さよりPC側のUSBのタイミングによる可能性もありますが…

複数回連続して命令を送っても前の処理が終わっていなければ単発の命令しか出なかったので自分のプログラムでは確認しなおしたところ二重でなく五重に送っていました。

ほかにもうまく動作しない人がいるようでしたらぜひトップページの2.1.0も修正した方がいいかと思います。(せっかくのガジェットが不安定で不便なものとして使われなくなってしまいそうですから。)私としては長年の(?)なぞが解けて既に満足していますが。


また、ONKYOは普通にNECフォーマット(4バイト)を使用しているが、タイミングの許容範囲が狭かったようです。
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-4-26 22:38 | 最終変更
disklessfu  <EXPERT>   投稿数: 198
投稿された直後に、最後の行(ONKYOは…タイミングの許容範囲が狭かったようです)を読み、
Ver2.1.6で対応したと言われた理由をガテンしただけで、放りっぱなしにしていました。


1行目ですが、
>2−3回ボタンを押さないと反応しなかったりしていました。
これは学習時のことでしょうか?送信時のことでしょうか?

私は数年間、(REMOCON_CT_TRANS v2.exeを使わない)実際の運用で、毎日何十回も送信に使用していますが、送信で失敗することは皆無です。
なので、送信に関しての信頼性は高いと思っています。
(2017年11月9日追記:次レスで訂正)


しかし1行目を読んで、「そう言えば、学習時にやり直しすることがある」ことを思い出しました。

私は今まで、学習に失敗した場合、学習させたいリモコンの送信部とBTO社リモコンの赤外線受光部が相対する角度を
正確に正対させるように調整し直すと次は成功する確率が高い、ような気がしていました。

しかしもしかすると、それは気のせいで、単純な確率の問題だったのかもしれません。

いずれにしても、対応フォーマットだと、いつまでも学習できない、なんてことはないので、今まで気にしていませんでした。


2行目(数え方により3行目)についてですが、
実運用では(相手側機器の応答時間分、必ず時間を空けるので)連続して送信することはないので気にしていませんでした。
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-11-10 1:14 | 最終変更
disklessfu  <EXPERT>   投稿数: 198
遅ればせながら、msg# 1.2.1の訂正(自己レス)です。

前レスで
>私は数年間、(REMOCON_CT_TRANS v2.exeを使わない)実際の運用で、毎日何十回も送信に使用していますが、送信で失敗することは皆無です。
>なので、送信に関しての信頼性は高いと思っています。

と書いたんですが、独自版のファームウェアに入れ替えて使用していることを失念していました。

実はわりと直ぐに思い出したんですが、ソースの確認が面倒でそのまま放置していました。



私は自作ハード版と合わせ、USB接続赤外線リモコンを2機、数年間常用しています。
でも、そのどちらも、純正ファームウェアのソースを元に、(送信のみ可能な)USBシリアル(インターフェース)版に改造したファームウェアに入れ替えて使用しています。
(加えて、さらにそれを元にリアル・シリアル版を2機作成し、1機常用しています)

そのシリアル版ファームウェアでは、フラグ変数を、受信が完全に終了した後に書き換えることで、
中途半端な送信がおこなわれないようにしています。

ということで、私も“その時(シリアル版作成中)は”、ryahpさんご指摘のオリジナルの純正ソースの問題(バグ)に気づいていた筈です。
でも作業が飛び飛びだったり、無責任だったり、前述の理由で自分自身は回避できていたこともあり、純正ファームのバグのことは忘れていました。

ryahpさん、ありがとうございました。

遅くなりましたが、RemoconServant-Firmware-216-set_v3改め、RemoconServant-Firmware-216-set_v4を出そうと思っています。
イイね!の数:0
返信する

このトピックに投稿する

題名
投稿本文