Alternate PID (

[3FG]

Graham,
Perhaps I don't understand the purpose of the Alternate PID feature. I think it is useful when the user opens an rmdu/km file which has a PID which is the same as a built-in PID, and the user will need to use both executors in upgrades. Or, I suppose that a similar message is given if the user tries to define 2 executors in upgrades which each have the same PID. FOr these situations, the Alternate PID feature is highly useful.

In this case, there is little chance that Bev will want to use the built-in 0184 executor with the newer 0184 upgrade executor loaded. So there seems to be little cost to ignoring the message, and that allows him to sidestep the question: "What alternate PID should I use?"

In any event, I believe the better course of action is to use the built in 0058 executor--it saves space, and of course there is no PID conflict.

[vickyg2003]

Okay, Dave broke the barrier. Beverly is one of those unisex names and I've often wondered if Bev is male or female, especially Bev Howard, who has the same programming background and a JP1 interest as I have.

So Bev, did Dave guess right?

[bevhoward]

>> the better course of action is to use the built in 0058 executor <<

Just when I think I I am making progress, someone succeeds in completely mystifying me with new information ;-)

>> Alternate PID <<

While I am glad to have started this thread and have learned more than I expected, I have to confess that the rmdu dissolved the conflict when I got to the point of being able to test all of the (highly anticipated) additional commands on our Philips 46pfl7505d TV

All of the RC6 commands worked with the 46pfl7505d but none of the RC5 commands worked... sigh... I was _really_ looking forward to having a discrete ON command.

(the rmdu was specifically for the Philips 47PFL7422D LCD and I erroneously stated that was our model number)

>> So Bev, did Dave guess right? <<

Sometimes I really have fun with this name ;-) see http://BevHoward.com ...I'm the one on the left.

Beverly Howard

(fwiw, I'm starting a new thread with a couple of questions not related to alt pid.)

[vickyg2003]

>> So Bev, did Dave guess right? <<

Sometimes I really have fun with this name see http://BevHoward.com ...I'm the one on the left.

Beverly Howard

I thought so!

[rsbrux]

I am facing the same problem originally reported here. I am trying to add a DU for my new Yamaha RX-V685 receiver to my existing URC-8603 (Xsight Touch) remote. The Yamaha DUs I have found here use the protocol "NEC 4 DEV Yamaha Combo" which already has the PID 011A in RM. However, as soon as I choose this protocol in RM together with the remote "URC-8603 Xsight Touch", I get the warning about the PID conflicting with a built-in protocol. I have tried several "Alternate PIDs", such as 01A0, 01FE, etc. but the warning persists. I have also reviewed the following:
http://www.hifi-remote.com/forums/viewtopic.php?t=16680
http://www.hifi-remote.com/forums/viewt ... p?p=127522
http://www.hifi-remote.com/forums/viewtopic.php?p=99826
but find myself none the wiser.
Could the conflict be responsible for the problem I encountered trying to download learned codes from my remote (see Raw Download from URC-8603)?
What (if anything) should I do?

[mathdon]

The warning is correct, but perhaps misleading. It isn't saying that the alternate PID you have given is not a valid one, it is saying that you need to give one. You do need to do so, and you have done so. If the alternate PID you enter is NOT valid, then it will appear in RED with a red message underneath, such as "Conflicts with built-in protocol". Try entering 011B as an alternate PID and you will get this message. So if the PID you have entered remains in BLACK, it has been accepted and you can continue.

You should find your first choice of 01A0 works. If this doesn't work for you, upload your setup as a .rmir file and the upgrade you are trying to use as a .rmdu file to the Diagnosis Area for me to look at.