Alternate PIDs in RM

gfb107 · Post by **gfb107** » Mon May 17, 2004 4:16 pm

mr_d_p_gumby wrote:
gfb107 wrote:In the thread http://www.hifi-remote.com/forums/viewtopic.php?t=1594 you wrote:
For the Pioneer one, if the "DVD" version is selected and a protocol upgrade is required, $017E is used. If the "MIX" version is selected and an upgrade is required, $017F is used
That has changed slightly due to my revisions to newer versions of KM. The $017F PID is no longer used; $017E is used in all cases where an alternate PID is required.

If I use the new KM scheme for alternate PIDs, RM won't be able to succesfully imprt KM upgrades that use PID $017F.
Also, what happens if a user needs both protocols? Or is this unlikely simply because they are just different versions of the same protocol, and the "MIX" version will work for the "DVD" upgrade?

Post by **The Robman** » Mon May 17, 2004 5:10 pm

A user might well want both versions if they have a Pioneer DVD and TV and are using a remote without any version of $007E installed. In this case, with the new KM handling, they would need to edit one of the PIDs by hand.

Mark Pierson · Post by **Mark Pierson** » Mon May 17, 2004 5:12 pm

gfb107 wrote:RM won't be able to succesfully imprt KM upgrades that use PID $017F

I'm probably confused, but doesn't RM has provisions to look at the protocol name in addition to the PID?

mr_d_p_gumby · Post by **mr_d_p_gumby** » Mon May 17, 2004 6:55 pm

The Robman wrote:A user might well want both versions if they have a Pioneer DVD and TV and are using a remote without any version of $007E installed. In this case, with the new KM handling, they would need to edit one of the PIDs by hand.

If you look very carefully, you'll see that the protocol code output by older KM versions for the $017E and $017F cases is identical. They are, in fact, the exact same protocol code, so there is no conflict in using the same pid, regardless of whether the $007E pid is present or not. The main difference between the DVD & MIX versions is how KM chooses to present the options for creating an upgrade.

Post by **The Robman** » Mon May 17, 2004 7:20 pm

mr_d_p_gumby wrote:
The Robman wrote:A user might well want both versions if they have a Pioneer DVD and TV and are using a remote without any version of $007E installed. In this case, with the new KM handling, they would need to edit one of the PIDs by hand.
If you look very carefully, you'll see that the protocol code output by older KM versions for the $017E and $017F cases is identical. They are, in fact, the exact same protocol code, so there is no conflict in using the same pid, regardless of whether the $007E pid is present or not. The main difference between the DVD & MIX versions is how KM chooses to present the options for creating an upgrade.

If that's true then something's changed and I haven't noticed so I guess it's time to go back and check.

Just for the record, the DVD protocol is a 1-byte protocol that uses one of the bits in the OBC to decide whether to generate the 2-part or 1-part signal. The MIX protocol is a 2-byte protocol where the user gets to decide when to generate a 1 or 2 part signal.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Mon May 17, 2004 10:46 pm

mr_d_p_gumby (in haste making typo :oops: ) wrote:DVD & MIX

That should have been DVD2 & MIX... This sure can get confusing!

As of KM v8.18 & subsequent versions:

version 1 (007E:1, UpgradePID=017E) is Pioneer DVD (1-byte)
version 2 (007E:2, AltPID=017F) is Pioneer DVD2 (2-byte)
version 2 (007E:2, UpgradePID=017F) is Pioneer MIX (2-byte)

In KM v8.17 & prior versions:

version 1 (007E:1, UpgradePID=017E) is Pioneer DVD (1-byte)
version 2 (007E:2, UpgradePID=017D) is Pioneer DVD2 (2-byte) (see note)
version 2 (007E:2, UpgradePID=017F) is Pioneer MIX (2-byte)

Where:
UpgradePID means that the PID is always used for an upgrade
AltPID means the PID is only used if there is a version conflict with a built-in 007E

Also, to further confuse matters, there is a version 3 (007E:3) which KM will use if built-in in place of version 2, though it is not known if this works. So far, it is only in the URC-9960 & Atlas remotes.

Note that in KM v8.17, DVD2 (017D) was not allowed to provide an upgrade protocol, so you'd never find a legitimate KM file with PID 017D. My previous comment was incorrect; it is the 017D PID that was eliminated from KM v 8.18. Hope this sets the record straight.

Post by **The Robman** » Tue May 18, 2004 6:33 am

OK, that's a bit better!

I assume "UpgradePID means that the PID is always used for an upgrade" should really read "UpgradePID means that the PID is always used for a protocol upgrade".

As for the DVD2 version. It was very deliberate on my part to not allow a protocol upgrade for this selection. If you don't have the DVD2 version of 7E installed, you should be using the DVD version. The only exception I can see to this is where the user doesn't have any version of 7E installed at all and they have already installed an upgrade using the MIX protocol. In that case, they may chose to use DVD2 to save having to have 2 protocol upgrades.

Therefore, I would suggest that DVD2 still not be allowed to provide a protocol upgrade, but when KM detects that one would be required, it should use the 017F id.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Tue May 18, 2004 11:01 am

The Robman wrote:I assume "UpgradePID means that the PID is always used for an upgrade" should really read "UpgradePID means that the PID is always used for a protocol upgrade".

Yes.

Just to further clarify things, here is a truth table showing what KM v8.18 does for the Pioneer DVD/DVD2/MIX protocols (* = upgrade protocol):

Code: Select all

Built-in:            007E:1   007E:2   007E:3   NONE
                     ------   ------   ------   ------
007E:1 DVD upgrade   007E    *017E    *017E    *017E
007E:2 DVD2 upgrade  N/A      007E     007E    *017F
007E:2 MIX upgrade  *017F     007E     007E    *017F

Given the proposal I made to Greg for RM to use UpgradePID and AltPID in protocols.ini, here is what RM would do:

Code: Select all

Built-in:            007E:1   007E:2   007E:3   NONE
                     ------   ------   ------   ------
007E:1 DVD upgrade   007E    *017E    *017E    *017E
007E:2 DVD2 upgrade *017F     007E     007E    *017F
007E:2 MIX upgrade  *017F     007E     007E    *017F

Note that the only difference is that RM would provide a non-conflicting 017F upgrade for DVD2 when 007E:1 is built-in.

While we're discussing these alternate PID scenarios, I should probably mention here what KM does with the other two similar cases.

First, the Sony Combo (12/20) & Sony Combo (12/15/20):

Code: Select all

Built-in:            0027:old   0027E:new   NONE
                     --------   ---------   ---------
0027:old upgrade     0027      *0127       *0027 
0027:new upgrade    *0127       0027       *0027

There is a conflict in the NONE case for these protocols, but it is unlikely that anyone would choose to use the 0027:old version if it were not built-in. However, we could change the 0027:old version to UpgradePID=0127 to resolve the conflict if needed.

The other case is Panasonic VCR Combo & Panasonic MIX Combo:

Code: Select all

Built-in:            001F:1   001F:2   NONE
                     ------   ------   ------
001F:1 VCR upgrade   001F     001F    *001F
001F:2 MIX upgrade  *011F     001F    *011F

Post by **The Robman** » Tue May 18, 2004 12:13 pm

OK, I just checked KM to verify what was happening and I have a problem with KM offering up a protocol upgrade for DVD2 for remotes that don't have any version of 7E installed (like the URC-4080). In this situation, the user should be using the DVD protocol as the device upgrade will be about half the size, and it will support advanced codes. Even though a protocol upgrade is not offered, I would like the generated device upgrade to use the MIX protocol id.

The only situation where a user with a remote like the URC-4080 might want to use the DVD2 protocol is when they have already loaded upgrades that use the MIX protocol. In this situation they won't need a fresh copy of the protocol code as they would already have it loaded.

gfb107 · Post by **gfb107** » Wed May 19, 2004 7:18 pm

I want to get this done tonight or tomorrow, so I just want to make sure we're all on the same page.

Here's what I'm planning to do:

Add support for AlternatePID in protocols.ini. When a protocol has an alternate PID, it will be used when a protocol upgrade is required.
There will be no checking to see if there is some other variant of the PID built into the remote.
Pioneer DVD will use AlternatePID=01 7E. Pioneer DVD2 and Pioneer MIX will use AlternatePID=01 7F. Pioneer DVD2 is only available when built into the remote, because no upgrade code is defined.
Pioneer DVD will not be assigned a VariantName. Pioneer DVD2 will use VariantName "DVD2", and Pioneer MIX will use VariantName "MIX". There is apparently a new variant of Pioneer MIX in the URC-9960 that uses 6 fixed bytes, so it will have VariantName "MIX6"
I considered using the version numbers that KM uses for the sake of consistency, but I think that descriptive names are better.
For the Sony 12/20 Combo protocol, I'll use VariantName=old and UpgradePid=01 27. The Sony 12/15/20 Combo protocol uses VariantName=new, should the AlternatePID=01 27 also, or should it be something else (e.g. 01 28), or should it just not have an AlternatePID at all?
For Panasonic VCR Combo, I'll use no VariantName and no AlternatePID. For Panasonic MIX Combo, I'll use VariantName=MIX and AlternatePID=01 1F.

Post by **The Robman** » Wed May 19, 2004 9:15 pm

gfb107 wrote:
Pioneer DVD will use AlternatePID=01 7E. Pioneer DVD2 and Pioneer MIX will use AlternatePID=01 7F. Pioneer DVD2 is only available when built into the remote, because no upgrade code is defined.

If the user selects DVD2 when using a remote that doesn't have any version of $007E installed, I want to encourage them to use the DVD version. However, if they are installing the MIX protocol anyway for some other reason, they should be allowed to use DVD2 for their DVD player.

Given the limitations of the Excel platform, the easiest way for me to do this was to not supply a protocol upgrade, but still supply a device upgrade. With the extra flexibility that Java offers, could you come up with something that accomplishes what I described? In other words, let them create an upgrade (but no protocol upgrade), but display them some sort of informational message laying out what I described?

mr_d_p_gumby · Post by **mr_d_p_gumby** » Wed May 19, 2004 11:37 pm

gfb107 wrote:Add support for AlternatePID in protocols.ini.

Your term AlternatePID has the same meaning as the term UpgradePID I was suggesting, so we'll have to be real careful that we keep our terminology straight here!

gfb107 wrote:The Sony 12/15/20 Combo protocol uses VariantName=new, should the AlternatePID=01 27 also, or should it be something else (e.g. 0128), or should it just not have an AlternatePID at all?

This is exactly why I was suggesting two types of alternate PIDs. You would never want to provide an upgrade protocol for the Sony 12/15/20 Combo (0027:new) with an alternate PID, except in the one case where 0027:old is built into the remote.

I guess I'm having a hard time understanding what the problem is with implementing both types of alternate PID mechanisms. What would it hurt to do both? Have I not stated something clearly enough? Is the code too difficult to write? If you only implement the one you enumerated, then RM will still be in the position where it does not do something that KM does do, and I thought the goal was to encompass all the functionality of KM. It's ultimately your decision, but I just wanted to take this one last opportunity to restate my suggestion.

The Robman wrote:If the user selects DVD2 when using a remote that doesn't have any version of $007E installed, I want to encourage them to use the DVD version. However, if they are installing the MIX protocol anyway for some other reason, they should be allowed to use DVD2 for their DVD player.

Greg can easily prevent an upgrade from being provided by omitting the protocol code from DVD2 in protocols.ini, while still using the alternate PID. This would duplicate what you want KM to do. The suggestion to use DVD could be added to the Notes entry for DVD2.

gfb107 · Post by **gfb107** » Thu May 20, 2004 8:05 am

mr_d_p_gumby wrote:I guess I'm having a hard time understanding what the problem is with implementing both types of alternate PID mechanisms. What would it hurt to do both? Have I not stated something clearly enough? Is the code too difficult to write? If you only implement the one you enumerated, then RM will still be in the position where it does not do something that KM does do, and I thought the goal was to encompass all the functionality of KM. It's ultimately your decision, but I just wanted to take this one last opportunity to restate my suggestion.

It's not that I think it is particularly difficult to implement, it's just that it isn't clear to me that there is a real need for it, and it seems to me that it has the potential to create conflicts and maybe even confusion, to have a different PID for a protocol upgrade in two different remotes.

If I do implement it, I'd probably use a different syntax that you propose, something like

Code: Select all

AlternatePID=<PID>[,ConflictOnly]

Where ConflictOnly indicates that the alternate PID is used only when there is a conflict with a built-in PID.

Does anyone else have an opinion?

mr_d_p_gumby · Post by **mr_d_p_gumby** » Thu May 20, 2004 9:57 am

I'm not "anyone else", but I'll comment anyway...

gfb107 wrote:It's not that I think it is particularly difficult to implement, it's just that it isn't clear to me that there is a real need for it, and it seems to me that it has the potential to create conflicts and maybe even confusion, to have a different PID for a protocol upgrade in two different remotes.

A) There is a real need for it to support the Sony 12/20 & 12/15/20 Combos.

B) If Rob had not decided to handle it differently in this case, it would be needed for Pioneer DVD2.

C) Where there is smoke, there is fire. There are bound to be other circumstances in the future where this capability is needed. The scenario only requires that UEI create one exceedingly bad version and a revised good version. (In the Sony Combo case, the exceedingly bad version is present in a large variety of currently available remotes, so there is a fair probability that an existing upgrade using the bad version will be in use.)

D) Adding this second method creates no more potential for conflict or confusion than would be present with only the first method. I think your comment here reflects your reluctance to accept the need for any alternate PID at all. I think you're just going to have to trust that Rob knows what he is doing.

E) KM has provided alternate PID support for these special cases for a considerable period of time, and it appears it has not caused any confusion or conflict. Where are all the posts from conflicted & confused users?

F) The whole point of having alternate PIDs is to avoid conflict and confusion for users by having experts predetermine a solution to a problem.

gfb107 wrote:If I do implement it, I'd probably use a different syntax that you propose, something like
Code: Select all
AlternatePID=<PID>[,ConflictOnly]
Where ConflictOnly indicates that the alternate PID is used only when there is a conflict with a built-in PID.

I have no quarrel with that. I'm not so concerned with the syntax you choose. My UpgradePID and AltPID were only suggestions.

Another possibility for this syntax would be that the presence of any additional arguments would trigger the conflict-only response. The additional argument(s) could then be a list of conflicting variant names.

Code: Select all

AlternatePID=0127,old

Does anyone else have an opinion?

gfb107 · Post by **gfb107** » Thu May 20, 2004 8:30 pm

Alright, since no one has anything to offer, I'm going with Mike's last suggestion, which seems to provide the most flexibility.

So, here's where I'm going:

Code: Select all

AlternatePID=<pid>[,<exception list>]

Where <exception list> is a comma separated list of variant names. If the variant built into the remote is in this list, the alternate PID is NOT used. The special value none can be used to indicate that the alternate PID should NOT be used if no variant is built into the remote. If no list is specified, the alternate PID is used whenever a protocol upgrade is required.

I think this will take care of all Mike's scenarios.
The Pioneers, which are easy:

Code: Select all

Built-in:            007E:1   007E:2   007E:3   NONE 
                     ------   ------   ------   ------ 
007E:1 DVD upgrade   007E    *017E    *017E    *017E   Use AlternatePID=017E
007E:2 DVD2 upgrade  N/A      007E     007E    *017F   Use AlternatePID=017F
007E:2 MIX upgrade  *017F     007E     007E    *017F   Use AlternatePID=017F

For the Sony Combos:

Code: Select all

Built-in:            0027:old   0027E:new   NONE 
                     --------   ---------   ----- 
0027:old upgrade     0027      *0127       *0027  Use AlternatePID=0127,old,none
0027:new upgrade    *0127       0027       *0027  Use AlternatePID=0127,none

For the Panasonic:

Code: Select all

Built-in:            001F:1   001F:2   NONE 
                     ------   ------   ------ 
001F:1 VCR upgrade   001F     001F    *001F  No alternate PID used
001F:2 MIX upgrade  *011F     001F    *011F  Use AlternatePID=011F