KM and RM hex values in DishNetwork Combo

[ElizabethD]

Using 6131ext, Dish Network Combo protocol (0002 in KM, 0002:5 in RM)
When OBCs are entered, and byte2 is 1, hex is not correct, and neither is EFC.
When byte 2 is zero, it's all ok.
Entry by EFC is ok.

Examples where byte2=1 in Dish721
page up OBC=015
page dn OBC=007
play OBC=003
swap OBC=061
Expected hex values are 3C,1C,0C,F4
Returned hex values are 3D,1D,0D,F5
just 1 tiny little bit off

[unclemiltie]

I can assure you that the 721 upgrade from RM works just fine with a 721. In fact, it works just fine with two of them (721's that is)

I'm using the 6131 extender and that very upgrade on both of the 721's in my house.

[mr_d_p_gumby]

Expected hex values are 3C,1C,0C,F4
Returned hex values are 3D,1D,0D,F5

The difference in your Expected and Returned values exists because this is a combo protocol executor. Valid OBC values are from 0 to 63, and use the upper six bits of the hex value. The lower 2 bits of the hex value are used to select one of the four Device Codes from the fixed data (using the Byte2 value in KM).

[ElizabethD]

I've seen the 6-2 split in Excel and understand how it works. The whole thing surprised me initially.
Would it be correct to say that with mini-combo you should not use OBC for entering learned values?

[The Robman]

I've seen the 6-2 split in Excel and understand how it works. The whole thing surprised me initially.
Would it be correct to say that with mini-combo you should not use OBC for entering learned values?

Actually, with the exception of the "Device Combiner" protocol which uses EFCs, it's always a good idea to just use OBCs with KM and RM. When we configure KM/RM to work with a protocol we have control over how the OBCs are configured, but we have no control over EFCs as that's in UEIs hands. When you look at a learned signal in IR.exe, the EFC info supplied is sometimes just a guess. With a mini-combo protocol like this, IR.exe will often display 3 or 4 possible EFCs, but it will always display just 1 OBC.

[mr_d_p_gumby]

I agree with Rob that using OBCs is generally the best method, especially in the case of mini-combos (such as the Dish Network Combo), or where you might be experimenting with more than one executor (like the various Sony Combos).

Using your Play OBC = 003 as an example with the Dish Network Combo, you could end up with one of four hex bytes depending on the desired device code: 0C, 0D, 0E or 0F. Those same codes will have have very different EFC values: 050, 042, 066 and 058. Which of those EFCs is correct depends upon where you choose to place the correct device code in the fixed data.

It gets even worse when you start working with two-byte combos and 5-digit EFCs.

[ElizabethD]

I'm not sure we're on the same page as far as HOW to use KM or RM.
Partial quote, where I expected to match Hex values for the remote to work:

Code: Select all

Learned data from DISH Platinum remote configured to address #1

BUTTON     Device Sub-device OBC HEX EFC
POWER      0      0            2  08 082
MENU       0      0           11  2C 051
TV/VIDEO   0      0           23  5C 176
PAGE UP    1      0           15  3C 179
PAGE DOWN  1      0            7  1C 178
PLAY       1      0            3  0C 050
SWAP       1      0           61  F4 109

Codes for other Dish addresses (2,3,4) were identical except for "Sub-device" values (1,2,3)

According to KM Protocol Help, IR learned Subdevice+1=Unit code. So I coded for Unit#1. I entered OBCs and didn't look back at EFC and hex. Hex was 3D for Page up. It didn't work. When we changed EFC from 171 to 179 it worked. Likewise for the others.

Also, when in EFC mode instead, EFC number is changed, b2/ov column fills and byte2 column goes blank - that one I don't understand at all. Perhaps one of you could take a peek at this file?
http://www.hifi-remote.com/forums/dload ... le_id=4089

Which of those EFCs is correct depends upon where you choose to place the correct device code in the fixed data

Do I have control over that? I see what happens on the first byte for unit1,2,3,4. But I just let the other 4 fixed bytes be done by KM, though I saw how it works. Am I supposed to change something?

[mr_d_p_gumby]

First of all, I think you are falling prey to a fundamental misunderstanding here. If you look closely at all the hex codes in your table you'll see that all of them have the lower 2 bits of the byte set to 0. That's because IR/DecodeIR.dll is not producing hex codes for a combo protocol executor. It simply filled in the upper six bits of the byte from the OBC, and has no idea what the two lower bits should be, so it left them set to zero. It then calculated the EFC values from those hex values.

The point here is that you should not be trying to match the hex values from IR in KM. IR does not know which version of the Dish Network executor you will be using. KM does know, and knows that the version in the URC-6131 is a combo protocol, and knows how to encode the lower 2 bits properly. All you have to do is enter the OBC, and select the correct device code by entering 0, 1, 2 or 3 in the byte2 column to select one of the four devices you entered on the Setup sheet.

Also, when in EFC mode instead, EFC number is changed, b2/ov column fills and byte2 column goes blank - that one I don't understand at all.

An EFC number completely defines all 8 bits of the hex code, so there is nothing for the byte2 column to do here. In OBC mode, the OBC only defines 6 of the 8 bits, and the byte2 column defines the remaining 2 bits.

According to KM Protocol Help, IR learned Subdevice+1=Unit code. So I coded for Unit#1.

Correct.

I entered OBCs and didn't look back at EFC and hex.

OK so far.

Hex was 3D for Page up.

This is as it should be, given that the Page Up function in your table indicates device 1. The lower 2 bits are 01, which points to Device#1 on the Setup sheet, which you set to be device code 1.

It didn't work.

Define what you mean by that. Do you mean it did not produce the hex code you expected, or do you mean that the device did not respond to the IR command?

When we changed EFC from 171 to 179 it worked. Likewise for the others

Again, I'm not sure what you mean here. If the functions did not operate the device correctly, then IR must be incorrect in indicating that these functions used device code 1. If you altered the functions to match the hex codes from IR, then all of them are using device code 0.

[ElizabethD]

While I read and learn the first part of your answer, let me throw some more data.
http://www.hifi-remote.com/forums/dload ... le_id=4092
The only thing I don't have is the actual IR file with learned signals (there was one bad decode to JVC-A there, no sweat). The learned data as well as my trying to understand Learned samples for units 1-4, is in xls. All decodes for unit 1 are there as well. I trust the transcriptions. My IR upgrade which didn't work on sub2=1 included in the zip file.

Do you mean it did not produce the hex code you expected, or do you mean that the device did not respond to the IR command?

According to the person I'm attempting to help:

Pressing SAT gives control of receiver with adress #1, and pressing PVR gives control of #2. I verified both by controlling my address 1 receiver and my address 2 receiver, as well as re-addressing my address 1 receiver to address 2.
...
None of the PIP keys work. Then I looked at the keymoves page in the IR file and saw you had put in page up and page down buttons as shift/ch+ and shift/ch-. So I tried 'em but they didn't work. I noticed you had used the wrong EFCs for these, so I changed your 171 and 170 to 179 and 178, and reloaded, then page up and down worked.

Does this change any of your answers?
Does this change how it should all be done for 2 units?

If you altered the functions to match the hex codes from IR, then all of them are using device code 0.

Oh boy. I'm getting deeper and deeper in trouble. So how would that square with the xls data? Because decoder manufactures 2 bits?