Hi,
I've seen a lot of discussion of this topic, but I can't seem to get it to work in KM.
I have a Philips 30PW850H TV that uses RC5 protocol from two devices, 0 and 3. Both devices have OBCs > 63. I can use the RC5 protocol to map most keys, but since there is room for only 3 device codes, I can't get in device 3 codes > 63.
I have a workaround, which is to create a second keymap and use key movers to map the device 3 codes > 63, but I would like to try the RC5/5x combo protocol.
How does one enter device codes in the dev2 column for OBCs > 63?
I've tried just entering the device code same as for OBC < 63, but those keys won't work. Adding 100 to the device code (like in the RC5 protocol) doesn't work either.
Is there a way to do this? Thanks in advance.
BTW, I have lurked on the Yahoo site and now this one forever. I built the original powered JP1 box and now use the simple interface. Sorry for being a wallflower... It always seemed that you guys were way over my head, and before now, I could always find the answer just by looking at previous posts.
Cheers, and thanks for all the wonderful work!
Mark
KM RC5/5x protocol question
Moderator: Moderators
-
jon_armstrong
- Expert
- Posts: 1238
- Joined: Sun Aug 03, 2003 9:14 pm
- Location: R.I.P. 3/25/2005
- Contact:
I don't know what assumptions KM Master uses to enter the byte two value. It is probably easier to enter the hex directly(use OBC and enter the two bytes on the OBC column with a space between them).
Here is how to calculate the two hex bytes for Protocol $0073 copied fro a previous post:
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
BTW, It may be easier just to use RC5 and device code 103 to get the upper 64 commands for device 3.
Here is how to calculate the two hex bytes for Protocol $0073 copied fro a previous post:
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
BTW, It may be easier just to use RC5 and device code 103 to get the upper 64 commands for device 3.
-Jon
Jon,
Thanks so much! I took your advice and entered the Hex Directly into the OBC column. That's the trick that I missed before.
It was not hard to compute the Hex--I used my previous RC5 keymap. The fixed data is the first byte and the RC5-computed hex is the second byte.
The combo protocol makes for a larger device upgrade than using two upgrades with RC5, but I like having everything in one keymap.
Cheers,
Mark
Thanks so much! I took your advice and entered the Hex Directly into the OBC column. That's the trick that I missed before.
It was not hard to compute the Hex--I used my previous RC5 keymap. The fixed data is the first byte and the RC5-computed hex is the second byte.
The combo protocol makes for a larger device upgrade than using two upgrades with RC5, but I like having everything in one keymap.
Cheers,
Mark