Lirc codes from Pronto Hex

[mlinuxboy]

Hello All,

I am trying to go from the Pronto hex found in this thread to a lirc profile for my zaurus.

I really don't see a good place to start.

Any help would be greatly appreciated.

Thanks,
Matt

[johnsfine]

That code set is quite consistent across a wide range of models. There are four lirc files already posted for it.

http://lirc.sourceforge.net/remotes/mitsubishi/DIVA29
http://lirc.sourceforge.net/remotes/mitsubishi/CT21AM2(A)
http://lirc.sourceforge.net/remotes/mitsubishi/CS-2047R
http://lirc.sourceforge.net/remotes/mitsubishi/CD-2015C

You will notice that two of those LIRC files specify 7 bits and the other two specify 8 bits. The 7 bit version can't support OBC numbers over 127 and it is trickier to add functions to (by converting from OBC number). But one of the 7 bit ones is the file with the most functions listed, so it might be the best choice despite those problems.

In any case you have a difficult (for a beginner) translation from Pronto Hex to the LIRC form.

If you really want to start with Pronto Hex (rather than the other forms of the same data in that thread), you need the IrTool program and decodeir.dll to get the OBC number from each Pronto Hex string.

For example "EXT 1" is listed there with the Pronto Hex:
0000 0074 0000 0011 000A 004E 000A 004E 000A 004E 000A 0022 000A 0022 000A 0022 000A 004E 000A 0022 000A 0022 000A 0022 000A 0022 000A 0022 000A 0022 000A 0022 000A 0022 000A 004E 000A 03DB

IRTool decodes that as "Mitsubishi:71:128"

The 128 is the OBC number.

The 8 bit LIRC files require the OBC number converted to hex using LSB conversion. The easiest place to get that conversion is the EFC calculator from the tools menu of IR.exe:

Type the OBC number (128) into the LSB field of the calculator and read the hex value (01). Then put that hex value in as the last two digits of a code in the LIRC file.

If you needed to work with one of those 7 bit LIRC files, you can only use OBC numbers 0 to 127 and you need to double the OBC number before typing it into the LSB field.

If you want the reverse translation (get the OBC number from one of the 7 bit LIRC files): type the two digit LIRC hex number into the "HEX Command" field in the EFC calculator, then read the number from the LSB field and cut that number in half to get the correct OBC number.

[mlinuxboy]

Excellent! With luck this will get me started.

But... How do I see that the device protocol is the same as another from the hex or any other data?

For example, is there a way to tell what the pre-data is from the material there? Is there some method to decode that?

I will further poke around. Thanks for the info.

Thanks again,
Matt

[johnsfine]

If you type the device number (71) into the LSB field of the EFC calculator, you will see E2 in the hex field.

The way all these LIRC files are configured that E2 is the pre-data.

But that is specific to these LIRC files. It is possible to have an LIRC file for Mitsubishi protocol that doesn't do it that way. And for protocols other than Mitsubishi the variety of rules is even greater.

For deducing the protocol itself, things get much trickier:

The bit timing is approximate everywhere. In one lirc file I see

Code: Select all

  one           300  1950
  zero          300   880

In another I see

Code: Select all

  one           564  1878
  zero          564   662

You need a fair amount of experience to know that apparently large difference is insignificant and both versions are consistent with the
values documented in the IRP notation for Mitsubishi at
http://john.fine.home.comcast.net/ir/De ... Mitsubishi
In that the 300 .. 1,-3 .. 1,-7 is equal to lirc

Code: Select all

  one           300  2100
  zero          300   900

Then the number of bits is fun. In one LIRC file we see

Code: Select all

  bits            7
  pre_data_bits   8
  post_data_bits  2

In the other we see

Code: Select all

  bits            8
  pre_data_bits   8
  ptrail        549

You need a good understanding of IR to realize that both of those (and that IRP I linked) mean that there are 16 data bits followed by a trailer that is equivalent in timing (but not in meaning) to one more bit.

Even I don't have the skill+patience required to look at LIRC data like that and deduce that it is Mitsubishi protocol, not Bose or G.I.Cable or DishNetwork or JVC, all of which are easy to confuse with Mitsubishi when looking at a crude approximation of the signal.

Instead, I have the experience to know that Mitsubishi:71 is such a common Mitsubishi code set that there must be several LIRC files for it, and I know that the device and OBC are encode LSB. So I just needed to see whether the LIRC file defines "one" as the long bit and "zero" as the short bit (the way DecodeIR does) requiring LSB translation, or the LIRC file could have defined "one" as the shorter bit requiring LSB-comp translation. Then I could easily compute the pre-data would be E2 and quickly glance at each Mitsubishi LIRC file to find the ones with predata E2.

[mlinuxboy]

I am humbled and in awe.

Whilst I consider myself an electronics guru, clearly there are many protocols I have not seen.

I bow to your supremeness.

Many, many thanks,
Matt

[The Robman]

Stick around, this kinda stuff becomes second nature to the JP1 experts and it will probably for you too.