JP1 Remotes

Here's what I am using:

URC6131 remote (main)
RS15-2117 remote (learning only)
Pioneer Receiver VSX-D812K

I've been trying to map the functions in the Pioneer Master List and anotate it by placing the receiver response in the Description/Notes column. I ran into problems getting the Stereo/Direct button working (Protocol: Pioneer 1023, OBC: 159, Byte2: 2 192 --> device 2 = 165). This info is on the Pioneer Master List file. I found that if I reversed the OBC's (ex. OBC: 192, Byte2: 2 159), I could get the button working, but I'd have to hold the button down almost a half second.

So, I came here and did some heavy searching and found a suggestion by Rob to make a new upgrade code using Pioneer 2CMD (instead of Pioneer 3DEV). After doing this, I got the Stereo/Direct button working properly, but haven't tried keymoves yet. Now for the questions.

1) Is there a simply answer as to why the code works with Pioneer 2CMD but not Pioneer 3DEV? (I already know that Pioneer often "breaks the rules")

2) Has anybody else found an alternate code for the Stereo/Direct Button that uses the Pioneer 3DEV protocol?

3) I've learned this button on the RS2117 and tried a keymove to get the hex for it. I did get a hex command for it, but only the original learned key functions, i.e., the keymove did not add the function to the key. Any thoughts as to why keymoving of a learned key won't work?

Thanks for any advice...

Choven

The 3DEV protocol makes some assumptions regarding what combination of OBCs will be used for each part of the combo signal, which were probably based on the signals that Pioneer was using for their devices at one point, but Pioneer is notorious for breaking their own rules.

When you enter an OBC for the second part of the signal with the 3DEV protocol, the OBC in converted into 8 bits of binary, then only 5 of those bits are actually used in the signal, the remaining 3 bits are derived from the OBC used for the first part of the signal. If the two OBCs follow the right pattern, the signal will work, but if the second OBC doesn't match up with the first OBC correctly, then the signal will not work and you'll need to use a keymove from an upgrade that uses the 2DEV protocol.

In this case, it shouldn't matter which way around the OBCs go, it should work both ways.

For the techie folks, here's how it works:

1. Convert both OBCs to LSB binary (eg, OBC 1 = 10000000)
2. Zero out the 3 MSBs of the 2nd OBC (ie, nnnnn000)
3. If bit0 of OBC1 is clear (ie, nnnnnnn0), clear bit0 of OBC2 (ie, nnnnnnn0), otherwise set it
4. If bit1 of OBC1 is set (ie, nnnnnn1n), clear bit1 of OBC2 (ie, nnnnnn0n), otherwise set it
5. Bit2 of OBC2 is always clear (ie, nnnnn0nn)

In the example above, the two OBCs are 159 and 192, here's the LSB binary for each OBC:

OBC1 (159): 11111001
OBC2 (192): 00000011

In this case bit0 is the same for both OBCs, which is good.
Bit1 has opposite values, which is good.
Bit2 is 0 for both, which is good.

If one OBC had had bit2 set and the other had it clear, then the one with it set should be OBC1 to make this work.