Alternate PIDs in RM

[gfb107]

I've known for a while that one (actually two) things that KM does that RM doesn't do is support alternate PIDs.

Based on information from Mike England, there are 2 different mechanisms for using alternate PIDs.

1. If a protocol upgrade is required, use the alternate PID. If a protocol upgrade is not required (the protocol is built into the remote), use the normal PID.

2. If a protocol upgrade is required, and the remote has a builtin protocol with the same PID, but it is a different variant, use the alternate PID. If the remote does not have a protocol with the same PID builtin, use the normal PID. This mechanism is apparantly used for the Sony Combo protocols.

Are both of these mechanisms really needed? I'd like to implement one or the other, or is there something here I am missing?

[johnsfine]

I don't understand the intent of those features, and maybe they are compensating for some limits KM might have that RM doesn't (sorry I don't know KM very well at this point).

RM does a decent job of supporting the same protocol name with different PIDs and selecting the right one of those based on model of remote. That often requires duplication of content within protocols.ini, for trivial differences, possibly for only the PID differing. It would be nice to have some inheritance screme for protocols.ini entries (entry X is just like entry Y except...) But I'm not sure about the cost/value balance of that. I think there are still some improvements deserved in the mechanism of switching between protocols.ini entries when required by model changes, but I've totally lost track of the details of that issue.

Anyway, I don't have any understanding of any need for automatic alternate PIDs that aren't logically part of the above described system.

I can see some expert need for manual alternate PIDs, but I assume that is an entirely different question.

[The Robman]

#1 is invalid. KM uses alternate PIDs when there is already a built in protocol of the same name that has other valid uses. The prime example of this, and the reason I wrote this code in the first place, is the $007E protocol.

Older remotes have the 1-byte version of this, which KM supports as "Pioneer DVD". Newer remotes have the 2-byte version of this, which KM supports as "Pioneer MIX". There are valid reasons why a user might want to use both of these.

For example, a 15-1994 user might already have created an upgrade for his Pioneer DVD player using the built in $007E protocol and now he wants to add an upgrade for his Pioneer TV which requires the MIX version. He would need a protocol upgrade to support the MIX version. If KM were to call this upgrade $007E, the user would be forced to re-built his 1-byte DVD upgrade using 2-byte variable data, and KM/RM would have to have some way of knowing that he has that upgrade installed in the first place in order to tell him to re-work it.

As that's obviously impossible, my solution was to use alternate PIDs. If a 15-1994 user selects "Pioneer DVD", no protocol upgrade is required and the device upgrade will use $007E. If that same user selects "Pioneer MIX", a protocol upgrade is supplied using an alternate PID.

If a 15-2104 user were to do make the same selections, a protocol upgrade would be supplied for "Pioneer DVD" using an alternate PID. No protocol upgrade would be required for "Pioneer MIX" and the device upgrade would use $007E.

Here's some addition info on this topic...
http://www.hifi-remote.com/forums/viewtopic.php?t=1594
http://www.hifi-remote.com/forums/viewtopic.php?t=1250

[gfb107]

Rob,

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

It seems to me KM doesn't really care if a different executor with the same PID is built into the remote. It simply checks to see if the desired executor is builtin. If it is, no protocol upgrade is required and the "normal" PID is used. If the desired executor is NOT builtin, a protocol upgrade is required and the alternate PID is used.

This seems to me to be what I described as #1, but you said that is invalid.

Here's where I am headed:

An entry will be added protocols.ini allowing us to define the desired alternate PID. The protocols.ini entry name will be AlternatePID. The alternate PID will be used when:

1. The protocol has an alternate PID defined
2. The protocol is NOT built into the remote

For example:

Code: Select all

[Pioneer DVD]
PID=00 7E
AlternatePID=01 7E
...

[Pioneer MIX]
PID=00 7E
AlternatePID=01 7F
...

As as aside, it looks to me that we need to give the various different flavors if 00 7E variant names, so that RM can tell which one is installed in a given remote. As it stands now, both the 1994 and 2104 RDFs include 00 7E in the protocols section, but RM can't tell which one. Based on the above, the version in the 1994 is the "DVD" variant, while the version in the 2104 is the "MIX" variant.

[The Robman]

I misunderstood what you meant by #1, but based on your most recent post I can tell you're headed in the right direction. You do indeed need to know which version of each of the relevant executors is installed in a given remote, I'll PM you with additional info on that.

It seems to me KM doesn't really care if a different executor with the same PID is built into the remote. It simply checks to see if the desired executor is built in. If it is, no protocol upgrade is required and the "normal" PID is used. If the desired executor is NOT builtin, a protocol upgrade is required and the alternate PID is used.

I'm not really sure what you mean by "a different executor with the same PID". Unless we're accidentally re-using an official PID for a hacked protocol, if the executor has the same PID, it's the same executor, or at least a version of the same executor.

Keep in mind that sometimes there can be several different versions of a specific executor floating around the various remotes in circulation, as is the case with the Dish Network executor (formerly known as "Dishplayer (Old)"). In KM we number these versions starting with 1 for the oldest. Then, depending on which protocol was selected and what other parameters might be set, KM might say that it needs at least version 3 of the protocol, so if the user's remote has version 1 or 2, a protocol upgrade is needed, but if he has 3 or 4, we can use the built in.

[johnsfine]

I'm not really sure what you mean by "a different executor with the same PID". Unless we're accidentally re-using an official PID for a hacked protocol, if the executor has the same PID, it's the same executor, or at least a version of the same executor.

I assume he meant a different executor-version with the same PID. For most purposes in RM, a different executor-version is as different as a different executor.

We have a variant field for PIDs in the list in each RDF. To take the above example, if 007E in the 15-1994 should not have identical treatment by RM as 007E in the 2104, then (at least) one of them should have a variant indicated in the RDF. I put a lot of variant info into the RDF's but I probably was scared away by my relative lack of understanding of Pioneer variants.

Keep in mind that sometimes there can be several different versions of a specific executor floating around the various remotes in circulation, as is the case with the Dish Network executor (formerly known as "Dishplayer (Old)"). In KM we number these versions starting with 1 for the oldest.

Since I didn't know KM's numbering system, I gave variants various short names, when I edited the RDF files to be variant aware. I arbitrarily selected one version to be the "standard" (non variant) variant. The others are named by some size or feature to remind me about the most important difference between them and standard.

It would be great if someone else who understands the variant issues (I think that's mainly you) reviewed what I did in variants in RDF files.

Then, depending on which protocol was selected and what other parameters might be set, KM might say that it needs at least version 3 of the protocol, so if the user's remote has version 1 or 2, a protocol upgrade is needed, but if he has 3 or 4, we can use the built in.

I think RM already does a decent job of deciding whether a variant already in the remote will handle the upgrade and using the right one if so and the right upgrade protocol variant if not.

The question at hand seems to be what to do when the variant in the remote is not good enough for the current device upgrade, but isn't total crap (as some variants are) so it is good enough for some other device upgrade the same user MIGHT have built and thus PID collisions are possible.

In a few cases I tried to warn the user away from possible PID collisions in the Notes that RM will display for a specific protocols.ini entry. With just a little extra data passed from RM/KM to IR, it would be possible for IR to detect and automatically fix ALL PID collisions. I see how the alternate PID idea in KM can eliminate the most likely PID collisions, so maybe that's enough.

[Mark Pierson]

FYI... the original Repl PID that Rob had in KM has been replaced (by Mike England) with a (hopefully) more robust mechanism that, combined with a protocol "versioning" scheme, ends up with the same net results as the old method. The current protocols handled this way are:

Dish Network Combo
Panasonic MIX Combo
Pioneer DVD, DVD2, and MIX
Sony Combo (12/20), and (12/15/20)

[The Robman]

The question at hand seems to be what to do when the variant in the remote is not good enough for the current device upgrade, but isn't total crap (as some variants are) so it is good enough for some other device upgrade the same user MIGHT have built and thus PID collisions are possible.

Exactly, this is why we came up with the alternate PIDs.

If there are, let's say, 4 different versions of a protocol floating around, and 2 are good and 2 are bad for the selected protocol, can RM handle this? In other words, does RM work on a one-to-one basis with protocols or can it handle a one-to-many situation?

[johnsfine]

RM could handle the serious cases, if you put enough protocol entries in the .ini file. You just avoid providing code for the variants that shouldn't be upgrades under their own PID and duplicate those variants as other ini file entries with a diffent PID and with code.

That would lead to cases where an alternate PID is used when the remote has no variant at all of the right PID, which is slightly inferior to what KM does, but not seriously wrong.

Anyway, it would expand the number of ini file entries, so it would be cleaner to just support alternate PIDs as described here.

Of course it would be even better if IR resolved all PID collisions.

[gfb107]

That would lead to cases where an alternate PID is used when the remote has no variant at all of the right PID, which is slightly inferior to what KM does, but not seriously wrong.

Actually, this is exactly what KM does, or at least did until recently, as you can see in http://www.hifi-remote.com/forums/viewtopic.php?t=1594

[The Robman]

That would lead to cases where an alternate PID is used when the remote has no variant at all of the right PID, which is slightly inferior to what KM does, but not seriously wrong.

Actually, you want to use the alternate PID even when the remote doesn't have any version of the protocol, just in case the user tries to add both versions. For example, let's say that the remote in question lacks the $007E protocol and the user creates an upgrade for their Pioneer DVD. They then later come along and create an upgrade for their Pioneer TV, using Pioneer MIX. You would now have 2 $007E protocol upgrades if the alternate PIDs are not used.

Of course it would be even better if IR resolved all PID collisions.

I would agree with this if we were talking about a single program that handles both the IR and KM/RM functions, but as long as they are seperate programs I disagree that IR should handle the clashes.

[mr_d_p_gumby]

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.

Actually, you want to use the alternate PID even when the remote doesn't have any version of the protocol, just in case the user tries to add both versions. For example, let's say that the remote in question lacks the $007E protocol and the user creates an upgrade for their Pioneer DVD. They then later come along and create an upgrade for their Pioneer TV, using Pioneer MIX. You would now have 2 $007E protocol upgrades if the alternate PIDs are not used.

I agree in the case of the Pioneer $007E, and this is what the #1 method accomplishes in KM now. But if you take the case of the $0027 Sony Combo variants, you would not want to encourage users to use the older "total crap" version. Unfortunately, the older version is built into many current remotes, so it's very likely that you'd have a collision if you used the standard PID in all cases. This is what the #2 method is for. It tries to use the standard PID in all cases except when a conflicting version is built into the remote.

Since I didn't know KM's numbering system, I gave variants various short names, when I edited the RDF files to be variant aware. I arbitrarily selected one version to be the "standard" (non variant) variant. The others are named by some size or feature to remind me about the most important difference between them and standard.

KM's numbering system is just as arbitrary as your variant naming system, so there's no real need to make the two agree in terms of which variant is named what. If anything, your variant names tend to contain a clue as to what the differences are, whereas KM's system is just a sequential numbering of the variants as they are discovered.

It would be great if someone else who understands the variant issues (I think that's mainly you) reviewed what I did in variants in RDF files.

I'm currently in the process of doing just that. Hopefully I'll be able to give Nils the required RDF changes/additions as soon as time permits me to finish up going through all the RDFs.

[The Robman]

KM's numbering system is just as arbitrary as your variant naming system, so there's no real need to make the two agree in terms of which variant is named what. If anything, your variant names tend to contain a clue as to what the differences are, whereas KM's system is just a sequential numbering of the variants as they are discovered.

They're not numbered based on the order in which they were discovered they're numbered based on the order in which they were created by UEI. The point being that UEI usually adds features as they go, rather than take them away. Take the case of the Dish Network protocol, first they re-org'd the device, unit and command codes into seperate byte, then they added the mini-combo logic, then they added the alternate frequency logic. So, if you need the mini-combo code, you need at least version 3, but if you need the alternate wavelength code, you need at least version 4. If you just need a standard single device upgrade, you can go as far back as version 1.

Another factor in deciding whether alt-PIDs are needed is whether this is a single device upgrade or not. For the Pioneer and Sony protocols, these can obviously be used by several devices, but the Dish Network protocol is most likely a single device protocol, so in my opinion, alt-PIDs are not needed here.

[mr_d_p_gumby]

They're not numbered based on the order in which they were discovered they're numbered based on the order in which they were created by UEI.

Sorry, didn't mean to imply there was no meaning to the KM numbering scheme...

You are right, I probably should have used the word created instead of discovered since that is the intent. It's just lucky for us that so far nobody has discovered a version of a protocol in one of the older 6805 remotes that is older than what we call "version 1".

[The Robman]

That's what ZERO was invented for!