Pioneer Receiver device (RCVR/1023) question(s)

[Capn Trips]

Short Questions:
(1) Does the RS 15-2117 built-in setup code for RCVR/1023 use the Pioneer 3Dev protocol?

(1a) If so, what is the order of listed device codes it accesses?
(1b) If not, what is the protocol and associated fixed data?

Longer boring ramble:

I am trying to reduce my reliance on Device Upgrades and shift some of my functions over to KeyMoves utilizing resident setup codes in my RS 15-2117. In particular, for my Pioneer VSX-D710S, I have found that built-in code RCVR/1023 operates some (but not all) of the functions of this receiver.

Since the device upgrades for these receivers all seem to use the Pioneer 3Dev protocol, it appears that the order in which the devices are listed determines (at least in part) what the second part of the two-byte Hex Cmd needs to be. Correct?

I note that in the various Pioneer receiver upgrade files, this 3Dev code is used, but the order, and even NUMBERs of the device codes vary. For example, the "Pioneer_1023" upgrade file lists the three Device Codes as 162, 165, and 164. While the "Pioneer_Master" upgrade uses 162, 164, and 165. The upgrade I built from scratch uses 165, 164, and 164.

So I can't just blindly take the two-byte Hex Cmds from any of these Pioneer upgrade files and use them as Keymoves calling on the built-in RCVR/1023 codes without an awareness of how the built-in setup code sequences the device codes, right?

How do I do that?

[johnsfine]

Short Questions:
(1) Does the RS 15-2117 built-in setup code for RCVR/1023 use the Pioneer 3Dev protocol?

Yes.

(1a) If so, what is the order of listed device codes it accesses?

162, 165, 164

(1b) If not, what is the protocol and associated fixed data?

PID 006A: 45 A5 25

So I can't just blindly take the two-byte Hex Cmds from any of these Pioneer upgrade files and use them as Keymoves calling on the built-in RCVR/1023 codes without an awareness of how the built-in setup code sequences the device codes, right?

How do I do that?

Ask an expert (as you did) is easiest and acceptable.

The harder do it yourself method is to take a know built in command in the built in setup code and keymove its key manually on the remote itself to some other key or device mode. Download to IR and look at the 2'nd byte of the hex. Compare to what you get in KM or RM and thus deduce the sequence of devices in the built in setup code.

[Capn Trips]

Great! All answers close to what I suspected. Follow-up questions:

(2) OK, I now build a KM Device Upgrade using Pioneer 3 Dev protocol, with 162, 165, and 164 as my devices. I learn and decode all of my OEM functions that are NOT mapped to buttons by the installed RCVR/1023 setup code. Insert the appropriate data into the KM functions sheet and this generates for me the two-byte Hex Codes I need to make Key Moves for my missing functions, correct?

(2a)In fact, I can generate the KeyMoves right there in KM and copy/paste them directly into IR. Am I still correct?

(3) There are signals being generated by the 15-2117 from this setup code that are NOT resident on the OEM remote. So I want to determine what these signale are. I Keymove RCVR/1023 buttons from the Audio device to the Aux device, download to IR and look at Keymoves Tab. In those cases where the second byte is "$00", "$40" or "$80", I deduce that it is a one-byte command, calling on the 162, 165, or 164 device code, respectively. Correct?

(3a) How do I deduce those commands in which the second byte is someting else? (like, oh say, "$20", "$48", or "$50") I presume these are two-byte signals being generated, right?

[The Robman]

Short Questions:
(1) Does the RS 15-2117 built-in setup code for RCVR/1023 use the Pioneer 3Dev protocol?

(1a) If so, what is the order of listed device codes it accesses?
(1b) If not, what is the protocol and associated fixed data?

Maybe this file would be of use to you: Pioneer-1023.txt This upgrade accurately reflects the 1023 code and lists the device codes in the right order. Any other upgrades created by indivudual users can have the combined device codes in any order, so they're not a good guide to the built in code.

I am trying to reduce my reliance on Device Upgrades and shift some of my functions over to KeyMoves utilizing resident setup codes in my RS 15-2117. In particular, for my Pioneer VSX-D710S, I have found that built-in code RCVR/1023 operates some (but not all) of the functions of this receiver.

As you know, the 1023 code combines device codes 162, 164 and 165, and it also allows the "2CMD" versions of those signals to be generated.

If your learned functions are simple 1-part signals, you can create simpler keymoves if you use the simple 1 device setup codes, such as these:

162 = (CD/0032)
164 = (RCVR/0080)
165 = (AMP/0013)

If the signals are 2-part, you can determine the hex code in KM and then use keymoves based on these built in setup codes:

162 = (AMP/0300)
165 = (AMP/0823)

Note: some "2cmd" style signals don't work with the "3dev" protocol, so using the "2cmd" setup codes would be required for some combinations.

3) There are signals being generated by the 15-2117 from this setup code that are NOT resident on the OEM remote. So I want to determine what these signale are. I Keymove RCVR/1023 buttons from the Audio device to the Aux device, download to IR and look at Keymoves Tab. In those cases where the second byte is "$00", "$40" or "$80", I deduce that it is a one-byte command, calling on the 162, 165, or 164 device code, respectively. Correct?

(3a) How do I deduce those commands in which the second byte is someting else? (like, oh say, "$20", "$48", or "$50") I presume these are two-byte signals being generated, right

What difference does it make? The keymoves themselves tell you exactly what hex code to use, so all you need to do is create similar keymoves when you've re-loaded the extender and you'll be all set.


As for the bigger picture, what I think you really need is a new version of the extender that uses the learning memory as an upgrade section rather than a keymove/macro section.

[Capn Trips]

Maybe this file would be of use to you: Pioneer-1023.txt This upgrade accurately reflects the 1023 code and lists the device codes in the right order. Any other upgrades created by indivudual users can have the combined device codes in any order, so they're not a good guide to the built in code.

Got it. Thanks. I saw this along with several others and couldn't figure out which was the "true" built-in 1023 code.

As you know, the 1023 code combines device codes 162, 164 and 165, and it also allows the "2CMD" versions of those signals to be generated.

If your learned functions are simple 1-part signals, you can create simpler keymoves if you use the simple 1 device setup codes, such as these:

162 = (CD/0032)
164 = (RCVR/0080)
165 = (AMP/0013)

If the signals are 2-part, you can determine the hex code in KM and then use keymoves based on these built in setup codes:

162 = (AMP/0300)
165 = (AMP/0823)

Note: some "2cmd" style signals don't work with the "3dev" protocol, so using the "2cmd" setup codes would be required for some combinations..

Thanks! That is GREAT poop. In fact, most (if not all) of my learned signals are either 1-byte Dev 164s or 2-byte Dev 165s, so I should be able to use RCVR/0080 and AMP/0823 as the "source" for KeyMoves of those functions, right?

3) There are signals being generated by the 15-2117 from this setup code that are NOT resident on the OEM remote. So I want to determine what these signale are. I Keymove RCVR/1023 buttons from the Audio device to the Aux device, download to IR and look at Keymoves Tab. In those cases where the second byte is "$00", "$40" or "$80", I deduce that it is a one-byte command, calling on the 162, 165, or 164 device code, respectively. Correct?

(3a) How do I deduce those commands in which the second byte is someting else? (like, oh say, "$20", "$48", or "$50") I presume these are two-byte signals being generated, right

What difference does it make?

Surely you're kidding! Right? The difference?! Why did man climb Everest? Why did we go to the moon? The eternal pursuit of knowledge, of course! (Of course, if I'm so all-fired up about the "pursuit of knowledge" all I have to do is learn these signals from the 2117 to my 1994 and decode them and I will have all of the answers right there in front of me, but then that would be almost like work, wouldn't it? )

As for the bigger picture, what I think you really need is a new version of the extender that uses the learning memory as an upgrade section rather than a keymove/macro section.

Yeah, but not really. The extended remote is MORE than capable of meeting my "needs". I just continuously try to tweak and pack in more and more of the functions that I will NEVER, EVER use (balance for each speaker, for example) primarily because it gives me a perverse sense of accomplishment and indeed, a greater and greater understanding of what oes on in these remotes and the tremendous amount of work you experts have put into developing this entire system of hacking with these simple, inexpensive tools. Truly remarkable accomplishments in which you just keep setting the bar higher and higher, and I commend and thank all who continue to help the beginning and intermediate JP1-er.

[The Robman]

We also help experts!

[The Robman]

What difference does it make?

Surely you're kidding! Right? The difference?! Why did man climb Everest? Why did we go to the moon? The eternal pursuit of knowledge, of course! (Of course, if I'm so all-fired up about the "pursuit of knowledge" all I have to do is learn these signals from the 2117 to my 1994 and decode them and I will have all of the answers right there in front of me, but then that would be almost like work, wouldn't it? )

Not as much work as decoding the data, but if you really want to get your hands dirty, here goes...

Let's say that the hex code is "D9 4D", first you will need to break both codes down to the binary code, which is:

D9 = 11011001
4D = 01001101

The first byte is the OBC in LSB format, so if you read it backwards and convert it to decimal, you get 155.

The first 3 bits of the second byte tell us which device code is in use, as follows:

100 = dev1
010 = dev2
001 = dev3
000 = dev3

So, in this case, it's dev2.

If the remaining 5 bits are not all zeroes, it means this signal uses the "2cmd" structure. Here's how you get the 2nd OBC:

First, take the 5 rightmost bits from the binary for the second byte, which gives you: 01101, these are the 5 leftmost bits of the second part of the signal. The next bit is always 0, the next bit is always the complement of the same bit from the first byte, and the final bit is always the same as the same bit from the first byte

so the binary is:
01101 0 1 1

If you then read this backwards and convert it to decimal you will get OBC 214.

HEY, you asked!!!

This is the MENU function, by the way.

If you're wondering why some "2cmd" functions don't work with the "3dev" protocol, it's because sometimes it's the 7th bit that should be a copy and the 8th bit that should be complimented. I've given UEI a fix for this, btw.

[Capn Trips]

if you really want to get your hands dirty, here goes...

Let's say that the hex code is "D9 4D", first you will need to break both codes down to the binary code, which is:

D9 = 11011001
4D = 01001101

The first byte is the OBC in LSB format, so if you read it backwards and convert it to decimal, you get 155.

The first 2 bits of the second byte tell us which device code is in use, as follows:

00 = dev1
10 = dev2
01 = dev3

So, in this case, it's dev3.

If the remaining bits are not all zeroes, it means this signal uses the "2cmd" structure. Here's how you get the 2nd OBC:

First, take the 5 rightmost bits from the binary for the second byte, which gives you: 01101, these are the 5 leftmost bits of the second part of the signal. The next bit is always 0, the next bit is always the complement of the same bit from the first byte, and the final bit is always the same as the same bit from the first byte

so the binary is:
01101 1 1

If you then read this backwards and convert it to decimal you will get OBC 214.

HEY, you asked!!!

This is the MENU function, by the way.

If you're wondering why some "2cmd" functions don't work with the "3dev" protocol, it's because sometimes it's the 7th bit that should be a copy and the 8th bit that should be complimented. I've given UEI a fix for this, btw.

Of course! How silly of me to not have noticed this obvious connection!

(although as I follow your explanation, am I correct in assuming that you omitted a 0 in the reconstruction of the second OBC in binary form?)

so the binary is:
01101 1 1

should be 01101 0 1 1, correct?

I worry greatly when I start understanding what I'm talking about

[The Robman]

Of course! How silly of me to not have noticed this obvious connection!

And just so you know, any blame for this rests squarely with Pioneer. Their remote control engineers have a really weird sense of humor!

(although as I follow your explanation, am I correct in assuming that you omitted a 0 in the reconstruction of the second OBC in binary form?) "01101 1 1" should be "01101 0 1 1", correct?

Yes absolutely, I did that just to see if you were following along, but you passed the test, so I have edited the original post now to make it look like you don't know what you're talking about!

I worry greatly when I start understanding what I'm talking about

Yeah, me too.

[Capn Trips]

So, using this magic, I look at the Hex Code for the KeyMoved "Band" function, and it is $C8 $20.

Breaking it down as you describe, I get:

C8 = 11001000 = OBC:19
20 = 00100000; separating it out - 00/1/00000
The first "00" = Dev 1;
The next "1" means there is a second OBC;
Building the OBC, I get 00000 0 1 0 = OBC:64

I enter the data from above in KM (OBC1=19, Device=1, OBC2=64) and lo and behold, the computed Hex is C8 80! Wassup?!

The same function, LEARNED from the OEM and decoded, yields a single OBC:19 and the Device corresponding to Dev 3!, which inserted into KM yields $C8 $00.

C8 = 11001000 = OBC:19
00 = 00000000; 00 = Dev 1; no second OBC due to all remaining zeroes.

Did you (or I) mix up devices 1 and 3 in this discussion? and is the third bit of the second byte material to this decyphering?

HAAALLLLPPPP!

[The Robman]

OK, I have mispoken a little. I did imply that the 3rd bit has some bearing on the proceedings, but it doesn't. I also gave you the device code values out of order.

Instead of extracting the first 2 bits, extract the first 3 bits, then use this chart to get the device code:

100 = dev1
010 = dev2
001 = dev3
000 also = dev3

[Capn Trips]

Ahh! It all coalesces now!

Just one little thing. Using these rules, $C8 $20 decodes to OBC 19, Dev 3, no second OBC. Entering OBC 19 Dev 3 in KM gives me $C8 $00! I can't revers-engineer the $20!

So WHERE does that damned $20 second byte come from? (A-ha, the first three bits of the second byte being 00000000 or 00100000 (yielding $00 or $20 respectively) BOTH give me the same result - a single OBC using Device 3, do I have it right now?) I guess KM just picks the easiest way to go and uses the 000 rather than 001 to specify the device.

Thanks for the detailed explanations.

[The Robman]

Yup, the way the actual protocol code is coded, it makes no difference how that 3rd bit is set. KM uses 0 but evidently UEI uses 1.

[Capn Trips]

Robman,

I was trying to locate the "official" Pioneer AUD/1023 code that you linked to in this message, but it's no longer there. I looked around but couldn't find it either at Yahoo or here. Can you please re-post it in the Official UEI upgrade section?

Maybe this file would be of use to you: Pioneer-1023.txt This upgrade accurately reflects the 1023 code and lists the device codes in the right order. Any other upgrades created by indivudual users can have the combined device codes in any order, so they're not a good guide to the built in code.

As you know, the 1023 code combines device codes 162, 164 and 165, and it also allows the "2CMD" versions of those signals to be generated.

If your learned functions are simple 1-part signals, you can create simpler keymoves if you use the simple 1 device setup codes, such as these:

162 = (CD/0032)
164 = (RCVR/0080)
165 = (AMP/0013)

If the signals are 2-part, you can determine the hex code in KM and then use keymoves based on these built in setup codes:

162 = (AMP/0300)
165 = (AMP/0823)

Note: some "2cmd" style signals don't work with the "3dev" protocol, so using the "2cmd" setup codes would be required for some combinations.

[The Robman]

Here's the version that's at Yahoo...
http://groups.yahoo.com/group/jp1/files ... o-1023.txt

You're right, it looks like it didn't et copied over to here yet.