Recently, I found a bunch of remote controls at work, with the matching IR receiver diode. After tracking down the source, it turned out some colleagues were building a Digital TV to Multicast server for some project. They needed quite a few DVB-T cards to get the signal; they chose DVICO Fusion Dual HD express DVB-Ts. That server being fully automated, they didn't need the remotes. Hence my booty. So I decided I'd use them to control my XBMC-based media center using LIRC.
These cards come with an IR diode at the end of a 3.5mm TRS jack. Having had some past experience and projects with homebrew serial modules before, I took the wild guess that this receiver would fit in the circuit. And it did.
So I set out to build one serial receiver, replacing the normal TSOP 1738 with a 3.5 jack socket. Another wild guess, helped by a ohmmetre and the datasheet, allowed me to work out which pin each contact on the TRS jack was as compared to a 1738, and wire the socket accordingly. This is as follows:
Then some soldering happened.
The Debian LIRC package already comes with configuration files for the supported remotes. These include the DViCO Fusion HDTV, in
/usr/share/lirc/remotes/dvico/lircd.conf.fusionHDTV. It can be copied verbatim as
The rest of LIRC can be configured in
/etc/lirc/hardware.conf. It mostly involves setting the following:
... LOAD_MODULES=true DEVICE="/dev/lirc0" MODULES="lirc-serial"
The UART of the serial port has to be deactivated. We also use Debian's
setserial init script to keep the setting.
$ <in>sudo setserial /dev/ttyS0 uart none</in> $ <in>sudo dpkg-reconfigure setserial</in> [select autosave once]
This doesn't seem to work
Another option is to tell
modprobe to change the UART prior to loading the
pre-install lirc_serial /bin/setserial /dev/ttyS0 uart none
Then, the whole shebang can be started, and tested.
$ <in>sudo /etc/init.d/lirc start</in> ... $ <in>dmesg</in> ... [1292746.588538] lirc_serial: ignoring spike: 1 1 4fd56036 4fd56036 8e9d8 8e4ab [1292746.588647] lirc_serial: ignoring spike: 1 1 4fd56036 4fd56036 8ea49 8ea44 [1292746.588716] lirc_serial: ignoring spike: 0 1 4fd56036 4fd56036 8ea8e 8ea78 [1292746.588800] lirc_serial: ignoring spike: 1 1 4fd56036 4fd56036 8eae2 8eabc [1292923.771275] lirc_serial: module is from the staging directory, the quality is unknown, you have been warned. [1292924.668015] lirc_serial: auto-detected active high receiver [1292924.668169] lirc_serial lirc_serial.0: lirc_dev: driver lirc_serial registered at minor = 0 [1293036.027874] lirc_serial: module is from the staging directory, the quality is unknown, you have been warned. [1293036.932015] lirc_serial: auto-detected active low receiver [1293036.932167] lirc_serial lirc_serial.0: lirc_dev: driver lirc_serial registered at minor = 0 $ <in>irw</in> 00000000807f32cd 00 8 DViCO_Utraview 00000000807f32cd 01 8 DViCO_Utraview 00000000807fe21d 00 play DViCO_Utraview 00000000807fe21d 01 play DViCO_Utraview 00000000807fe21d 02 play DViCO_Utraview
XBMC then needs to be taught how to interpret the remote's input. Some more work is needed there. First, the mapping from LIRC button to XBMC inputs has to be done, in
Lircmap.xml. The default system file is in
/usr/share/xbmc/system/Lircmap.xml, while the user's custom version can be put in
~/.xbmc/userdata/Lircmap.xml. I fiddled with mine a bit to adjust some specific keys available on that remote. The final version is here.
Based on this mapping, XBMC can then be instructed to behave in specific ways through the
keyboard.xml file (either in
/home/elisa/.xbmc/userdata/keymaps/). My most important requirement is easy start of the party mode. Some other tweaks are in my final configuration, including a precusor to my Hammer Button.
OpenELEC natively supports a number of remotes, LIRC or not, which it exposes to XBMC through
eventlircd. The configuraton above doesn't work because ''eventlircd'' expects keys to be named following the event subsystem's convention. An updated .config/lircd.conf and .xbmc/userdata/Lircmap.xml fix the problem.