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