IRTrans Hex code format

[touchsquid]

I am working on a code capture app for Android. Our device database uses Pronto Hex codes. I can send to the irTrans device using send CCF and it works well.

This will do for our remote control app, as it only needs to send codes.

On the capture side, I have written code to capture IR signals via TCP/IP, and that works. However for the captured code is in IRTrans hex format which is not documented. Unless I can translate the captured code to Pronto it can not be added to our database and used in our TouchSquid tablet, or with other external blasters.

I have been able to translate code captured with Global Cache and Keene devices, because the formats are documented.

Is it possible for a developer to obtain access to the documentation for this format? I have spent some time trying to decipher it but it has not been successful.

Without this information we will support IRTrans for send only.

[IRTrans]

Hi,
the problem with Pronto Hex Codes is, that a lot of features we do support cannot be defined using CCF Hex Codes.Those are especially Toggle Bits that are used by RC5, RC6, RCMM and some more code formats. Furthermore not all IR Repeating we can do can be done in Pronto CCF. And last but not least Pronto CCF Codes have a limited length whereas we can support up to 420 Pulse/Pause Pairs.

Please note that you loose quite some functionality of the IRTrans, especially when learning RC5/RC6 IR Codes if you convert the codes into the Pronto CCF Format.

In general our Hex Codes are the based on the IRDATA Struct defined in the "remote.h" header file in the irserver sourcecode:

#define TIME_LEN 8

typedef struct {
byte len; // 0
byte checksumme; // 1
byte command; // 2

byte address; // 3
word target_mask; // 4

byte ir_length; // 6
byte transmit_freq; // 7
byte mode; // 8

int16_t pause_len[TIME_LEN]; // 9
int16_t pulse_len[TIME_LEN]; // 25
byte time_cnt; // 41
byte ir_repeat; // 42
byte repeat_pause; // 43

byte data[CODE_LEN]; // 44
} IRDATA;

Most IR Codes are defined in the standard format, however there is also an extended format with 18 Pulse/Pause Pairs.

There is also a description of the Code format in the IRTrans Users Manual.

Please let us know if you have any further questions regarding the format.

IRTrans

[touchsquid]

Our product can handle toggle codes by capturing each version separately, and alternating them. the only devices we have found that seem to require toggle codes are the xBox360 and Microsoft MCE.

Here is a sample Pronto code (Sharp TV power ON/OFF)
0000 006d 0000 0020 000a 0046 000a 001e 000a 001e 000a 001e 000a 001e 000a
001e 000a 0046 000a 0046 000a 001e 000a 0046 000a 001e 000a 001e 000a 001e
000a 0046 000a 001e 000a 0679 000a 0046 000a 001e 000a 001e 000a 001e 000a
001e 000a 0046 000a 001e 000a 001e 000a 0046 000a 001e 000a 0046 000a 0046
000a 0046 000a 001e 000a 0046 000a 0679

This is what we captured:**00271 LEARN

80011000000542600006200E5159815B1169D16B00000000525456586066466687072747678808284868890929496
0020001F001F0020001F00200000000006828704030430313030303030313130313030303130343130303030313030313031
3131303132313030303030313130313030303130353130303030313030313031313130313331303030303031313031303030313030

Hwere is what I have deciphered, I think. Offsets in decimal
Offset 00: Count of bytes
Offset 02 - 010: ??
Offset 12: Number of Burst pairs
Offset 14: Carrier frequency
Offset 16: ??
Offset 18 - 82: Timing data. 8 words of on times followed by 8 words of off times

Offset 84: RC - number of repeats
Offset 86: RP - Pause between two repeats in ms.

Data at end. I'm sure that each pair refers to a pulse/pause timing pair but I'm not sure how they are referenced.

Can you help me to decipher waht is there?

Thanks!

[IRTrans]

Hi,
I know that GC uses this approach to learn codes with toggle bits, however that is very time consuming and error prone especially for a larger remote control.

I can tell you that there are many, many more devices using these codes. RC5 and RC6 are very common. The RCMM codes that also use toggle bits are very common, too - especially for STBs. The AT&T Cable Boxes in the US for example use RCMM with a toggle bit. Therefore I would really recommend to also store such codes in our format.

Please note that you will need to switch off RCMM, RC5 and RC6 detection in our devices if you want to learn toggle bits manually. Otherwise our device will filter out the toggle bits internally.

Regarding your question:

Offset 00: Count of bytes
Correct

Offset 02: Checksum
Not needed

Offset 04: IR Command
Not needed

Offset 06: Address
Not needed

Offset 08: Address mask (Word)
Not needed

Offset 12: Number of Burst pairs
Correct

Offset 14: Carrier frequency
Correct

Offset 16: Mode Flags
Flags to select special modes (See below for details)

Offset 18 - 82:
Timing data. 8 words of on times followed by 8 words of off times

Offset 84:
RC - number of repeats
Correct - If Bit 7 (128) is set then Repeat Pause is Framelength and not pause

Offset 86: RP - Pause between two repeats in ms.
Or Framelength when Bit 7 of RC is set

Offset 88: IR Data as an ASCII String referencing the timings above

0 = First Pulse/Pause Pair 1 = 2nd and so on

If Mode Bit "Start Bit" (= 1) is set then:
S = First Pulse/Pause Pair (Startbit) 0 = 2nd, 1 = 3rd and so on


Mode Bits:

START_BIT 1
See above

REPEAT_START 2
Start bit is repeated

RC5_DATA 4
RC5 Code (No timing Info provided, Manchester Code generated by the IRTrans)

RC6_DATA 8
RC6 Code (No timing Info provided, Manchester Code generated by the IRTrans)


In addition there are many, many more options. We can also code additional Repeat info (Repeat Start, Repeat Sequence, Repeat Trailer) in the beginning of the Data sequence. However, it will not make sense to decode those codes because it will not possible to encode those code in CCF anyways.

Maybe you should really rethink having more than one IR Format in your Database. Otherwise you will loose a lot of functionallity we readily provide with our superior learning capability.

IRTrans

PS: If you like we can discuss further ideas via Email or Phone.

[touchsquid]

I think this info will be sufficient.

We have a very large database of codes and the need for learned codes is actually quite rare. Our database does contain many RC5 and RC6 codes as well as CCF codes.

Toggle bits are indeed common, but we have found that most devices do not seem to "pay attention" to them. You can send the same code a second time and the device will still respond.

The xBox360 and MCE are exceptions, they will ignore the same code when it is sent a second time--it must toggle. We have a mechanism for this which works well.

The problem with storing codes in your format(which I admit is excellent) is this:
Our tablets have built in IR capabilities, and the sending API uses CCF format. So even if we stored your code in our database, we would have to translate it to CCF for sending to any device other than the IRTrans. Mixed systems are common, where the TV is visible, and controlled by direct IR, and the other devices are hidden in a cabinet and controlled with IRTrans or another blaster.

We could store your codes "as is" but then they could only be used with the IRTrans device.

Anyway, thank you very much for the detailed and informative discussion!

[IRTrans]

Hi,
at least RC5 and RC6 codes are also supported in a special form of the Pronto Hex Format. Our devices do support those special codes and will regenerate the toggle bits correctly then. However, I do not think that anybody else (apart from Philips of course) does support the more complex CCF codes.

IRTrans

[touchsquid]

This is proving more difficult than I expected. My translated codes look quite different from the originals.

Before going into detailed analysis I decided to make sure the correct code is being captured.

Here is the captured code:
800110000000542600006200E5159915B1169D16B5007900000020001F001F0020001F002000090000068287040304303130303030303131303130303031303431303030303130303130313131303132313030303030313130313030303130353130303030313030313031313130313331303030303031313031303030313030

I send it back out on UDP port 2100 with the following string:
"sndhex 800110000000542600006200E5159915B1169D16B5007900000020001F001F0020001F002000090000068287040304303130303030303131303130303031303431303030303130303130313131303132313030303030313130313030303130353130303030313030313031313130313331303030303031313031303030313030,lb,ps"

The LEDs do not flash, and the result returned back is:
ERROR:ASCII Format Error

This string, using sndccf returns OK and works:
sndccf 0000 006d 0000 0060 000a 0046 000a 001e 000a 001e 000a 001e 000a 001e 000a 001e 000a 0046 000a 0046 000a 001e 000a 0046 000a 001e 000a 001e 000a 001e 000a 0046 000a 001e 000a 0679 000a 0046 000a 001e 000a 001e 000a 001e 000a 001e 000a 0046 000a 001e 000a 001e 000a 0046 000a 001e 000a 0046 000a 0046 000a 0046 000a 001e 000a 0046 000a 0679 000a 0046 000a 001e 000a 001e 000a 001e 000a 001e 000a 001e 000a 0046 000a 0046 000a 001e 000a 0046 000a 001e 000a 001e 000a 001e 000a 0046 000a 001e 000a 0679 000a 0046 000a 001e 000a 001e 000a 001e 000a 001e 000a 0046 000a 001e 000a 001e 000a 0046 000a 001e 000a 0046 000a 0046 000a 0046 000a 001e 000a 0046 000a 0679 000a 0046 000a 001e 000a 001e 000a 001e 000a 001e 000a 001e 000a 0046 000a 0046 000a 001e 000a 0046 000a 001e 000a 001e 000a 001e 000a 0046 000a 001e 000a 0679 000a 0046 000a 001e 000a 001e 000a 001e 000a 001e 000a 0046 000a 001e 000a 001e 000a 0046 000a 001e 000a 0046 000a 0046 000a 0046 000a 001e 000a 0046 000a 0679,lb,ps

Is there a different syntax for the ending of the sndhex command? Or perhaps there is something else wrong?

[touchsquid]

I also tried sending by TCPIP:

Asndhex 800110000000542600006200E5159815B1169C16B600000000001F00200020001F0020001F00000000068287040304303130303030303131303130303031303431303030303130303130313131303132313030303030313130313030303130353130303030313030313031313130313331303030303031313031303030313030,LI

This resulted in:
**00034 RESULT ASCII Format Error
I have no idea what is wrong with the format. There is a carriage return chr(13) on the end and it was sent with ASCII encoding.

[IRTrans]

Hi,
please recheck the syntax of the "sndhex" command (page 8 of the IRTrans TCP manual): The Hexcode has to be preceded by an "H":

sndhex H800110000000542600006200E5159915B1169D16B5007900000020001F001F0020001F002000090000068287040304303130303030303131303130303031303431303030303130303130313131303132313030303030313130313030303130353130303030313030313031313130313331303030303031313031303030313030,lb,ps"



IRTrans

[touchsquid]

The missing H solves the issue of sending the code by UDP, it works now. Responds with OK. The TV switches on.

When sending by TCPIP, it works once, but on the second attempt Android returns a exception from the outputstream. I don't need to so this, UDP works fine, but TCPIP acts as if the IRTrans has dropped the connection. Is there a timeout?

Now that I'm convinced the Hex string contains the correct IRcode (it controls the TV) I will work on the translation again.