First of all, I discovered a bug that caused the program to either dump core or to produce erroneous results. New version uploaded.
If I'm understanding right, this requires the linux users lirc to be patched to produce some xml file that your companion program to produce the RDMU.
No, you do not understand it right. Following my instructions builds a new program, lirc2xml, and leaves any existing installation alone (expect if the user determines to overwrite it by issuing make install).
the poster is using a anonymous configuration file such as this lirc configuration file, so we can't ask the linux user to patch his lirc because we don't know the linux user.
No, it is not anonymous at all, it is a normal file, in current LIRC defaults to /etc/lirc/lircd.conf. Anyhow, it is given to lirc2xml as its argument. To process the file, download it locally to, say, RC-1070E, and issue the command
. This creates the file RC-1070E.xml, also available
here. Note that DecodeIR has identified the signals as "NEC", a protocol name unknown to Remotemaster. This file is translated to a rmdu-file using
.
This file is not
quite suitable for RM as such, it needs to be hand edited to turn NEC as protocol name into NEC1 (or something else?) and the protocol number has to be adjusted to 00 5A. Now it can be loaded into RM; however it still remains to fill in the device- and subdevice numbers (25 and 231 respectivelly, however some codes are subdevice 24) -- this information is read out of the XML-File.
Code: Select all
After YEARS of Rob's mentoring, I can now read SOME of these files and decode them by hand to pull out specific functions, but its tedious.
And now this is not needed any more? Am I not nasty? Anyhow, the Rob-method is severly error prone: The verbal description is written by other people than the developers, it is several years old and LIRC has evolved in the meantime, it should be interpreted by other humans, who make errors. Instead, I use LIRC to decode LIRC-files, eliminating all this chain of potential errors.
Is there anyway that your tools can be adapted to use a standard lirc file?
I hope this has been answered.
It's risky going from LIRC to RM format because that requires that you identify the protocol, etc.
Well, of course. lirc2rmdu therefore gives up unless it finds DecodeIR-decodes.
As we often get called in when there is an unknown protocol, it might be more useful to go from LIRC format to a learned format that we understand, like the Pronto format or the UEI learned format.
Do not see your point here. This is exactly what lirc2xml does.
If you were to go with the UEI learned format, the best possible output would be an IR file, faked up to look like an IR file from a remote with lots of learning memory, like the URC-8820.
If you are up for that project, the xml file from lirc2xml would be an ideal starting point.