Saturday, April 28, 2012

LIRC IRMP remote control code "sharing"

While investigating inferior LIRC performance today, I checked the timings used by IRMP and found that using those instead of the "measured" ones of LIRC in the config file made LIRC perform much better. See the patch for details.

Looking at the lircd.conf more thoroughly for the first time, I finally found the similarities between the lircd remote control codes and the IRMP codes (at least for the NEC protocol used with this handset):

  • IRMP "address": 0xBA45

  • IRMP "command": 0x1A

  • lircd "pre_data": 0xA25D

  • lircd "code": 0x58A7

The IRMP Documentation (sorry, german only) describes the NEC protocol as follows:
32 bits of data: 8 address bits + 8 inverted address bits + 8 command bits + 8 inverted command bits

The IRMP "address" is really 8 bit only: 0xBA inverted is 0x45, leading to an "effective address" of 0x45.
The IRMP "command" is already 8 bit only.

Now double-check with the lirc codes: address 0xA2 inverted = 0x5D, command 0x58 inverted = 0xA7, so the scheme seems to apply to both.

Using only the relevant 8 bits:

  • IRMP address: 0x45

  • IRMP command: 0x1A

  • lircd address: 0xA2

  • lircd command: 0x58

Looking closely, I found that the difference is actually the LSB / MSB order: IRMP is shifting the bits in reverse order compared to lircd.

So if needed, it should now be pretty easy to extract codes for IRMP from lircd.conf files using a simple perl script or the other way round, at least for NEC codes. Lircd has the advantage that you can easily "learn" your new remote control handset with an interactive program (if you disregard the suboptimal timing data it creates).