With the FTDI based hardware from my previous post, I’ve been looking at how LIRC can be used with multiple transmitters / receivers. As I’m using Ubuntu 13.10 (based on Debian – other linux distributions may vary in the configuration / installation of lirc), the repository for 13.10 provides version 0.9.0 of the LIRC package so these are being used as the basis for this post.
To install the lirc package, enter the following into the command line (or install lirc from the ‘Ubuntu Software Centre’:
$ sudo apt-get install lirc
As shown in the following screenshot, installing the lirc package also pulls in the ftdi and setserial libraries and suggests the installation of lirc-x which includes additional lirc tools specifically for use with the X display manager such as xmode2 (a GUI version of mode2), though these aren’t required.
The lirc deb package uses debconf to prompt for configuration options during installation (lirc can be configured and compiled to work with specific drivers for certain hardware or all supported drivers, this is all handled during the deb installation process).
The debconf configuration options allow for the selection of the FTDI type of receiver device:
And also separately provides an option to choose the transmitter. There is currently no option from the list to select an FTDI based transmitter but this can be configured later.
The receiver and transmitter options chosen at the time of installation are written to the file /etc/lirc/hardware.conf file:
The device driver has been specified in the hardware.conf file for the receiver and the transmitter configuration is left empty.
After the installation of lirc, the Ubuntu service for lirc is started which reads the configuration from /etc/lirc/hardware.conf and creates the lircd instance(s) accordingly.
Using ‘ps faux | grep lircd’ to list the processes with command line arguments that match ‘lircd’ shows the following:
A single lircd instance has been created by the init script (/etc/init.d/lirc) which is run by the lirc service. Based on the hardware.conf configuration, the init script has explicitly specified the lircd socket file /var/run/lirc/lircd (though this would have been the default) and has set the device driver to be used as ‘ftdi’.
The irrecord program can now be used to record a remote control to file, however the device and driver parameters need to be specified since irrecord doesn’t pay any attention to running lircd instances and as such has no way of determining the configuration options from /etc/lirc/hardware.conf.
Although the device driver was chosen at installation and is already included in the hardware.conf file, when using lirc packages such as irrecord and mode2 the exact device needs to be specified. Fortunately all USB FTDI devices are shipped with a unique alphanumeric serial number which can used by LIRC to determine which device to communicate with.
Finding the FTDI serial number
There are a number of ways to do this, using ‘lsusb’ with increased verbosity of the output being one, but the easiest method is to plug in the USB device and run ‘dmesg’ to see information about the most recently connected device which includes the device serial number.
Using irrecord and mode2
Using the serial number, the following command line can be constructed to start the irrecord program.
$ sudo irrecord -d serial=FTG4GJL4 -H ftdifilename
Having recorded a file, the contents of the file or the path to the file can then be included in the /etc/lirc/lircd.conf file. When restarting the lirc service, the lircd instance will now be aware of the remote file.
As with irrecord, mode2 can be used to decode and output the IR signal of a remote that uses space encoding, again explicitly specifying the device and driver:
$ sudo mode2 -d serial=FTG4GJL4 -H ftdi
Adding the transmitter
The /etc/lirc/hardware.conf file can be edited to add the transmitter by setting the TRANSMITTER_DRIVER option to FTDI, and as per the receiver using ‘dmesg’ to find the serial number of the transmitter device which can then be added to the TRANSMITTER_DEVICE option.
Restarting the lirc service with the new configuration, and issuing another listing of the running processes there are now three instances of lircd.
One for the receiver (5240), with an additional subprocess (4249) for the receiver and one (5246) for the transmitter. The subprocess has appeared because the Ubuntu init script has detected that two devices have been configured (a receiver and a transmitter) and has made use of the lircd networking capabilities which allows two lircd instances to communicate, albeit only one way – from listener to connector, so the receiver lircd instance can send event updates to the connecting lircd instance (the transmitter). So the listening lircd instance forks a subprocess to handle incoming connections.
Transmitting an infrared signal
The irsend program works by communicating with a lircd socket file (rather than the device directly), with the default socket file being /var/run/lirc/lircd the use of irsend without any change in the device parameter would be trying to transmit infrared signals via the receiver device. Therefore, to target the transmitter device, the socket file for the transmitter lircd instance is specified:
$ sudo irsend -d /var/run/lirc/lircd1 SEND_ONCE remote code
Adding additional transmitters (and receivers)
All that is needed is an additional lircd instance for each transmitter / receiver. The obstacle with this is that the Ubuntu init script doesn’t handle any more than one receiver and one transmitter from the hardware.conf file, however these don’t have to be created by the init script and can be added manually or via another start up script.