|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
bwade_913
Joined: 18 Jan 2004 Posts: 20 Location: Boulder, CO |
Posted: Mon Jun 07, 2004 1:14 am Post subject: Qtronix keyboard revisited |
|
|
Hi protocol experts,
I've been experimenting with JP1 to control a Linux MythTV PVR by sending IR keyboard commands. I've had success with a Liteon keyboard using the Airboard upgrade. I should be happy with that, but I have a Qtronix keyboard that I like much better and I would love to get that working instead.
If I understand the process, if someone can decypher the protocol for me, I should have no trouble using IR to translate leaned signals and creating an upgrade file. If anyone's willing to do the protocol work, I'll commit to doing the rest of the work to the best of my ability.
I've uploaded qtronix_kb.txt to the yahoo diagnosis folder. It was captured with a 15-2117. The learned signals are 0-9, up, down, right and left trackball movements and the two mouse buttons. All of these learned signals work from the remote. FWIW, the track ball appears to use the same protocol as the key strokes which would make this keyboard more versatile than the Liteon.
Thanks,
Bret (who has little idea just how much work I'm asking for) |
|
Back to top |
|
|
bwade_913
Joined: 18 Jan 2004 Posts: 20 Location: Boulder, CO |
Posted: Mon Jun 07, 2004 10:35 am Post subject: Re: Qtronix keyboard revisited |
|
|
bwade_913 wrote: | Hi protocol experts,
I've been experimenting with JP1 to control a Linux MythTV PVR by sending IR keyboard commands. I've had success with a Liteon keyboard using the Airboard upgrade. I should be happy with that, but I have a Qtronix keyboard that I like much better and I would love to get that working instead.
If I understand the process, if someone can decypher the protocol for me, I should have no trouble using IR to translate leaned signals and creating an upgrade file. If anyone's willing to do the protocol work, I'll commit to doing the rest of the work to the best of my ability.
I've uploaded qtronix_kb.txt to the yahoo diagnosis folder. It was captured with a 15-2117. The learned signals are 0-9, up, down, right and left trackball movements and the two mouse buttons. All of these learned signals work from the remote. FWIW, the track ball appears to use the same protocol as the key strokes which would make this keyboard more versatile than the Liteon.
Thanks,
Bret (who has little idea just how much work I'm asking for) |
Here is a link to the IR file with the learned keyboard signals:
http://groups.yahoo.com/group/jp1/files/Diagnosis%20Area/qtronix_kb.txt
Thanks,
Bret |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Mon Jun 07, 2004 11:28 am Post subject: |
|
|
Like most keyboard protocols it looks like the whole signal is too long to be correctly learned by the UEI remotes.
The basic "frame" within the signal is short enough to learn and the samples in your file make its basic structure clear.
There is a lead-in (roughly +2010,-1030) followed by 40 bits of data. In the data a '0' is +260,-280 and a '1' is +260,-780.
If you squeeze the columns in IR you can read the Misc column, which contains the 5 bytes (40 bits) of data decoded for each frame.
I don't yet understand what the individual bits within the 40 mean, nor the rules for building the whole signal from multiple frames.
For most keyboards, the multi-frame level rules depend on how long the key is held and most interesting examples are too much data for the remote to learn. You can usually guess at much of those rules by learning the same key with a few different durations (as quick press and release as possible, fairly quick press and release, and press and hold till the learning is done).
Even if you fail to detect the true rules, the receiver logic is likely to be tollerant of errors at that level, so you can make the remote reproduce just part of the true signal and that may be enough. |
|
Back to top |
|
|
bwade_913
Joined: 18 Jan 2004 Posts: 20 Location: Boulder, CO |
Posted: Wed Jun 09, 2004 6:25 pm Post subject: |
|
|
johnsfine wrote: | Like most keyboard protocols it looks like the whole signal is too long to be correctly learned by the UEI remotes.
The basic "frame" within the signal is short enough to learn and the samples in your file make its basic structure clear.
There is a lead-in (roughly +2010,-1030) followed by 40 bits of data. In the data a '0' is +260,-280 and a '1' is +260,-780.
If you squeeze the columns in IR you can read the Misc column, which contains the 5 bytes (40 bits) of data decoded for each frame.
I don't yet understand what the individual bits within the 40 mean, nor the rules for building the whole signal from multiple frames.
For most keyboards, the multi-frame level rules depend on how long the key is held and most interesting examples are too much data for the remote to learn. You can usually guess at much of those rules by learning the same key with a few different durations (as quick press and release as possible, fairly quick press and release, and press and hold till the learning is done).
Even if you fail to detect the true rules, the receiver logic is likely to be tollerant of errors at that level, so you can make the remote reproduce just part of the true signal and that may be enough. |
Thanks for looking at this John. Do you need to reverse engineer the data bits to create a protocol or does the protocol just need to define how to insert the data in the complete signal?
Are there any links with instructions for building protocols? I'm not that clever but I am persistent and can usually find way.
Bret |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Wed Jun 09, 2004 8:13 pm Post subject: |
|
|
I don't know when I'll have time for a more serious look.
You don't absolutely need to reverse engineer the data bits to create a protocol. But it's much better if you do.
This protocol has 5 bytes of data. With no reverse engineering you'd need an upgrade with no fixed data and 5 bytes of hex cmd. That would make a really big device upgrade.
By reverse engineering the data bits, you can reduce the hex cmd size, either using fixed data instead of hex cmd, or computing redundant parts dynamically (so they take neither fixed data nor hex cmd).
In simple cases, you can use the Protocol Builder spreadsheet to create a protocol executor. That would be easy for single frames of this signal using 5 byte hex commands. But it may be much harder for a smarter executor using less than 5 bytes (since the 40 bits don't seem to split fixed/variable/redundant in one of the simpler patterns). It would be harder still if the muilt-frame level of the signal is actually mandatory (especially since you haven't caputered the extra samples needed to start guessing that).
If you make a single-frame 5-byte version in PB, I'm not sure if KM can handle that. RM can (by writing a new entry in protocols.ini) but that's yet another thing to learn.
I forget when Jon is expected back. He usually does the heavy lifting in this situation. |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Thu Jun 10, 2004 5:14 pm Post subject: |
|
|
I got back last night. The following are the four bytes of data in this data structure of 40 bits, MSB first:
0:4,Byte1:8,Byte2:8,Byte3:8,Byte4:8,0:4
There were consistently 42 burst pairs in two frames with different data, the numbers seem to line up but maybe I'm not seeing any other relationhip. I have gotten a 5 varaible byte protocol to work using KM and I assume that the 2116/7 will handle it. I can certainly do that using PB. I assume frame 1 is the "press down" and frame 2 the "release" of the keys.
Code: |
02 00 20 00 01 00 2F 00 1
03 00 30 00 02 00 3F 00 2
04 00 40 00 03 00 4F 00 3
05 00 50 00 04 00 5F 00 4
06 00 60 00 05 00 6F 00 5
07 00 70 00 06 00 7F 00 6
08 00 80 00 07 00 8F 00 7
09 00 90 00 08 00 9F 00 8
0A 00 A0 00 09 00 AF 00 9
0B 00 B0 00 0A 00 BF 00 0
8C 30 10 00 8F 50 20 00 Right
87 E1 0F 00 88 E3 FF 0F Left
89 02 F0 0F 89 02 F0 0F Down
88 F1 0F 00 89 00 10 00 Up
99 00 00 00 99 00 00 00 REW
AA 00 00 00 AA 00 00 00 FFWD
|
_________________ -Jon |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|