Qtronix keyboard revisited

[bwade_913]

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)

[bwade_913]

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 ... nix_kb.txt

Thanks,
Bret

[johnsfine]

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.

[bwade_913]

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

[johnsfine]

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.

[jon_armstrong]

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: Select all

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