リモートコントロール .bin 作成方法③ - プロトコル作成編 | Slingbox Fan

リモートコントロール .bin 作成方法③ - プロトコル作成編

Filed under リモコン用.bin

準備編で準備したProtocol-Builder v4.00を使って新しくプロトコルを作成します。赤外線データ学習編でリモコンから学習したデータのプロトコルが”Gap…”と表示されていた場合こちらの作業が必要です。もし”Gap…”と表示されていなく、プロトコルの名前が表示されているのであれば、ボタン割り当て編へ進んでください。プロトコル作成は、ややこしいように思えますが、一回やってしまえば、後は簡単です。そして、最大の強みは、どうしても分からなければJP1フォーラムで質問すればいいのです。きっと誰かが助けてくれるばず。

はじめに断っておきますが、赤外線のタイミングデータは寸分の狂いもなく正確でなくては動かない、というものではありません。”大体”、で十分認識してくれるのです。(下記不明確な記述もありますが、”大体”ということで。もし、赤外線データのスペシャリストがいたら是非とも間違いを指摘して下さい!また、スペシャリストからのコメントもお待ちしております!)

学習したいリモコン(例として、I-O DATA HVT-T100を使用)の数字ボタン1~9まで学習し、今回はそのデータを解析します。

1) IR.exeの”Learned Signals”にある学習した赤外線のタイミングデータをテキストに貼り付けていく

学習したタイミングデータ

一つずつ貼り付けていく

学習した数字ボタン1~9までのデータをテキストに貼り付けた状態

2) 次にタイミングデータの以下の四つのタイプのペアを探す

I.   リードイン(Lead-in)
II.   0
III.  1
IV.  リードアウト(Lead-out)

タイミングデータは、”ON”はプラス、そして”OFF”はマイナスで示される。まず、始めのペア”+9062 -4530″がリードインとなる。そして、通常“1″のペアは”0″のペアよりもタイミングが長くなると思われるので、数字ボタン1を例にとると:

数字ボタン1
+9062 -4530 +582 -552 +582 -552 +582 -552 +582 -552 +582 -552 +582 -552 +582 -552 +582 -1690 +582 -552 +582 -552 +582 -552 +582 -1690 +582 -552 +582 -1690 +582 -1690 +582 -1690 +582 -552 +582 -1690 +582 -552 +582 -552 +582 -1690 +582 -552 +582 -552 +582 -552 +582 -552 +582 -552 +582 -1690 +582 -552 +582 -1690 +582 -552 +582 -552 +582 -552 +582 -552 +582 -552 +582 -552 +582 -552 +582 -552 +582 -552 +582 -1690 +582 -552 +582 -37910

+9062 -4530 —-  リードイン
+582 -552   —–  0
+582 -1690  —–  1

と推測される。(”0″と”1″が逆の場合もあります)

そして最後に、リードアウトだが、これは通常シグナル全体の長さとなる。下記の通り、1~9の全ての数字ボタンは、合計が”108824″となっている。なので、この例では、リードタイムを”108824″とする。

タイミングデータをエクセルで計算

ここまでをまとめると、

リードイン    +9062 -4530
0                  +582 -552
1                  +582 -1690
リードアウト  108824

3) そして次に、”+582 -552″そして”+582 -1690″を、それぞれ”0″と”1″へ変換する

下図は数字ボタン1のタイミングデータを例に取り、+582 -552を”0″へ置換

数字ボタン1のタイミングデータ+582 -1690を”1″へ置換

置換後

バイナリデータは、通常”8ビット”で区分されているため、下記のように区分する。

これを数字ボタン1~9まで全て行うと下記の通り区分できる。

ボタン1 +9062-4530 00000001 00010111 01001000 00101000 00000010 +582-37910
ボタン2 +9062-4530 00000001 00010111 01001000 00100100 00001110 +582-35634
ボタン3 +9062-4530 00000001 00010111 01001000 00101100 00000110 +582-35634
ボタン4 +9062-4530 00000001 00010111 01001000 00100010 00001000 +582-37910
ボタン5 +9062-4530 00000001 00010111 01001000 00101010 00000000 +582-37910
ボタン6 +9062-4530 00000001 00010111 01001000 00100110 00001100 +582-35634
ボタン7 +9062-4530 00000001 00010111 01001000 00101110 00000100 +582-35634
ボタン8 +9062-4530 00000001 00010111 01001000 00100001 00001011 +582-35634
ボタン9 +9062-4530 00000001 00010111 01001000 00101001 00000011 +582-35634

0と1に変換した数字ボタン1~9のデータ部分は上記の通り40ビットで構成されており、上位3オクテットは数字ボタン1~9まで同様であることから、”device code”であることが推測される。そして、その下の2オクテットは、”command code”であると思われる。(このデータは後で使います)

数字ボタン1では、
00000001 00010111 01001000 —– device code
00101000 00000010 —– command code
となる。

4) Protocol Builderを開き、上記の情報を元にプロトコルを作成する

まず、Protocol Builderの左の上から説明していくと、

I. Remote Type

RemoteChart.xlsで確認する。
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2981

例:
URC-8910  —–  S3C8+
URC-10820 —– HCS08

II. Protocol Id
hex でIDを0~1FFの間で選択。
使用されていないIDを選択すること。分からなければ”1FF”とする。

III. Frequency
IR.exeで”Learned Signals”タブの下に表示されていた”Frequency”を記入。

IV. Duty Cycle
詳細不明。30~33%で設定する。

V. Signal Structure
手順 3)で0と1に変換した結果のdeive codeとcommnad codeの順序を選択。
解析したデータでは、deive code、commnad codeの順序だったため、”dev-cmd”を選択。

VI. [Device]Bytes
解析した例では、上位3バイトがdevice codeとしてfixしていたので、”3″とする。

VII. Bits/Dev
それぞれのfixされたバイト(device code)は、何ビットで構成させているか記入する。解析したデータの例では、それぞれが8ビットで構成されいるので、”8″。

VIII. [Command]Bytes
commnad codeの長さを指定。解析したデータの例では、2バイトだったので、”2″とする。

IX. Bits/Cmd
command codeは、それぞれ何ビットで構成されているか記入。解析したデータの例では、”8″。

X. [Repeat]Value
シグナルが何回繰り返されるかを指定。解析したデータの例では、リピートされていなかったので、”1″とする。例えば、2回リピートされている場合は、リモコンで数字1のボタンを一度押すと、リードインからリードアウトまでのシグナリングが二回送信される。

XI. Type
詳細不明。”force”とする。

XII. Hold
Yes — リモコンのボタンを押し続けている限り、シグナル全体が何度も送信される。
No  — リモコンのボタンを押し続けていても、シグナルはリピートされない。
Ch+/-, Vol+/-, FF, Rew — 左のボタンのみリピートされる。
No data bits in repeat — 不明

XIII. ['1'Burst]ON(uSec)
タイミングデータ”1″の”ON”を指定。解析したデータでは、”1″のペアは”+582 -1690″だったので、これの”ON”、即ち”582″を指定する。

XIV. OFF(uSec)
タイミングデータ”1″の”OFF”を指定。解析したデータでは、”1″のペアは”+582 -1690″だったので、これの”OFF”、即ち”1690″を指定。(しかし、実際には”1″と”0″が逆だったようなので、この数値を後で”552″へ変更した)

XV. ['0'Burst]ON(uSec)
タイミングデータ”0″の”ON”を指定。解析したデータでは、”1″のペアは”+582 -552″だったので、これの”ON”、即ち”582″を指定。

XVI. OFF(uSec)
タイミングデータ”0″の”OFF”を指定。解析したデータでは、”1″のペアは”+582 -552″だったので、これの”OFF”、即ち”552″を指定。(しかし、実際には”1″と”0″が逆だったようなので、この数値を後で”1690″へ変更した)

XVII. [Lead-In Style]
解析したデータでは、リードイン(+9062 -4530)が存在し、さらにリードイン、リードアウトを含む全てのデータがリピートされるようなので、”Same Every Frame”を選択。

XVIII. [Lead-Out Style]
[-LO] — OFF Timeのみ
[LI,-LO] — リードインのON Timeを使用
[OneOn,-LO] — “1″ペアのON Timeを使用
[LI],[OneOn,-LO] — リードインがリピートされ、[OneOn,-LO]がそれに続く

解析したデータでは、リードアウトのタイミングデータは、”+582 -35634″で
“582″が”1″のONと同様なので、[OneOn,-LO]となる。

XIX. [Lead-Out]OFF(uSec)
リードオフタイムを記入。シグナル全体の長さとなる。解析したデータの例では、”108824″を記入。

XX. OFF as Total
NO — 上記に記入したOFFタイム(この場合、108824)が全てのシグナリングに使われる
Yes — データ部分のシグナリング長が上記に記入したタイム(この場合、108824)から引かれ、実際のリードアウトタイムが計算される。
解析したデータの例では、数字ボタン1~9まですべて合計が”108824″で、さらにリードアウトのタイミングデータが数字ボタン毎に異なるので、”Yes”を選択。

注意点:
“0″ペアと”1″ペアの決まりは明確には無いようです。動かなかったら逆にしてみて下さい。上記の解析したデータでは、”1″のペアは”+582 -1690″、”0″のペアは、”+582 -552″としましたが、動かなかったので、逆にしたら動きました。しかし、このプロトコル作成の時点では分かりませんので、次のボタン割り当て編にて.binを作成後、実際にSlingboxへアップし、確かめてみる必要があります。

全てのデータの記入が終わったら、右上の”Upgrade Protocol . . .” で始まる Protocol Code をコピーして、テキストに貼り付け、保存して置きましょう。

Protocol Builderで作成したデータ:

Upgrade protocol 0 = 01 FF (S3C8+) PB v4.00
44 8C 32 8B 12 CF 45 08 08 01 23 01 00 01 23 03
39 D4 8C 11 B3 08 C5 E6 0D 01 8D 01 46
End

ここまで出来たらもうすぐです!

作成してプロトコルをProtocol Builderのdecodeに貼り付けて、decodeをクリックすると設定内容が分かります。

References:
「Protocol-Builder」
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=3727

JP1フォーラムの方々に感謝します!

(この記事は今後もっと分かり易くなるよう修正していきます)


Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*