This was originally posted in the custom installers lounge but I have posted to this forum.

[Link: remotecentral.com]

Once you find discrete codes like the ones posted below how do you recognize whether or not it is an acceptable format for say Pronto hex that will allow you to copy and paste into the software editor? If the codes do need to be changed to another format how do you go about doing so? TIA




Function Code Number D20..................D0 D15 D14..D12 D11..D8 D7…D0
Power On 0 1 1100 1000 0000 0001 0001 x 000 0010 00000000
Power Off 1 1 1100 1000 0000 0001 0001 x 000 0010 00000001
Ant (or Source tuner 1) 10 1 1100 1000 0000 0001 0001 x 000 0010 00001010
AV1 13 1 1100 1000 0000 0001 0001 x 000 0010 00001101
AV2 14 1 1100 1000 0000 0001 0001 x 000 0010 00001110
AV3 15 1 1100 1000 0000 0001 0001 x 000 0010 00001111
SV1 16 1 1100 1000 0000 0001 0001 x 000 0010 00010000
SV2 17 1 1100 1000 0000 0001 0001 x 000 0010 00010001
YPbPr 1 19 1 1100 1000 0000 0001 0001 x 000 0010 00010011
YPbPr 2 20 1 1100 1000 0000 0001 0001 x 000 0010 00010100
HDMI 1 21 1 1100 1000 0000 0001 0001 x 000 0010 00010101
HDMI 2 22 1 1100 1000 0000 0001 0001 x 000 0010 00010110
Mute On 25 1 1100 1000 0000 0001 0001 x 000 0010 00011001
Mute Off 26 1 1100 1000 0000 0001 0001 x 000 0010 00011010
Aspect 1 - Side Bar 35 1 1100 1000 0000 0001 0001 x 000 0010 00100011
Aspect 2 - Smart Stretch 36 1 1100 1000 0000 0001 0001 x 000 0010 00100100
Aspect 3 - Zoom 37 1 1100 1000 0000 0001 0001 x 000 0010 00100101
Aspect 4 - Stretch 38 1 1100 1000 0000 0001 0001 x 000 0010 00100110
Aspect 5 39 1 1100 1000 0000 0001 0001 x 000 0010 00100111

Pronto Codes are relatively recognizable. Look at a few that you have learned and you will begin to see. These are not formatted for Pronto but rather raw data information.

Is this information from a chart? Can you mail the exact chart to my email on my profile?

One way to begin figuring out the puzzle without having to be an IR expert is to learn a code or codes from the native remote, paste it into IRTool Modified located here... [Link: remotecentral.com] to find the protocol, device number and function number of the command. Use this information to generate a complete list of possible code by using MakeHex found here... [Link: remotecentral.com]
To do this you open the .irp file that corresponds to the desired protocol and edit the device number. Once done, drag it onto the Makehex icon to generate your Pronto Codes. You can then use IR Panels found here... [Link: remotecentral.com] to generate a Pronto CCF file so that you can test all of the codes if you have a Pronto.

In regards to converting the raw info, you have to figure out how the manufacturer presents the data and discover what portion of the data makes up the protocol, device and function information. Use the codes generated with MakeHex to associate with the information from the raw data.

Someone else may have a simpler explanation but in my experience, once you get comfortable with the method(s) described above, it becomes fairly quick and easy.
If I had to do all of this AND build Pronto Hex codes manually from the raw data I would never finish my installations! It's hard enough as it is.

The data you posted above that looks like 1's and 0's is binary. The 'x' means don't care or that this is a toggle bit. This is just a stream of bits that really does not mean anything without more information about the expected timing or protocol.

As you probably already know, the above data is not in Pronto Hex format.

Pronto Hex will begin with a string such as 0000, 5000, 6000, 900A, or 9000 depending on the remote. The actual values that start a code are listed in the Classic Pronto or Pronto NG FAQs.

To convert, you'd need to decipher the codes and use a program like MakeHex to generate IR code data in Pronto Hex format unless the document containing /source of the code data includes information about the protocol.

However, after reading the document you linked (see bolded info above), I see that the device uses the RC6A protocol. There are already dialogs (conversion tools) in the Pronto Editors for entering such data to convert to obtain IR codes in Pronto Format as part of adding an IR code to a button.

For example, using either Pronto Edit 4 or Touch Screen Setup (for Marantz), you simply add an IR code to a button and then click 'Advanced'. There, you'd enter the Customer Code, System Code as listed in the document and then substitute the Function Code from the table for the function you desired.

From the PE/TSS RC6A window...

For the Customer Code, enter 32785
For the System Code, enter 2
For the Command, enter the Function code as listed in the table. (I believe 13 used in this example)

Which corresponds to the following Pronto Hex Data (RAW Format).
0000 0073 0000 0020 0070 0020 0010 0010 0010 0010 0010 0020 0010 0020 0030 0020 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0020 0020 0010 0010 0010 0010 0020 0020 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0020 0020 0010 0010 0010 0010 0010 0010 0010 0010 0020 0010 0010 0020 0020 09c0

Hope this helps

I haven't done much with direct entry of RC6A codes in ProntoEdit. Lyndel's instructions look plausible and I assume they are correct.

But the linked HP documentation only shows that one combination of Customer Code and System code, that fits the list of signals they call "Entertainment group 1". They have a second list of signals called "Entertainment group 2" without telling you a different Customer Code or System code.

If I'm reading the binary right and if I correctly understand what "System code" means in ProntoEdit, then the second list uses the same Customer Code as the first, but System Code 18 instead of 2.

My software (DecodeIR and MakeHex, etc.) call this protocol "MCE". If you want to generate ordinary Pronto Hex with MakeHex, use MCE.irp and set device=2.17 for "Entertainment group 1" and rerun with device=18.17 for "Entertainment group 2". In both cases the "Code Number" in the HP document is the function number in the MakeHex output.

The HP icon is a Hyperlink and will take you to the chart I pulled the data from. Thanks for the info.

Here is how I did find all discrete codes for LG LCD TV

I did use the learning capability on the Pronto to learn some codes.

It soon showed a pattern that all codes looked like this:
900A 006D 0000 0001 04FB 00FF Program+
900A 006D 0000 0001 04FB 01FE Program-
900A 006D 0000 0001 04FB 10EF 0

All codes startes with:
900A 006D 0000 0001 04FB

The last four digit = 00 to FF for the two first digit and FF to 00 for the two last, as a check sum.

This gives 255 possibility. I then tested all variation from:
00FF
01FE
to

FE01
FF00

This gave me all secrets on my LCD TV.

The list is posted here and should work with most LG LCD:
[Link: remotecentral.com]

Am I looking at this correctly???...

The information from the HP chart is presented in backwards binary.
The customer code (32785) is derived from D15-D0 in the third column.
The system code (2 or 18) is derived from D14-D8 in the 5th and 6th column.
The function code is derived from D7-D0 in the last column.

From where is the x.17 for the device number derived?

No. That documentation uses ordinary binary, not backwards. "Backwards" would mean the high order bits are shown on the right. But the high order bits are on the left in that doc.


The 'x' (2 or 18) in x.17 is the same bits as the system code.

The 17 in x.17 is the bottom byte of the customer code. The top byte of that is always 128 in MCE. 128*256 = 32768, so that top byte contributes 32768 of the customer code. 32768+17 = 32785 because the bottom byte is 17.

I guess I had this concept reversed.


Do other RC6 protocols use top bytes of 0, 64 and 192?

Most other RC6 protocols differ in a more fundamental way from these.

The two main factors distinguishing RC6 protocols from each other are:

1) The value of a three bit field named M.
2) The number of data bits.

In ordinary RC6, M is 0 and there are 16 data bits.

In the RC6 used by Sky and Sky+, M is 6 and there are 20 data bits.

In the RC6 used by Replay, M is 6 and there are 24 data bits.

In the RC6 used by MCE, M is 6 and there are 32 data bits and the first eight data bits are 10000000 (binary for 128 decimal).

I'm not certain of the definition of RC6-6A, but I think it includes both the Replay version of RC6 and the MCE version. All the samples of Replay I've seen have the first eight bits 00000000 or 00000001. I expect there is some rule relating the length to the first few bits when M is 6, so a truncated 32 bit signal wouldn't accidentally decode as 24 bits. But if so, the Sky signal is an exception and possible problem. A truncated Replay signal could look like a perfect Sky signal.

Thanks as always, John.

I appreciate the information.