Hughes HBH-SA KM, and what about Remote ID issues with this?

[mvgossman]

I've got a pair of Hughes HBH-SA satellite receivers, and the only Hughes device code KM shet I see is Hughes_HIRD_Satellite.txt "Upgrade that should work most of the HIRD models".

Is this it? It seems to be since the device code and subdevice codes as downloaded from the stock remote -> learning remote -> IR agrees. But what is HIRD?

And there's no convenient Device Address spot on the spreadsheet (as there is for the HDVR2 for instance). Am I missing a device definition sheet somewhere that has this? I did a learn from the stock remote and determined that it simply changes the OBC, so I could if necessary slog out all the codes for when the device code is set to 2 and 1, but is this the only way?

In case anyone's interested (those even more new to this than I in other words) in why I need separate device codes, I have an IR repeater system in the house on the cables to allow viewing of any of the 4 receivers anywhere in the house, and am programming some 6131's to talk to each of them without crosstalking between like units.

[mvgossman]

I'm just going ahead with the laborious deermination of the keycodes when the remote/Highes receiver HBH-SA is in remote ID 2 mode. Would this potentially be something of interest to put in the files area for the next person? Assuming of course that there is NOT a better way that I've overlooked.

By the way, is there a link explaining what EFC, OBC stand for, how they are mathematicaly related, and how the Hex code is derived? I had assumed that the Hex code was merely the Hex representation of either EFC or OBC, but I see that it is not.

[The Robman]

The Tivo upgrade uses a custom protocol written especially for Tivo, hence the inclusion of the "easy to use" 'unit code' entry.

The Hughes box, on the other hand, uses a regular protocol (NEC), so the entries are not tailor made for this box.

If you have discovered that the OBC value change for the other unit codes, my guess is that they will all change by a fixed amount. Learn a few buttons and see if this is the case. My guess is that the difference will be in units of 32 (ie, 32, 64, 96, 128).

If this is the case, you can easily change the OBCs without having to re-learn all 24 buttons.

[The Robman]

By the way, is there a link explaining what EFC, OBC stand for, how they are mathematicaly related, and how the Hex code is derived? I had assumed that the Hex code was merely the Hex representation of either EFC or OBC, but I see that it is not.

EFC stands for "Extended Function Code"
OBC stands for "Original Button Code"

To know how to get from the OBC to the hex code, you need to know what format the protocol uses (ie, LSB, LSB-COMP, etc).

For an LSB protocol, the binary would be (you can figure out the hex):

OBC Binary
001 10000000
002 01000000
003 11000000
etc

In this case the protocol is LSB-COMP, so...

OBC Binary
001 01111111
002 10111111
003 00111111
etc

[mvgossman]

The Tivo upgrade uses a custom protocol written especially for Tivo, hence the inclusion of the "easy to use" 'unit code' entry.

The Hughes box, on the other hand, uses a regular protocol (NEC), so the entries are not tailor made for this box.

If you have discovered that the OBC value change for the other unit codes, my guess is that they will all change by a fixed amount. Learn a few buttons and see if this is the case. My guess is that the difference will be in units of 32 (ie, 32, 64, 96, 128).

If this is the case, you can easily change the OBCs without having to re-learn all 24 buttons.

Thanks, Rob. I did notice the identical difference and that it's a power of two, but before your reply, I did not have enough faith to stop doing al the codes manually. I'll stop now!

For everybody else... the difference is 128. Add 128 to the OBC for each function, and it converts the remote address from the original baseline of 1 in the device upgrade description to 2.

Mitch

[The Robman]

Does this device just support two unit codes?

[mvgossman]

Does this device just support two unit codes?

It supports eight codes (1-8). No "zero" code. I'm sure it's a coincidence that 8 is a power of two. I have not determined the OBC addition formula for the other remote address codes, but I will if it might be of general interest.

[mvgossman]

Does this device just support two unit codes?

It supports eight codes (1-8). No "zero" code. I'm sure it's a coincidence that 8 is a power of two. I have not determined the OBC addition formula for the other remote address codes, but I will if it might be of general interest.

A smiley was inadvertantly created there... the device supports remote codes one through eight.

[The Robman]

Does this device just support two unit codes?

It supports eight codes (1-8). No "zero" code. I'm sure it's a coincidence that 8 is a power of two. I have not determined the OBC addition formula for the other remote address codes, but I will if it might be of general interest.

To support 8 unit codes, they must have set aside the top three bits on the OBC (in binary). If the top bit is set for unit-2, that means the unit code is in LSB format.

Therefore, I'm guessing that the unit codes are as follows:
For Unit 1, add 0
For Unit 2, add 128
For Unit 3, add 64
For Unit 4, add 192
For Unit 5, add 32
For Unit 6, add 160
For Unit 7, add 96
For Unit 8, add 224

But if you could confirm that, it would be great.

A smiley was inadvertantly created there... the device supports remote codes one through eight.

That happens when you put an 8 and a ) next to each other, to fix it either put a space between them or check the "Disable Smilies in this post" box

[mvgossman]

Interesting, not so simple. The higher codes beyond device code 2 are more complex.

Device Code Main Device Sub Device OBC addition factor
1 12 251 0 (baseline)
2 12 251 +128
3 60 178 0
4 60 178 +128
5 33 4 0
6 33 4 +128
7 69 5 0
8 69 5 +128

Apparently they went with different device ID's having run out of bits on the OBC?

I see my columns did not work out, but you get the picture.

These numbers are actually downloaded, i.e. no assumptions after a pattern became evident (pairs of device/subdevice).