Accessing RC5x commands when the OBC>=64 ?

bluenose · Post by **bluenose** » Sat Nov 08, 2003 4:41 pm

I'm creating a device upgrade for Marantz SR-5300 Receiver using keymaster and protocol RC-5/5x combo. My starting point is the Marantz SR-7200 Receiver file from the JP1 Yahoo group. My remote is the 15-1994.

My difficulty is accessing RC5x commands when the OBC > 64.

For example, I used ccf2efc on a downloaded CCF file to get the following button codes:

"CS Music" (RC5x):16.37:62 {T=1}

"CS Cinema" (RC5x):16.0:66 {T=0}

I can program "CS Music" (because the OBC is 62), but cannot program "CS Cinema" (because the OBC is 66).

I suspect I need another device number when OBC>=64. Thus far I've tried devices 116 and 48 (16+32=48 ) without success. I've also tried 17.64:2 (because the Marantz SR-7200 file from Yahoo groups defines the key like this). So far no luck.

Thanks in advance for the help. Thanks also those whose unpaid efforts make "JP1" remotes so powerful.

jon_armstrong · Post by **jon_armstrong** » Sun Nov 09, 2003 2:24 pm

UPDATE:

This is not correct you can use $073 to access all commands within RC5 and RC5x see details in posts further down.

I think neither of the two official protocols that can do RC5x ($00F2 and $0073 and only in some remotes) can set the second control bit to zero that designates the upper 64 commands. I have also never seen an OBC in RC5x > 63 but I asumed they existed. The only solution I could come up with was to use Protocol Builder and create a protocol and device upgrade that can do what you want.

You can input these into IR and they should work on your 1994.

Upgrade Code 0 = 0F CF (Cable/1999)
F2 00 81 6F 00 00 FF F7 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
End

Upgrade Protocol 0 = 01 F2 (S3C8)
47 93 12 8B 17 8D 81 10 08 06 01 BD 01 A9 01 BD
01 A9 B7 FB 00 00 06 E0 FF FF FF 09 08 00 27 0B
03 77 77 8D 01 33
End

Here is how you calculate the device and 2 byte commands.

Device:

For the upper 64 commands use device+128 then take the binary complement and convert to hex:

16+128=144 and
255-144=111 decimal is the binary complement => 0x 6F

The two variable bytes are:

Byte1 is the subdevice and is the hex equivalent of the binary complement of subdevice x 4 :
4 x 0 = 0
255-0=255 decimal ==> 0x FF

Byte 2 is the hex equivalent of the binary complement of (OBC-64) x 4:
66-64=2
2 x 4 =8
255-8=247 decimal ==>0x F7

Hence FF F7 is the two byte command.

It is also on the numeral 1 so you can test.

I don't mean to be too basic here but in case you can't manipulate binary to hex in your head, I thought I would show the steps

bluenose · Post by **bluenose** » Sun Nov 09, 2003 6:23 pm

The upgrade protocol works! Thank you very much.

I successfully entered some other hex commands by replacing pairs of zeros in the protocol upgrade posted above.

I will use keymoves to add some of these functions into my RC5/5x combo device definition. I’ll later try the protocol with 15-1994 extender 5 (for more macro memory).

For your information, Marantz receivers (SR-xx00) now have some descrete sound modes mapped with OBC>=64. Here are the RC5x codes I know of:

16.0.64 - (FF FF) - Prologic 2 Cinema
16.0:65 - (FF FB) - Prologic 2 Music
16.0:66 - (FF F7) - Circle Surround Cinema
16.0:67 - (FF F3) - DTS ES
16.0:68 - (FF EF) - 5.1 Music (not supported by SR-5300)
16.0:69 - (FF EB) - Neo 6 Cinema
16.0:70 - (FF E7) - Neo 6 Music
16.0:71 - (FF E3) - Ultra 2 (not supported by SR-5300)
16.0.72 - (FF DF) - Neo 6 Music/Cinema Toggle
16.0.75 - (FF D3) - HT-EQ (Home Theater EQ)

Thanks again for the prompt and expert response. I can’t applaud the JP1 efforts enough!

(Nov 11/2003 edited to update table of known codes)

jon_armstrong · Post by **jon_armstrong** » Sun Nov 09, 2003 7:12 pm

If you only need device.sub-device 16.0, I can make the upgrade smaller if you are short on upgrade space. It will be easy to change to a single byte of variable data and save key move space also. I can also post the text file for Protocol builder and the KM Master device upgrade. If you want to do it yourself. I will be out of town for a week and won't have any ability to test. So it may be a while before I can do it.

Also, if John or Rob are reading this, there is one spare bit of variable data in the RC5/RC5x combo protocol ($0073) bit 3 of Byte 2 that AFAIK, doesn't do anything.

It may be worth modifying the $0073 protocol so that bit 3/byte2 will set the second bit of fixed data since Marantz needs both RC5 and RC5x and now apparently also RC5x OBC's > 63.

bluenose · Post by **bluenose** » Mon Nov 10, 2003 9:10 pm

My upgrade space seems ample. It’s the macro/keymove space that has run out, though I expect switching to the 15-1994 extender-5 will provide enough keymove memory.

I am very happy to use the protocol that you’ve posted supporting 256 subdevices. If you make another protocol specific to subdevice 0, I will switch to save keymove memory.

But if you have motivation and time to donate, I suggest you rather modify the $0073 protocol for the best enduring solution. This solution is also easiest to document and explain because it should provide seamless support for RC5x when OBC >63.

I can test whatever further RC5x code is written.

To do this myself would take much learning effort and time, certainly longer than a week. (Although, I’ve done novel things reprogramming DVD players).

I very much appreciate your efforts.

Thanks to those who have donated time and expertise making JP1 remotes so powerful.

omri · Post by **omri** » Tue Jan 20, 2004 9:46 am

Has any progress been done on this?
I am trying to create a device upgrade for a Marantz VP12S3 projector that uses both RC5 and RC5x, and in both of them OBC>63.

If anyone is interested, the buttons are:(name: protocol device OBC)
power on: RC5x 0.12 1
power off: RC5x 0.12 2
V.mute: RC5 0 13
menu: RC5 0 46
input: RC5 0 56
aspect: RC5x 0.61 67
up: RC5 0 28
down: RC5 0 29
left: RC5 0 44
right: RC5 0 43
select: RC5 0 87
patt: RC5x 0.15 1
comp1: RC5x 0.56 1
comp2: RC5x 0.56 6
svideo: RC5x 0.56 2
video: RC5x 0.56 3
RGB: RC5x 0.56 4
AUX: RC5x 0.56 5
full: RC5x 0.31 2
normal: RC5x 0.31 1
zoom: RC5x 0.31 3
through: RC5x 0.31 4
theater: RC5 0 126
std: RC5x 0.61 66
dyna: RC5 0 116
user: RC5x 0.61 65
cinema: RC5 0 118
info: RC5 0 15

As you can see - they are all under one device, but mix RC5 and RC5x and verious subdevices.
I can use the RC5/RC5x combo, but I won't be able to get to the buttons with OBC>63.

Any suggestions?

Thanks in advance,

Omri

jon_armstrong · Post by **jon_armstrong** » Thu Jan 22, 2004 1:25 pm

All of those commands CAN be done in Protocol $0073 .

Short explanation: Download the device upgrade that has all commands:

http://groups.yahoo.com/group/jp1/files ... jector.txt

You will have to assign commands to keys on the buttons tab first.

Long explanation:

You can do commands greater than 64 for both RC5 and RC5x. Here is as complete of a definition for RC5/RC5x combo protocol $0073 as I can come up with.

$0073 is a two byte protocol where the bottom bit of byte 2 if Zero will select RC5 and if One, RC5x. In RC5 any device and OBC can be used for any command.

In the RC5x mode you can call up to four different "half" devices similar to the regular RC5 protocol. It turns out that what we have defined as sub-device can actually have values of 0-63 depending on the second data bit or 64-127 but OBC's only from 0 to 63. This is a semantical difference to reconcile it with the Pronto database format.

Here is a recap of the protocol definition and what bits go where:

RC5 {36k,msb,889}<1,-1|-1,1>(1:1,~F:1:6,T:1,D:5,F:6,^114m)+

Protocol ID $0073 in RC5 mode (where bits are numbered 7,6, ..., 1,0)

Hex Byte 1
Bits 0..4 -- device complement 0..4
Bit 5 -- doesn't matter
Bit 6 = 0 for OBC's < 64 and 1 for OBC's > 63
Bit 7 = 0

Hex Byte 2
Bit 0 -- 0 for RC5 (1 is RC5x)
Bit 1 -- doesn't matter
Bits 2..7 -- OBC complement bits 0..5

For RC5x
Hex Byte 1
Bits 0..1 -- OBC complement bits 4..5
Bits 2..7 -- Sub-device complement bits 0..5

Hex Byte 2
Bit 0 = 1 for RC5x
Bits 1..2 -- call order for the four bytes of fixed data in 0,1,2,3 order
Bit 3 -- doesn't matter
Bits 4..7 OBC Complement bits 0..3

Fixed Data all four bytes
Bits -- 0..4 Device complement 0..4
Bit 5 -- doesn't matter
Bit 6 -- 0 for S <64, 1 for S > 63
Bit 7 -- 0

Decode IR will decode learned commands as

RC5x:0.61:65
RC5x:0.61:66

Interestingly, when I looked those up in the Marantz ccf file on their website the file had database command for the same commands as:

RC5x:0.125:1
RC5x:0.125:2

And that means our interpretation of RC5x is incorrect and should be:

RC5x {36k,msb,889}<1,-1|-1,1>(1:1,~S:1:6,T:1,D:5,-4,S:6,F:6,^114m)+

The second data bit is actually the complement of the top bit of S (not F)

johnsfine · Post by **johnsfine** » Thu Jan 22, 2004 1:40 pm

jon_armstrong wrote: And that means our interpretation of RC5x is incorrect and should be:

RC5x {36k,msb,889}<1,-1|-1,1>(1:1,~S:1:6,T:1,D:5,S:6,F:6,^114m)+

The second data bit is actually the complement of the top bit of S (not F)

I don't have time now to read all the above carefully enough nor to test with KM to actually understand it, so I'l try just asking the bottom line question regarding DecodeIR.

Should I make the above trivial change to the way DecodeIR reports RC5x, or should I leave it the way it is (incompatible with the Marantz data you found) to maintain compatibility with our (JP1 group) past practice?

jon_armstrong · Post by **jon_armstrong** » Thu Jan 22, 2004 2:04 pm

I think you should make the trivial change to the decoder. Otherwise when the decoding the database format (where alot of RC5x commands come from) in DecodeCCF will not agree with the occasional learned RC5x command.

The second piece of information is that the top two bits of fixed data in $0073 that are only used in the RC5x are the same as the first two data bits in RC5x.

We should probably collaborate on getting $0073 into RM while it is fresh in my mind, since I just tested these features before posting the device upgrade and am pretty certain that I got it right.

johnsfine · Post by **johnsfine** » Mon Jan 26, 2004 12:24 pm

What should the UI for this RC5/RC5x combo be in RM to minimize user confusion, but within reasonable limits of implementation difficulty?

I have two different proposals. Jon, Greg and others, please comment:

A) Four functions sheet columns:

1) Protocol: A two way pull down RC5/RC5x

2) Device: When protocol is RC5 this is a numeric type in field. When protocol is RC5x this is a 4-way pull down of the four device numbers from the setup sheet.

3) Subdevice: When protocol is RC5 no entry is permitted (force blank or force the word none). When protocol is RC5x this is a numeric entry field.

4) OBC.

This design presents the data the same way the decoder does, so I think it is least confusing. But I don't know how to write the required Java code (to change the behavior of columns 2 and 3 based on the choice in column 1).

B) Three columns:

1) Prot/Dev: A five way pull down selecting from RC5, RC5x:d1, RC5x:d2, RC5xd3, RC5x:d4

2) Dev/Sub: Numeric entry of dev number for RC5 and subdev number for RC5x

3) OBC.

I would know how to build that within the RM structure (it's still a moderate amount of new Java code, but nothing fundamentally different from things that are in other tricky protocols). Also, since it is more closely tied to the abilities of the executor, it more clearly tells the user what he can or can't choose. It avoids the "why can't I?" type questions that might hit design A.

I'm uncomfortable a choosing bettwen column names that are concise enough to be unclear or long enough to be ugly in the UI.

jon_armstrong · Post by **jon_armstrong** » Mon Jan 26, 2004 4:12 pm

I don't see B as much harder for a user than A, but here is a complicating factor. In RC5x only, Bit 6 in fixed data selects whether Sub-device range is 0-63 or 64-127. So in B) 1), would that be a 9-way pull down box and add the > 64 or <63 sub-device range?

The other choice is a lot more logic, but you could set the 6th byte of fixed data depending on the value of S but if someone had already chosen D=16 and then wanted 16.12 and 16.127 that seems more complicated to me.

I think the 9-way pull down box would alert the user to the problem earlier and they would have to use up an additional byte of fixed data.

johnsfine · Post by **johnsfine** » Mon Jan 26, 2004 5:09 pm

jon_armstrong wrote:I don't see B as much harder for a user than A,

You may be assuming a higher level of user expertise than I am.

A user would have no trouble if he understood two thing:
1) "RC5x:23" means Protocol RC5x, Device 23.
2) RC5x has subdevices and RC5 doesn't

jon_armstrong wrote: but here is a complicating factor. In RC5x only, Bit 6 in fixed data selects whether Sub-device range is 0-63 or 64-127. So in B) 1), would that be a 9-way pull down box and add the > 64 or <63 sub-device range?

It can't be a 9 way pull down. There are really only 5 choices. Notice the way RC5 currently works in RM.

Each device on the setup sheet will need an associated choice for subdevice>63, just like the setup sheet in RC5.

It would be best to have some tricky coodination of the OBC with the pull down (again similar to what is in RC5 now) so that a device number could be put twice on the setup sheet with opposite >63 choice and the functions sheet would appropriately make the invisible change to the pull down state as required by the OBC bit. All that is the same in my UI version A and B.

jon_armstrong · Post by **jon_armstrong** » Tue Jan 27, 2004 2:09 pm

johnsfine wrote:Each device on the setup sheet will need an associated choice for subdevice>63, just like the setup sheet in RC5.

It would be best to have some tricky coodination of the OBC with the pull down (again similar to what is in RC5 now) so that a device number could be put twice on the setup sheet with opposite >63 choice and the functions sheet would appropriately make the invisible change to the pull down state as required by the OBC bit. All that is the same in my UI version A and B.

I'm sure you already know these two things, but Fixed Data bit 6 either is bit 6 of F OR S. I think in your second paragraph, you meant sub-device rather than OBC. IIUC, you are suggesting adding 100 to device to get sub-device >63.

Also, in the case of the OBC's >63 in RC5 mode, all 7 bits of OBC are in the variable bytes, so you can choose any Device/OBC (0-127)combination.

johnsfine · Post by **johnsfine** » Tue Jan 27, 2004 2:40 pm

jon_armstrong wrote: I'm sure you already know these two things, but Fixed Data bit 6 either is bit 6 of F OR S.

I not only didn't know, I still don't understand. I thought I could get away with making the UI suggestions prior to understanding how all the data bits are managed.

jon_armstrong wrote: I think in your second paragraph, you meant sub-device rather than OBC.

Yeah. That's right. That's what I meant. Right

jon_armstrong wrote: IIUC, you are suggesting adding 100 to device to get sub-device >63.

NO. I am absolutely NOT suggesting that. I am suggesting a check box, just like RM has for RC5. NOT like KM has for RC5.

jon_armstrong · Post by **jon_armstrong** » Tue Jan 27, 2004 7:16 pm

johnsfine wrote:
jon_armstrong wrote: I'm sure you already know these two things, but Fixed Data bit 6 either is bit 6 of F OR S.
I not only didn't know, I still don't understand. I thought I could get away with making the UI suggestions prior to understanding how all the data bits are managed.

Right now for RC5x, DecodeIR.dll decodes the second data bit (in order of transmission) of the actual command as the complement of bit 6 of F. As I mentioned earlier in the thread, the Official Marantz file for their projectors had database command where S>63 but F was 0 to 63. This lead me to conclude that S can be 0 to 127 but F can only be 0 to 63 in RC5x.

I suggest that you change DecodeIR.dll to conform to the database command, but your RM GUI should reflect the interpretation that will be returned from decodeIR.dll. You probably could set a valid range for RC5x from 0 to 63 for OBC and that way it will be more foolproof.

BTW, I don't think there are any backwards compatibility issue since this is the first time I have seen an RC5x command where the second data bit (in order of transmission) was anything but 1.

(OK, who had the stupid idea to add 100 to the device code in RM...)