JP1 Remotes

[gfb107]

I'm trying to add support for the Pioneer MIC protocol to RM.
I've figured out how all the device parms get encoded in the fixed data, and the cmd parms get encoded in the hex cmd.

Now I want to make the user interface better.
In KM, byte2 is described as "dev#", and the notes tell the user to use the values:
0 = single cmd, using device 1
1 = device 1 with cmd1
2 = ??? apparently not valid ???
3 = device 1 with cmd2

KM doesn't restrict the value entered by the user, so the user can specify 2 or 4 or even FF.

I would like to present the user with a combo box that will be meaningful and help in making the correct choice.

Does it make more sense to present this as 2 fields?
First would be Style. with values "single" and "double"
Next would be "2nd Cmd", which would be disabled if Style is "single"
Cmd would present the user with the values entered for cmd1 and cmd2 in the device parameters.

Does this make sense, or am I making it too different from KM?
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[johnsfine]

I'm not sure of the details of that particular version of Pioneer, but the decoder currently presents any compound Pioneer signal as two signals, so I think the clearest UI would be four columns:

Prefix device
Prefix OBC
device
OBC

Probably the first three would be pull down fields, and maybe they would all interconnect (changing one would change the others).

Maybe prefix device is just a choice between one value from the setup page and the word "none".

Prefix OBC would be "none" if and only if prefix device is none.

I think the above design is clearer to beginners. Another advantage is that it could make conversions between Pioneer protocols easier (after the user has set up an upgrade with the wrong Pioneer protocol and needs to switch).

[johnsfine]

I looked at Pioneer DVD in protocols.ini and at Pioneer Mix in keymap-master-protocols.txt, so I can firm up some details in my above proposal.

The two protocols are related enough that they should be set up with the same names for their function columns. If the existing names aren't best, then whatever new names are chosen should be used for all protocols to which they apply. Pioneer DVD has
Prefix Dev
Prefix Cmd
Device
OBC.

They should be pull-downs. If I understand that txt file correctly:

Device should be either the dev1 or dev2 value.
Prefix Dev is either none or dev1.
Those two choices are locked together, so you really have just none:1 or 1:2. You can't get none:2 or 1:1.

Prefix Cmd is none, cmd1, or cmd2. It should be half locked to the preceeding choice, so it is "none" if and only if Prefix Dev is none.

In Pioneer DVD, the choice if OBC also interacts with the three pull down choices. In Pioneer Mix I believe the choice of OBC is independent of the pull down choices.

I believe all the locking of column behaviors together can occur indirectly through the portion of the hex cmd which they share. It shouldn't require special code to coordinate.

[jon_armstrong]

I just recently figured out a few more details about how $0073 works. I think I documented it pretty well at the bottom of this thread:

http://www.hifi-remote.com/forums/viewtopic.php?t=437

But while it is fresh in my mind, I can be helpful but while I understand the general concepts of the protocol.ini file, this protocol is sufficiently complex I probably can't get it right.
_________________
-Jon

[The Robman]

First off, let me shed some light on the background of these two protocols, as they are essentially the same protocol.

When the $007E executor was originally implemented by UEI, it was just designed to handle Pioneer DVD players. The executor code would test one of the bits in the OBC to determine whether to send the 1-part version or the 2-part version.

Three fixed bytes where required:
device1
command1
device2

When the 1-part signal was used, device1 would be the device code and the variable byte would be the OBC.

When the 2-part signal was used, device1 and command1 would be used for the first part and device2 and the OBC would be used for the second part.

Then somewhere along the line, Pioneer started putting out televisions that used a similar format but didn't follow the same rules as before regarding when to send the 1 or 2 part versions. So, rather than create a new executor, UEI decided to make a new version of $007E that would handle all situations. Unfortunately, this meant that the DVD/0525 and DVD/0571 setup codes became 2-byte codes.

So in KM I decided to handle these seperately and created the "DVD" and "MIX" versions of this executor. I also created the "DVD2" version at this time.

"DVD2" is designed for people who have remotes with the 2-byte version of $007E installed, it uses the 2-byte protocol but allows the user to enter the old fashioned OBCs or EFCs. KM will then test the bit in the OBC itself and decide when to format the 1-byte or 2-byte versions of the signal. This option was implemented to allow the user to decide if they wanted to implement a protocol upgrade or not. If this user were to select "Pioneer DVD" (not DVD2), KM would detect that their remote has the newer 2-byte version of $007E and would therefore offer them a protocol upgrade.

If the user has an older remote that has the 1-byte version of $007E installed and they select DVD2, KM would tell them that the protocol is not available. This was deliberate because these users should not be using DVD2, they should be using the DVD version.

Now for the MIX version. The fixed data here is as follows:
device1
command1
device2
command2

device1 = the device code found in both the single-style signals and the first half of the double-style signals.

device2 = the device code found in the second half of the double-style signals.

cmd1 = the OBC command code used in the first half of most of the double-style signals.

cmd2 = the OBC command code used in the rest of the double-style signals (if present)

Then on the Functions sheet, you indicate which style of signal to use for each function. Do this by entering one of the following values in the byte2 column:

0 = single-style signal (using device code 1)
1 = double-style signal (using dev1/cmd1 in the first half)
3 = double-style signal (using dev1/cmd2 in the first half)

Also, just FYI, if KM offers up the old version of $007E to a user who's remote has the new version installed (ie, for "Pioneer DVD"), a new protocol id of $017E is used, and if KM offers up the new version to a user who's remote has the old version (ie, for "Pioneer MIX"), a new protocol id of $017F is used. This is so that they can still create upgrades with the other version if needed.

Does that help you decide how to implement it?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[gfb107]

An addtional concern when designing the RM UI is the importing of existing KM upgrades.

To date, we haven't considered this at all. In this case, KM uses only the "byte2" column to store this information. ov is not used at all.

If successful importing is important, maybe the best solution would be a single column, entitled "Prefix Dev and Cmd"
which would be a drop-down box with the following values:
"none" which would be the 0 value
"Device 1 w/ Cmd1" which would be the 1 value
"Device 1 w/ Cmd2" which would be the 3 value

Of course we could choose other text for the title and values, but in order to import there must only be one column (in addition to EFC and OBC).

I've updated the protocols.ini command parameter parser to allow omitting a choice in the list the choices (to skip over the 2), so this could be coded as:

CmdParms=Prefix Dev and Cmd:none|Device 1 w/ Cmd1||Device 1 w/ Cmd2,OBC=0

A ParmInitializer could be used to fill in the that actual values of dev1, cmd1, and cmd2.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[johnsfine]

[gfb107]

OK, I'll work on adding an optional ImportTranslator= entry to protocols.ini. If one isn't specified, it will use the CmdTranslator= entry.

Now, back to your proposal for Pioneer MIX:

For the Device Parameters we have:
Device 1
Device 2
Command 1
Command 2

For the Command Parameters we have:
Prefix Device
Prefix Command
Device
OBC

Prefix Device: may take the value "none" or the value of Device 1.
Prefix Command: may take the value "none", the value of Command 1, or the value of Command 2. If Prefix Device is "none", Prefix Command must be "none" as well.
Device: this doesn't seem to have any use, as there isn't anyplace to encode it in the hex cmd, unless it is somehow encoded in the OBC, as it is in Pioneer DVD.
OBC: the OBC for the function.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[johnsfine]

[The Robman]

[gfb107]

I've got it working as described. Look for it in the next release.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)