lirc2xml & lirc2rmdu: Snarfing IR-signals from LIRC file

[Barf]

Extracting info from LIRC files comes up every now and then. Since LIRC has a pretty particular model for describing the signals, this is not an easy task. I have written lirc2xml as an extension to LIRC, it uses the LIRC IR-engine to render the signals, and outputs them to an XML file instead of hardware. There is a companion program, lirc2rmdu, technically a post processor for lirc2xml, that generates Remotemaster rmdu-files (probably needing some manual tweeking).

Documenation is found here

Be sure to read the documentation, as this stuff probably requires more than the average Windows application...

[vickyg2003]

Hi Bengt,

I've read the documentaion for your utilities. 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.

In my experience, most of the time I've seen LIRC, 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.

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. Is there anyway that your tools can be adapted to use a standard lirc file?

[The Robman]

It's risky going from LIRC to RM format because that requires that you identify the protocol, etc. 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.

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.

[Barf]

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

Code: Select all

lirc2xml -o RC-1070E.xml RC-1070E

. 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

Code: Select all

python lirc2rmdu.py  RC-1070E.xml

. 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.

[vickyg2003]

Okay, I didn't understand. Normally when I can't understand I try the software, but I don't have a Linux box. I'm sure some other people on the forum have access to Linux.

I'd love to have a tool that I could use to decode LIRC, because its difficult and tedious.

[wnewell]

The lircd.conf file you posted is just one version of the file. It's also easy to create one with the raw codes such as this if it's easier to figure out.

# brand: One For All URC-8810 (default cable device)

begin remote

name /home/test1
flags RAW_CODES|CONST_LENGTH
eps 30
aeps 100

ptrail 510
repeat 0 0
gap 100206

begin raw_codes

name menu
9077 4498 506 4487 518 2213
509 2238 533 4453 527 4434
576 2182 550 2189 584 2166
570 2180 569 2186 562 2162
605 2150 597 2138 593 4401
590 4412 616 2105 608
----------

[vickyg2003]

Hey wess, thanks for that information. Can anybody with a LIRC program then suck in the one format, and spit out the other?

[Barf]

Can anybody with a LIRC program then suck in the one format, and spit out the other?

"anybody with a LIRC program" runs Linux (unless you are talking about the since many years abandoned winlirc) and can thus build and run lirc2xml So it does not buy you anything if you try to avoid Linux.

Anyhow, I almost completed compiling lirc2xml in the Cygwin environment in order to produce an executable that runs on Windows hosts. I just do not know yet how to link with DecodeIR.dll. Stay tuned.

[erocm123]

Extracting info from LIRC files comes up every now and then. Since LIRC has a pretty particular model for describing the signals, this is not an easy task. I have written lirc2xml as an extension to LIRC, it uses the LIRC IR-engine to render the signals, and outputs them to an XML file instead of hardware. There is a companion program, lirc2rmdu, technically a post processor for lirc2xml, that generates Remotemaster rmdu-files (probably needing some manual tweeking).

Documenation is found here

Be sure to read the documentation, as this stuff probably requires more than the average Windows application...

I know this is an old thread, and I apologize for reopening it, but I just wanted to thank "Barf" for lirc2xml. It has saved me a lot of time and works amazingly well. I've been able to get perfect sets of IR codes from LIRC, convert them to Pronto HEX and then use another script that I've created to convert the file to iRule format for uploading. This has made the process extremely simple and efficient.

While I was searching for some way to do this, I came across several posts of people ending up doing it by hand. Or eventually giving up. There truly is a need out there for this software, I believe it is just hard to find.


Anyway, thanks for your work!!

[The Robman]

There truly is a need out there for this software, I believe it is just hard to find.

I would agree. I think the first problem is that it's only available in the source code library, it's not in the regular programs folder. I just downloaded it and can see that it's not an executable, so I went to barf's documentation site and I see that it's an extension for LIRC itself, which most of us here don't use. So, for us, we would still need to do it all by hand.

[erocm123]

There truly is a need out there for this software, I believe it is just hard to find.

I would agree. I think the first problem is that it's only available in the source code library, it's not in the regular programs folder. I just downloaded it and can see that it's not an executable, so I went to barf's documentation site and I see that it's an extension for LIRC itself, which most of us here don't use. So, for us, we would still need to do it all by hand.

Well, I didn't use LIRC either . . . until last weekend. I patched and installed it using Barf's instructions (on my Fedora16 box) and used the lirc2xml binary with great success.

[Barf]

Lirc2xml now has a new home page.

There is also a new version, tested with the current LIRC version 0.9.0. (No really important differences, just the defaults.) Found at the usual places, including of course on its home page. Possibly more interesting in the light of

I believe it is just hard to find.

binaries for Linux 32 bit and Linx 64 bit. And, believe it or not, a Cygwin compile version that runs Windows! The Linux files are just the executables, download somewhere,make sure they are executable (chmod +x lirc2xml*), copy recent libDecodeIR.so to /usr/local/lib (optional), and it should work from the command line. The Cygwin file is somewhat trickier: I could not get the DecodeIR.dll to load properly, so I just linked the recent sources in. In order to run without Cygwin, there are some Cygwin dlls enclosed. If really intended to use with Cygwin, these should be deleted. Otherwise, unzipping into in an empty directory, opening a "Dos-box", cd to the just unpacked directory, and running with

Code: Select all

lirc2xml lircd.conf

(where the argument is the name of the file to be translated). The zip file contains the executable for lirc2xml (as before, DecodeIR compiled in), a test file and some Cygwin dll's.



@erocm123: Thanx for those kind words. Finally someone gets it.

I would agree. I think the first problem is that it's only available in the source code library, it's not in the regular programs folder. I just downloaded it and can see that it's not an executable, so I went to barf's documentation site and I see that it's an extension for LIRC itself, which most of us here don't use. So, for us, we would still need to do it all by hand.

I really have to comment upon this. Up until erocm123, the reception has bee, at most, lukewarm. One person even thinks that he is helping the community by (trying to) tell how to avoid using this program! (without providing any usable information). In other postings, various severe problems are claimed, without presenting any argument that stands up to scrutiny. I welcome constructive criticism, in particular if I can learn from it, but this is not it. Far from it.

If someone thinks "this looks like an interesting program, too bad that it does not run on $operating_system", why not say "it looks like an interesting program, any way I/you/we can get it to run on $operating_system"? The impression given by the first postings is rather that investing more time in it is a waste of time.