Isn't this Nec1 4Dev Yamaha Combo a custom executor? I didn't see a custom protocol in the IR file. If I switch to RS 15-2116 it says that the protocol upgrade is not required. So apparently 011A was not a good pid to use for this custom executor. 011A is also the PID of the Nec 2Dev combo.

If the OP adds this protocol into the remote, it will probably help with the y1 codes.

the POWER button functions as the VOLUME DOWN function, and the MUTE button functions as the VOLUME UP button

I looked at the Power button in the IR file, and it doesn't appear to be mapped, so I don't know how this is working at all.

Edit: I see that PID 011A is the Nec2Dev Combo. That one has 4 fixed data, so when the upgrade is filled in, the codes will be shifted up by two, and the numbers will probably be all screwy too._________________Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

There are three issues here:
1) Chico didn't actually upload the RMDU file that he used. He just pointed us to the RMDU file that he used as a starting point, and then remapped the buttons, and removed a lot of functions. So it's difficult to see exactly what happened, although reading the IR file into RMIR allows us to see some of the changes.

2) He didn't change the remote type to match his RS 15-2116. That lead to the incorrect mapping of functions to buttons.

3) Protocols.ini has an error in the way the Yamaha 4DEV Combo is listed. The 2DEV and 4DEV NEC protocols both use 011A, and so does the Yamaha 4DEV. That's OK in itself, but the Yamaha version does not have a VariantName entry. That's probably my fault. It should be (I believe) VariantName=JP1 (or some other unique variant name.) So far as I know, the upgrade chico used is the only one using the Yamaha 4DEV, and it also needs to have the VariantName added (011A:JP1)

The existing protocols.ini file will work as is with all remotes that don't have the NEC 2DEV executor, so there are really only 4 remotes that are affected: RS 15-2116/7, 2133, URC-6131, and Slingbox JU.
But we need to fix protocols.ini and also update the upgrade file.

Chico,
In RM, select the 2116 as the remote type, and in IR, paste in both the upgrade from RM, and the protocol upgrade that Vicky posted. Then it should work.

There are three issues here:
1) Chico didn't actually upload the RMDU file that he used. He just pointed us to the RMDU file that he used as a starting point, and then remapped the buttons, and removed a lot of functions. So it's difficult to see exactly what happened, although reading the IR file into RMIR allows us to see some of the changes.

Actually, it IS the file I used. The buttons are automatically remapped when I changed the remote to an RS-2116, at least enough of them to test the functionality. Since the power, volume, mute, menu, etc. are properly mapped upon changing the remote, I left it as is to keep it simple for testing purposes, and to avoid adding other variables (or my own mistakes).

3FG wrote:

2) He didn't change the remote type to match his RS 15-2116. That lead to the incorrect mapping of functions to buttons.

No, I DID do that. I must have stepped through this procedure a dozen times or more, changing the remote each time. Although I'll go back and check the actual memory map I uploaded to see if I neglected to do so the last time. BUT, that is certainly the first thing I do, is change from the Atlas remote to the RS-2116. Is it possible it's not sticking?

3FG wrote:

3) Protocols.ini has an error in the way the Yamaha 4DEV Combo is listed. The 2DEV and 4DEV NEC protocols both use 011A, and so does the Yamaha 4DEV. That's OK in itself, but the Yamaha version does not have a VariantName entry. That's probably my fault. It should be (I believe) VariantName=JP1 (or some other unique variant name.) So far as I know, the upgrade chico used is the only one using the Yamaha 4DEV, and it also needs to have the VariantName added (011A:JP1)

The existing protocols.ini file will work as is with all remotes that don't have the NEC 2DEV executor, so there are really only 4 remotes that are affected: RS 15-2116/7, 2133, URC-6131, and Slingbox JU.
But we need to fix protocols.ini and also update the upgrade file.

Chico,
In RM, select the 2116 as the remote type, and in IR, paste in both the upgrade from RM, and the protocol upgrade that Vicky posted. Then it should work.

OK, I just selected RS-2116 as the remote type, pasted it into IR as before, and it didn't work. Mute still is volume up, POWER is volume down, etc. Same as before.

Then I added in Vicky's protocol upgrade, and VOILA! Correct operation! With no changes at all, except adding the protocol, it works. Or, I should say, the basic functions (VOL, MUTE, POWER) work, which is better than before. I'll get to testing the more exotic -y2 -y3 stuff in a day or two. Will Vicky's protocol upgrade handle those variants?

I think I understand the above discussions…will an upcoming version of IR remove the necessity for me to add Vicky's protocol upgrade to IR?

At any rate, thanks to everyone for helping me get this to work so far. I still have some questions about the -y1 -y2 -y3 protocol, as there is some conflicting info in various posts about the topic. But it's late tonight and I'll probably start a new thread for that in the general forum to help others who may also be seeking assistance.

chico,
It surprises me that a missing executor could cause so many buttons to become unmapped and/or wrongly mapped. When I try it here, the original file has various inputs (e.g. HDMI1) assigned to the digit keys, and the digits are unmapped. Those assignments aren't changed when I change the remote to a 2116. But your IR file has numbers assigned to the digit keys, so it seems to me that some remapping was done, or perhaps I didn't really start with the same RMDU file as you did.

In any case, for diagnostic purposes it would have been a big help if you had saved and uploaded the RMDU file that resulted when the remote type was changed. It really isn't the same file anymore once the remote has been changed or the buttons have been remapped.

The protocol upgrade that Vicky posted is the same one that is already in protocols.ini, and it is designed to handle the y1, y2, y3 styles. As mentioned above, there is an error in protocols.ini which affects the RS 15-2116.

It will always be necessary to paste any required protocol upgrade to IR. That is the way it is designed to work. You can avoid the manual step by using RMIR instead.

There are three issues here:
3) Protocols.ini has an error in the way the Yamaha 4DEV Combo is listed. The 2DEV and 4DEV NEC protocols both use 011A, and so does the Yamaha 4DEV. That's OK in itself, but the Yamaha version does not have a VariantName entry.
The existing protocols.ini file will work as is with all remotes that don't have the NEC 2DEV executor, so there are really only 4 remotes that are affected: RS 15-2116/7, 2133, URC-6131, and Slingbox JU.
But we need to fix protocols.ini and also update the upgrade file.

Thanks for the explanation. That clears things up for me.

Quote:

It surprises me that a missing executor could cause so many buttons to become unmapped and/or wrongly mapped. When I try it here, the original file has various inputs (e.g. HDMI1) assigned to the digit keys, and the digits are unmapped. Those assignments aren't changed when I change the remote to a 2116. But your IR file has numbers assigned to the digit keys, so it seems to me that some remapping was done, or perhaps I didn't really start with the same RMDU file as you did.

The next 8 bytes are supposed to be the Fixed Data.
A1 5E 81 7E FF 00 FF 00

Since there is no number table in use, the numbers come next. Since this is a 2 byte protocol, the next 20 bytes are supposed to be the number keys.

00 00 1D 20 AD 20 00 00 97 20 59 20 95 20 00 00 00 00 00 00

But since the built in protocol is expecting 4 bytes of fixed data instead of 8, the last 4 bytes of the fixed data become the first 4 bytes of the numbers. All the numbers get shifted.

FF 00 FF 00 00 00 1D 20 AD 20 00 00 97 20 59 20 95 20 00 00

This shifting continues through the rest of the keymap. All the keys are shifted over by two keys (4 bytes). So you can see the wrong protocol variant can cause a great deal of shifting.

Quote:

It will always be necessary to paste any required protocol upgrade to IR. That is the way it is designed to work. You can avoid the manual step by using RMIR instead

Of course in a case like this, you'd have to jump through hoops to get the 011A protocol to be added in RMIR. Gettiing the custom protocol into RM requires a thorough understanding of manual settings. I've complained about how difficult it is to tweak a protocol in the latest versions of RMIR. Perhaps if someone else tries it and adds their voice to mine, there might be a change._________________Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

Vicky,
Thanks for the very complete explanation of the upgrade structure. However, chico's IR file has, I believe, a different entry for the number table than the original 00, and this comes before the fixed data. So I'm still puzzled. Put another way, I can see how the wrong number of fixed data bytes can cause the signals to be shifted from button to button. I don't see how the keymap bytes can be affected, and yet that seems to have happened with chico's IR file. Or, I'm starting with a different RMDU file.

Quote:

Getting the custom protocol into RM requires a thorough understanding of manual settings. I've complained about how difficult it is to tweak a protocol in the latest versions of RMIR. Perhaps if someone else tries it and adds their voice to mine, there might be a change.

But NEC 4DEV Yamaha Combo isn't a custom protocol-- it is standard in protocol.ini, albeit with an error that affects 4 remotes. I'd prefer that the effort necessary to make that change to RMIR go instead into documenting how to correctly add an entry to protocols.ini.

Vicky,
Put another way, I can see how the wrong number of fixed data bytes can cause the signals to be shifted from button to button. I don't see how the keymap bytes can be affected, and yet that seems to have happened with chico's IR file. Or, I'm starting with a different RMDU file.

You must be starting with a different RMDU file. I downloaded the one in the link, and it matches to the IR output when I change to the 15-2116

Quote:

However, chico's IR file has, I believe, a different entry for the number table than the original 00, and this comes before the fixed data.

I sincerely doubt that. To use a numbers table entry other than 00, the upgrade has to exactly match all ten numbers for a number table entry within the remote. The random way inputs are assigned to the numbers would rarely match a pre-defined numbers table entry.

Quote:

Quote:

Getting the custom protocol into RM requires a thorough understanding of manual settings. I've complained about how difficult it is to tweak a protocol in the latest versions of RMIR. Perhaps if someone else tries it and adds their voice to mine, there might be a change.

But NEC 4DEV Yamaha Combo isn't a custom protocol-- it is standard in protocol.ini, albeit with an error that affects 4 remotes. I'd prefer that the effort necessary to make that change to RMIR go instead into documenting how to correctly add an entry to protocols.ini.

While that might be practical for the unknown signals that we get every once in a while, its totally impractical for the vast majority of custom executors, which are just tweaked so that they will give the correct number of repeats for working within a macro. I'd say protocol tweaking is approximately 85% of my protocol work. I don't know about how much Rob does on the side, but we usually see less than one new signal a month in the protocol decodes forum._________________Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

You must be starting with a different RMDU file. I downloaded the one in the link, and it matches to the IR output when I change to the 15-2116

Strange--I don't get the same result. When I load in chico's IR file, and look at the Devices tab, the digit keys 0 through 9 have Hex Commands asssigned, and these hex commands are B2 20, 58 20, 98 20, etc. These are the hex commands for number 0, 1, 2... for Yamaha receivers. Using the linked RMDU file, changing to 2116, and pasting the upgrade into IR, the same digit keys have hex commands 00 00, 1D 22, AD 22, etc. 1D 22 and AD 22 are the hex data for HDMI1 and HDMI2.

Ooops. My Bad. I was looking at my 2116 file not the users. Yes it looks like the OP did an auto assign._________________Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

In any case, for diagnostic purposes it would have been a big help if you had saved and uploaded the RMDU file that resulted when the remote type was changed. It really isn't the same file anymore once the remote has been changed or the buttons have been remapped.

Actually, I didn't save the file to disk, I just changed the remote type and copied the device code to IR. I assumed that I didn't need to save the file for the generated code to be correct. Am I wrong about that?

Quote:

The protocol upgrade that Vicky posted is the same one that is already in protocols.ini, and it is designed to handle the y1, y2, y3 styles. As mentioned above, there is an error in protocols.ini which affects the RS 15-2116.

Cool. Now I can start button mapping and macro baking.

Quote:

Ooops. My Bad. I was looking at my 2116 file not the users. Yes it looks like the OP did an auto assign.

Yes, I just let RM do it (it assigned a few buttons when changing the remote) for testing purposes. Does that cause an issue?

No, you don't need to save a RMDU file in order for the changes to be effective. I think it is a good idea to do so, in the event that you later want to make modifications or even change to a different model of remote. If you haven't saved the RMDU file, then it is necessary to reconstruct it. In the present situation, which is caused by an error in our tools, it would have been useful to see the exact RMDU file, but normally it isn't necessary.

People normally remap the buttons because each remote and the intended use are different. It was only an issue here because we want to completely understand the failure mode, and I think we do now.

People normally remap the buttons because each remote and the intended use are different. It was only an issue here because we want to completely understand the failure mode, and I think we do now.

Wait, I'm not sure I understand the problem. Does it have anything to do with Vicky's broken glasses? Because I think that deserves the highest priority and needs to be resolved, stat._________________Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)

No, you don't need to save a RMDU file in order for the changes to be effective. I think it is a good idea to do so, in the event that you later want to make modifications or even change to a different model of remote. If you haven't saved the RMDU file, then it is necessary to reconstruct it. In the present situation, which is caused by an error in our tools, it would have been useful to see the exact RMDU file, but normally it isn't necessary.

People normally remap the buttons because each remote and the intended use are different. It was only an issue here because we want to completely understand the failure mode, and I think we do now.

OK, I understand. I provided that particular file because it duplicated my problem, and didn't include any of my own errors. It was only intended as a test file, not a remapped file for my usage.

You guys do great work. It's very interesting to follow the discussions, as they become learning aids for the rest of us. Thanks again.