Device upgrades and protocol upgrades

[floyd1977]

There's something I've been wondering about for a while now. I have a Pioneer Receiver, and I'm using device code 1023. From what I understand, you cannot use advanced codes with RECV 1023 (why?).

So, I downloaded an upgrade from the site, edited it with KM and copied it into IR. Everything works fine, but I'm wondering why I needed to copy the protocol upgrade. Is it because the built in 1023 code uses a different protocol than the upgrade, which uses protocol 1D0? The reason I ask is because the built in 1023 code works for a few basic functions: vol +/-, mute, preset +/-, AM/FM, a few random input selects on 0-9, etc.

All the setup codes included with the remote are the ones in the instruction manual, but is there a way to find out what protocols are built into my remote?

[tnkrer]

There's something I've been wondering about for a while now. I have a Pioneer Receiver, and I'm using device code 1023. From what I understand, you cannot use advanced codes with RECV 1023 (why?).

A wild guess, the built in protocol for RECV 1023 does not support adding extra signals other than the preset ones?

[johnsfine]

There's something I've been wondering about for a while now. I have a Pioneer Receiver, and I'm using device code 1023. From what I understand, you cannot use advanced codes with RECV 1023 (why?).

It uses two bytes of command information per function. Simpler setup codes use just one byte.

Except on the new remotes (with full support for five digit EFC numbers) you can't create a two byte command from an EFC number.

With JP1 you can create KeyMoves based on RCVR/1023, using Hex command mode rather than EFC mode. But to compute the right hex commands, you need to know some protocol details on RCVR/1023.

but is there a way to find out what protocols are built into my remote?

In the rdf file there is a list of protocols that are in your remote and which varient of each protocol.

KM may have chosen either a different protocol or a different variant of a protocol than RCVR/1023 uses. I don't know the details of Pioneer protocols at that level. A lot of those details are shown in RM's protocols.ini file.

[floyd1977]

Thanks, johnsfine.

It should've been obvious to me why advanced codes wouldn't work with 1023. I knew it used two-byte commands and that EFCs were one byte; I just didn't put the two together.

Thanks for your help. I'll see if I can find some info on calculating the hex commands, unless someone has that information handy.

[The Robman]

RCVR/1023 uses the "Pioneer 3DEV" protocol. $01D0 is the id that KM uses for my homemade "Pioneer 4DEV" protocol. The 4DEV protocol allows you to use the complete range of Pioneer functions, whereas there are some functions that cannot be programmed using the 3DEV version.

As long as you don't need the functions that cannot be programmed, you can switch the selected protocol from 4DEV to 3DEV and the protocol upgrade will no longer be required, and you can then use KM to generate the hex commands for you.

[floyd1977]

Thanks a lot, Rob! I'll try it out and see if there are any unavailable functions in 3DEV that I can't do without.

[The Robman]

These are the functions that show up as "ERROR" when you switch from the 4DEV to the 3DEV protocol....

RCVR bass/treb -
RCVR bass/treb +
RCVR bass/treble
RCVR Dialog Enhancement
RCVR display
RCVR MCACC
RCVR sur movie
RCVR sur music
RCVR tone

[floyd1977]

Rob,

That's fine, I don't need those particular functions. Can you point me to the upgrade you were using when you switched from 4DEV to 3DEV? The one I'm using isn't working. Only a few functions work, like Vol +/- and Mute. I see that the 2-byte codes for each function are different than before, and it's using protocol 06A:

Upgrade code 0 = a3 ff (Tuner/1023) (RM v1.51)
6a 00 f6 fd c5 a5 25 00 c0 80 c0 40 c0 c0 c0 20
c0 a0 c0 60 c0 e0 c0 10 c0 90 c0 50 40 d0 40 48
40 08 c0 88 c0 38 40 42 5c 82 5c ea c0 6a c0 6a
44 c2 c0 aa 40 c8 c0
End

My old upgrade looked like:

D0 00 F6 FD C5 A5 25 05 04 00 84 80 44 40 C4 C0
24 20 A4 A0 64 60 E4 E0 14 10 94 90 50 54 D0 D4
48 4C 0C 08 8C 88 38 3C 42 E4 82 E4 EE EA 6E 6A
6A 24 C6 C2 AA AE CC C8

[floyd1977]

Coincidentally, the commands that work are the ones that have the same first byte as the original hex command.

[The Robman]

Here ya go...
https://www.hifi-remote.com/forums/dload ... ile_id=508

[floyd1977]

Rob,

When I used your upgrade file, I came up with the exact same upgrade
I had before (I think I used this upgrade file originally), and I have the
same results (only some of the functions work).

I also tried creating my own upgrade with Pioneer DEV3, but that didn't seem to work either. When I look at my decoded signals in IR (that I learned from my original Pioneer remote), all it says for Protocol is "Pioneer."

By the way, sorry for the delay. I had a terrible stomach virus the last few days...

Thanks again.
--Nathan

[johnsfine]

I also tried creating my own upgrade with Pioneer DEV3, but that didn't seem to work either. When I look at my decoded signals in IR (that I learned from my original Pioneer remote), all it says for Protocol is "Pioneer."

You might be confused by the uses of the word "protocol" for a few related but not identical concepts.

From the decoder's view, a protocol is a way of encoding data in IR signals. Actually "Pioneer" is three different ways (one way of encoding single part signals and two ways of encoding two-part signals). But the decoder doesn't know any of that. It just reports each frame of the signal as "Pioneer". If all the decoded frames of one signal are the same (or there is only one frame) it is a one part Pioneer signal. If there are two different frames decoded from one signal it is one of the two-part formats.

From the point of view of KM or RM, a protocol is a "protocol executor" (instructions for the remote to translate fixed data and hex commands into IR signals) plus instructions for KM or RM to translate device and OBC information into fixed data and hex commands.

Each Pioneer "protocol" in KM or RM can generate some set (per upgrade) of Pioneer signals. The difference between Pioneer protocols in KM or RM is not in the structure of the individual signals. It is in the way you can mix multiple different signals in one upgrade. A less powerful Pioneer protocol in KM or RM might have the ability to generate any one of the some set of Pioneer signals, but lack the ability to combine that set into a single upgrade.

As for which Pioneer protocol in KM or RM can do what, I don't begin to know/remember as much as Rob does, so I won't comment. I'm just trying to explain the relationship between Pioneer "protocol" as decoded and Pioneer "protocol" as built in an upgrade.

[The Robman]

To build on John's reply, the "Pioneer 3DEV" executor lets you combine up to three different device codes, plus it lets you format 2-part signals where the device codes are the same in each part, but the OBCs are different. The 3DEV exec is the official UEI exec and it has limitations, there are certain OBC combinations that it can't handle.

I wrote the "Pioneer 4DEV" exec. It works in a very similar manner to the 3DEV exec, except that it lets you combine up to 4 device codes and every OBC combination works. Even though the hex code generated will be different, the data that you input into KM is the same, so you should be able to just change the selected protocol from 4DEV to 3DEV and it should still work (except for the buttons listed earlier).

If that's exactly what you did and it still doesn't work, you should learn some of the buttons that you're trying to replicate and make a note of what device codes and OBCs they use. If a learned signal translates into 2 entries, you first step should be to verify that each entry uses the same device code. Then make a note of what the device code is and what each of the two OBCs are. Then go back to KM and verify that the entry for the function in question points to the right device code and uses the correct pair of OBCs.

If you can't make sense of any of that, just post a copy of an IR file that contains both the learned signals and the upgrade that you tried testing.

[johnsfine]

If you can't make sense of any of that, just post a copy of an IR file that contains both the learned signals and the upgrade that you tried testing.

Learned signals and an upgrade together in the same device mode of the same .ir file is at best a way to misunderstand your test results, and sometimes worse than that.

To understand the problem, we probably should see both the learned signal and the upgrade in .ir file(s). But we want the .ir file with the upgrade to match what was actually tested and we don't want the device mode in which the upgrade was tested to include learned signals.

So, choose whichever you find more understandable between:
One .ir file with an upgrade in one device mode and learned signals in another.
or
Two .ir files.

[floyd1977]

I'll retrace my steps when I get home from work. When I convert the upgrade from DEV4 to DEV3, I'll check the OBCs & device codes. If they match up to the learned signals, and they still don't work, I'll post an IR file.

Thanks again!