RMIR feature: convert learned signals into an upgrade

[The Robman]

split from: https://www.hifi-remote.com/forums/viewtopic.php?t=16540

I've learnt them onto the 6440 now but they don't show up in the device tab on RMIR, just the learned tab. How do I copy them across to the device on RMIR so that I can save the file and upload it?

We don't have an automated way of converting learned signals and adding them to existing upgrades, the process is manual. As we already know the protocol and device codes, all we need from your learns is the OBC (original button code), so what you would do is, make a note of the OBC for Tape and Mode, then go to the upgrade itself and add 2 new entries.

Before you do that, you should re-download your upgrade file because I modified it a little. The 2 codes for input+ and input- were added as many different functions and then spread across the number buttons, so I reduced them down to just 2 functions and added them to the CH+ and CH- buttons instead. I had to guess as to which was input+ and which was input-, so maybe you could verify that.

[mathdon]

We don't have an automated way of converting learned signals and adding them to existing upgrades

Actually, Rob, I think we do. Go to the Options menu in RMIR and click on Options > Advanced > Learn to Upgrade Conversion. It should add a new button to the Learned Signals tab, "Convert to Device Upgrade". (If it doesn't add it, close and re-open RMIR - in checking just now, I found that was sometimes necessary.)

You should now be able to select one or more learned signals and have them added to a device upgrade by pressing this button. This wasn't written by me, I don't know how robust it is, but the option is there. IIRC it was written by Vyrolan, who came into this group, was very active for a short time and then disappeared.

[The Robman]

I just tested this myself and it works. Which raises the question, why is such a cool feature buried deep under 2 levels of menus in order to activate it. Buried so deep that even I didn't know about it.

My recommendation is that it be activated permanently.

[ElizabethD]

Just FYI: several months ago I converted a whole mess of old 8910 learned signals to upgrades. It was during some early RMIR 2.03 work. It worked great.

[3FG]

IIRC, Vyrolan chose that menu location, probably because the feature wasn't much tested. But as Rob notes, that means it doesn't get tested much. Anyway, it's cool for the situations where it works.

Automatically making an upgrade from learned signals is hard because most executors need more information than a decode of an IR signal provides. And our way of describing executors in protocols.ini doesn't lend itself to algorithmic use. So the Convert To Upgrade button only works for the most simple of protocols. Until we revised significantly the entry for NEC1/2/x1/x2 in protocols.ini, the Convert To Upgrade button didn't work for NEC signals, except for the common case when there is no subdevice. And that is in no way a bug in the code; instead RMIR simply doesn't know what to do with flag bits in executors, so it writes a zero. That means a combo executor isn't likely to work, although it was possible to make PID 005A (NEC) work correctly. I don't think there is any possibility of converting RC-5 signals. I haven't tried other IR protocols, but I suppose that as people, especially novices, try out the Convert feature, we'll find lots of other instances where the generated upgrade doesn't function correctly.

As a practical matter, many components require combo executors. Yamaha, Onkyo, Panasonic, Marantz, Denon, Sony all tend to need combo executors. For me, it is easier and more robust to choose an appropriate executor and do column copies from the learned signals tabs into the Device Upgrade Editor.

[The Robman]

You're right, when I looked closer at the NEC1 upgrade that it created for me, it had -1 in the sub-device field, and I just tried it on some RC5 learns and it didn't work at all, so it does need some work.

But obviously, nobody's going to work on it if nobody knows it exists.

So I guess for now, let's leave it hidden, but if Graham is willing to look into it, I would be willing to experiment with it and propose fixes, and I'm guessing it won't be hard to find other volunteers among the JP1 experts.

[3FG]

Well, it won't be difficult to find issues, but IMO it isn't easy to find fixes. About a year ago, I spent some time considering how to do these conversions to upgrades so that the conversion could be accomplished successfully most of the time.

My conclusion then was that we would need, at the least, to come up with an executor description language. The approach taken in protocols.ini is not adequate to describe the flag bits in combo executors. As an example, RC5 is doubly difficult because it is both a combo executor, and the msb of the OBC bits is split into the fixed data. Unless we plan to write specialized code for each one of the known IR protocols and for each of the possible executors, we'll need a good way to describe executor behavior. Again as an example, many components use both RC5 and RC5x, requiring the RC5/RC5x combo executor. If we don't have an executor description facility, that would be another special case.

I think DecodeIR.dll would need to be re-written so that the output is in a completely standardized output format. Probably this would turn out to be that the output used for automatic conversions would abandon the use of terms like device, subdevice, etc, so that D:8, S:8, F:8,~F:8 would become A:32. I used here NEC as an example because it is familiar to all of us, but the issues show up with the newer protocols which have multiple fields like OEM, X, E, toggles, etc.

IMO, this is not a trivial project.

[Barf]

I did a similar experiment here, trying to import "arbitrary" commands into RM. Although the result was usabble for "important special cases", of course I run into similar problems.

The most annoying thing was that the protocols in protocols.ini are so "grown", with different notation etc. While DecodeIR/IrpMaster/IrScrutinizer uses D, S, F, and T fairly consequently, this is not at all the case in protocols.ini. There are (IIRC) "dev", "device", "D" etcetera, making the mapping very tedious. Just cleaning up protocols.ini, using uniform notation, would be a considerable step.

I think DecodeIR.dll would need to be re-written so that the output is in a completely standardized output format. Probably this would turn out to be that the output used for automatic conversions would abandon the use of terms like device, subdevice, etc, so that D:8, S:8, F:8,~F:8 would become A:32. I used here NEC as an example because it is familiar to all of us, but the issues show up with the newer protocols which have multiple fields like OEM, X, E, toggles, etc.

Compare http://www.harctoolbox.org/IrpMaster.ht ... nheritance.

IMO, this is not a trivial project.

right, it is a challenge...