Pioneer lesson required (or why doesn't 3DEV meet my needs?)

[Capn Trips]

I'm providing no links, but if one does a forum search for "Pioneer"_AND_"3DEV"_AND_"4DEV" one finds a few strings on the topic of Pioneer 3DEV's limitations.

My understanding is that the Pioneer 3DEV executor, although seemingly correct for my situation (AWESOME new Pioneer VSX 2016 Receiver!), is ... inadequate. All of my signals are EITHER single or double byte Dev 164 (the Tuner functions), OR single or double byte Dev 165(the Receiver functions). I note that the Pioneer Master file uses the Pioneer 4DEV executor. When I switch to Pioneer 3DEV - which according to the protocol Help file SHOULD work - KM (and RM) vomits up error messages (as mentioned but not explained in the various posts in the threads I found.)

My question is WHY?!?!? The Pioneer 3DEV is built in, but if I have to use the 4DEV, then I have to use that HUGE protocol upgrade! Why are certain OBC combinations unavailable with the 3DEV executor, and is there another option, like somebody writing a smaller 4DEV or even 3DEV replacement executor?

That protocol upgrade is REALLY cramping my style!

P.S. see my OTHER post for some updates to the Pioneer Master File.

[Mark Pierson]

I note that the Pioneer Master file uses the Pioneer 4DEV executor. When I switch to Pioneer 3DEV - which according to the protocol Help file SHOULD work - KM (and RM) vomits up error messages (as mentioned but not explained in the various posts in the threads I found.)

My question is WHY?!?!?

I just opened the master file, changed the remote to the 8910 (yours, correct?), and selected Pioneer 3DEV. Guess what? No errors here. Without any changes to anything else (functions or buttons), here's the upgrade:

Upgrade Code 0 = A3 FF (Tuner/1023) Pioneer Receiver (KM v9.07)
6A 00 FE FE F7 C5 A5 25 E2 40 B0 40 70 40 F0 40
08 40 88 40 68 40 E8 40 32 40 F2 40 50 40 D0 40
48 40 08 20 88 20 38 40 CB 5F 01 40 81 40 C1 40
41 40 21 40 C2 20 AA 40 90 57 79 80 F9 80 D9 80
59 80 19 80 39 80 B9 80
KeyMoves
14 F4 A3 FF 02 40«RCVR DSP» ¦30 F4 A3 FF 12 40
«RCVR Sleep»¦37 F4 A3 FF 90 57«RCVR exit (return
)»
End

[Mark Pierson]

KM vomits up error messages (as mentioned but not explained in the various posts in the threads I found.)

Wait... now I see them (I think). There's a handful of RCVR functions that show ERROR on the Functions sheet.

I'm not sure why yet, but I think it has something to do with the EFC5 stuff, so Mike might need to look into it.

[The Robman]

The 3Dev version is a UEI executor whereas I wrote the 4Dev version.

This executor attempts to let you combine Pioneer signals that use up to 3 different device codes where some of the signals use the simple 1-part format and some use the more complicated 2-part format, and it wants to do all this with just two bytes of variable information.

All 8-bits of the first variable byte is the main OBC.
Two bits from the second variable byte are used to select which device code is used.
One bit from the second variable byte is used to select the 1-part or 2-part format.
That only leaves 5 bits in which to put the 2nd OBC when it's needed.

In the early days, Pioneer used a formula for the 2nd OBC where one of the bits was always the same as in the 1st OBC and another bit was always the complement. This, combined with the fact that one of the bits is always zero, meant that UEI could use just 5 bits to store the 2nd OBC (as they would generate the remaining 3 bits). This worked fine until Pioneer stopped following their own rules for the 2nd OBC, which is why some functions don't work for you when you use the 3Dev executor.

I took a much simpler approach for my 4Dev executor. I store the complete 2nd OBC in the 2nd variable byte. Then, the fact that one of the bits in Pioneer OBCs is always zero means that I have two spare bits that I can play with, so I combine these 2 bits and use them as the index that selects which device code to use. (I reset the bits to zero before I actually send the signal). Therefore, with my executor, you can send any combination of OBCs you like, but you will always need to load a protocol upgrade.

If space is an issue, you can use the 3Dev executor for your upgrade and just program the buttons that work. For the left over buttons, you can create a smaller upgrade that uses the Pioneer 2CMD executor and use keymoves to assign the functions to buttons.

[Capn Trips]

Precisely.

edit: the "precisely" was a response to Mark, but Rob snuck in with his explanation before me.

So, Rob, UEI doesn't get its executors from the developers, like Pioneer? They make their own and basically make a best guess to replicate them? Sheesh! What a way to run a railroad. I'll have to give your suggestion a try when I can find a bit of time.

[The Robman]

Wait... now I see them (I think). There's a handful of RCVR functions that show ERROR on the Functions sheet.

Just FYI, that ERROR display is not an error, KM is supposed to display ERROR when you enter an OBC combination that the 3DEV executor can't handle.

[Mark Pierson]

KM is supposed to display ERROR when you enter an OBC combination that the 3DEV executor can't handle.

That's why we keep you around here, Rob!

I suppose I ought to apologize to Mike too since I implied his recent changes might be at fault.

You know how that goes: "Problems? Let's blame Mikey!"

[mr_d_p_gumby]

You know how that goes: "Problems? Let's blame Mikey!"

Mikey likes it!!

[The Robman]

So, Rob, UEI doesn't get its executors from the developers, like Pioneer? They make their own and basically make a best guess to replicate them? Sheesh! What a way to run a railroad. I'll have to give your suggestion a try when I can find a bit of time.

They sometimes get specs from the OEM, but more often than not they don't, either way they still get to write the executors themselves. I've tried to get them to adopt my 4dev version, and I have supporters over there, but so far it hasn't come to pass.