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 remotecode

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.

Using an FTDI PCB (with Vishay infrared receivers and emitters) as the basis for the project provides added benefits to my development including the following:

FTDI for infrared uses USB to TTL, however the same chips are more commonly used for RS-232 (which I plan to work on further down the line although I have done some initial experimenting with RS-232 and am familiar with FTDI USB to RS-232 devices).

As with most USB devices, they come with a unique serial number which can be retrieved when interrogating the device.

The EEPROM which stores the serial numbers is freely programmable from a number of operating systems which may be of use at a later date – I have experimented with programming non-FTDI USB to RS-232, such as the Prolific 2303, converters in the past without much success.

Readily available worldwide and relatively cheap.

Available in a range of formats, pre-moulded cables, chips / ICs and PCB modules.

Hardware in detail

The FTDI TTL-232R-5V-PCB is also available in a 3 volt version – the models are almost identical and only differ by the presence of R1 on the 5V model and R2 on the 3V version. Useful to know if you have one lying around and aren’t sure which model it is. The board is a basic USB to TTL serial converter and detailed information, schematics and EEPROM settings can be found in the datasheet online – I’m using these modules in their factory default states without any modifications to internal settings.

As most consumer remote controls operate at 38khz I opted for 38khz receivers and emitters (this decision on make / model was influenced by the fact that I had some TSOP38238 emitters lying around when first experimenting) but other receivers should work.

Schematics

Transmitter – The following diagram shows the wiring of the infrared emitter to the FTDI PCB.

Receiver – Infrared receiver pin-outs and corresponding pads on the USB module. The ground (‘GND’) pad highlighted by the dotted border indicating that the pad is on the underside of the module.

As can be seen, only the ground pad is common between the two diagrams so combining the emitter and receiver onto one module would be achievable.

Photographs

I’ve taken a few photographs of the hardware I’m using to get an idea of schematics in physical form and to demonstrate the scale of the modules.

Transmitter – using the original Keene Electronics IRUW wired emitter with lens (photos taken before obtaining the smaller blue Vishay emitter).

Receiver – leads of the component are soldered directly to the board (no additional wiring)

I have spent a bit of time searching for cases and alternative ways of housing the modules – there is a neat case manufactured by New Age Enclosures which is what the IR Blaster products use however it seems that resellers only make these available in bulk quantities so for now they will stay as they are until I manage to find something more suitable.

My first exposure to LIRC, and PC based IR control in general, goes back quite a few years to a time when I was using an infrared receiver connected via serial to control my MythTV installation.
While serial infrared transmitters are no doubt still being used, availability of serial ports has generally always been limited to one socket on a PC with optional expansion with additional PCI cards – the limit on this is determined by the availability of PCI slots on the motherboard and serial expansion generally isn’t an option with a standard laptop without using up the PCMCIA slot if the laptop has one. However as technology has progressed and the size of connections reduced, serial is probably now considered quite uncommon on a PC, instead favourable connections such as USB which are smaller, faster and allow for multiple devices on with just one port have become mainstream.

There is a maximum of 127 USB devices that can be attached to any one USB host controller, so the potential for expansion is there to cover the controlling of a considerable number of devices with USB IR transmitters. The following diagram illustrates how the controlling of three devices could be achieved in my theoretical model of equipment installation with an additional receiver for learning new codes.

USB is hot pluggable meaning devices can be inserted and removed without any disastrous side effects so any USB infrared device can be removed and allocated to another controlling machine at any time. It would, for example, be sensible / more cost effective to have one receiver module as a shared resource that is physically swapped between a number of machines to learn new IR codes from which the created drivers could be pushed to the controllers where needed.

With this in mind, the obvious place to start was to look for IR transmitter (and ideally receiver) hardware that was USB based. Having scoured the internet for quite some time for information on this, I have put together the following price comparison table of USB related IR products.

All of whom produce a variety of infrared related control products, including IR distibution units, IR over IP and a variety of wired emitters with attention to detail and excellent build quality. I’ve had experience with Keene electronics IRUW emitters and Xantech’s designer emitters (the blinking ones are quite handy to save getting a camera out to confirm transmission of the signal) and haven’t had any issues with these in the past.

USB IR product suitability

Iguanaworks product provides 2 x 2.5mm jack sockets to attach wired emitters to so this would be an option to consider. Iguanaworks online support appears to be very good with detailed instructions on configuration of their devices and troubleshooting. With Iguanaworks selling individual and dual wired emitters, it would in theory be possible to control up to 4 devices (2 channels, two emitters per channel) from one transceiver for $60 (though could be cheaper if you make your own wired emitters). This is assuming the signals being sent to one channel (two emitters) were unique enough so as not to trigger actions on both devices when only one is intended to be controlled – explanation to follow in my next post.
Unfortunately however Iguanaworks product is prohibitively expensive, adding multiple infrared transmitters would see a significant increase in cost and when factoring in the wired emitters and international shipping costs and tax, this adds up to quite an expensive control system just for infrared control.

The USB-UIRT components are housed within an enclosed casing which didn’t meet the requirements of a low spill and physically small emitter head.

USB-IR-Boy’s option is cheap, doesn’t include a transmitter and isn’t quite what I was looking for in terms of size – without some additional design work.

The IR Blaster products interested me as the style of the transmitter is exactly what I had been looking for. The description of the device stated that the design was based on a project started by Albert Huitsing which was documented in one of Albert’s blog posts. Having got my hands on a transmitter, and working through Albert’s blog I was able to successfully configure LIRC to send IR commands and control a TV on my desk at work.

Experimenting with FTDI

Although it is closest in terms of meeting the requirements, the IR Blaster products still seemed a bit too expensive at $24 (£15.48) for a transmitter and $20 (£12.85) for a receiver, plus shipping and tax. I decided to go back to Albert Huitsing’s designs, from which the IR Blaster is made, and found that the hardware uses merely a FTDI cable, an IR LED (and optional IR receiver). So how much would it cost to put one of these together myself?

Albert’s design uses a pre-made FTDI cable with an IR LED and receiver attached to the connector block. It looked a bit untidy but I’d seen that IR Blaster had used a PCB version of the same FTDI product and attached a wired LED to the end which is cheaper than using the pre-made FTDI cable.

I’d acquired a TTL-232R-5V-PCB and had a spare wired emitter from Keene electronics lying around. I removed the 3.5mm jack from the emitter and soldered the emitter to the PCB as per Albert’s design and have been using this for a good few weeks during testing without any issues at all. All devices I’ve wanted to control have worked and using xmode2 with a receiver to compare the signals I’m sending via my transmitter with LIRC compared with those from the original remote, the results have been very close and certainly accurate enough.

I was intrigued to see how cheaply I could replicate this, as the Keene emitters (while very neat and well made) cost around £5.99 + delivery. I’ve started looking at alternative emitters and have opted for something similar in specification to some IR receivers that I have used in the past (Vishay TSOP38238) and found that the Vishay TSUS4300 seemed to be a pretty close match. Initial tests with this are also looking positive, I’m able to control the same devices as with the emitter from Keene electronics and although it doesn’t have the emitter lens cover it still looks reasonable and is smaller in size.

I have an account with Farnell (onecall) and although I already these parts I priced them up to see how much it would cost to replicate:

Manufacturer

Product

Quantity

Price (inc VAT)

FTDI

TTL-232R-PCB

1

£11.76

Vishay

TSUS4300

1

£0.11

Total

£11.87

For £11.87 ($18.40 / €14.00) – add the additional cost of some two conductor multiple strand cable (maplin electronics do some striped miniature speaker wire at 49p per metre which will do) and a very small amount of solder, which I had lying around, I would be able to build myself a relatively cheap infrared transmitter.

That’s only $5.60 cheaper than buying one from IR Blaster?

I’d saved on international shipping and tax as well, but the big win is that I could, in theory add an IR receiver (Vishay TSOP38238) at a cost of £0.44 which would turn the device into a USB IR transceiver for a total of £12.31 ($19.14) – plus standard delivery – a pretty good result looking back to the requirements I had started out with.

So how can LIRC be used to drive multiple USB transmitters?

Part of the LIRC documentation covers the use of multiple, different devices and guides the user through this. However it didn’t seem obvious, and perhaps isn’t possible, to configure multiple devices from one lircd instance so the next logical step was to run multiple instances of lircd, each one targeting a specific FTDI device. This approach would actually work to my advantage and provide greater flexibility in that I could have multiple instances of lircd for different tasks, some for learning and some for transmitting via devices that are all connected to one PC.

Quick update – It appears that running multiple instances of lircd is exactly how debconf on Ubuntu (currently using 12.10) works when selecting different transmitters and receivers, highlighted in the following image:

I’ve been looking at PC based IR control options and have spent some time experimenting with LIRC and the Arduino IR library which have both proved to be usable and popular methods of IR control.

The Arduino IRremote library supports of a variety of Arduino hardware and, despite it’s name, also caters for different prototyping boards such as the Teensy (1 and 2) and Sanguino. It appears to have been very popular for hobby prototypists with since it’s release and to highlight the current level of interest in the Arduino IRremote library the git repository has been forked a total of 115 times to date!
Interest has sparked the addition of more remote control protocols by the Arduino community (such as Samsung, Panasonic and more) which have gradually made their way onto Ken Shirriff’s blog. I worked these additions into my local copy of the library and began testing with the range of remotes I had available – Samsung, Elmo (NEC), Panasonic, Hauppauge (RC-5), Kramer (NEC), Mitsubishi, Toshiba (NEC), LG (NEC). The results were mostly successful, some of the protocols weren’t recognised and couldn’t be decoded but could be recorded in raw mode. I only managed to find one, Panasonic, remote that the library didn’t seem to respond to.

However the one real draw back of using an Arduino for infrared control is that the Arduino has a limited number of timers available for PWM (which is used to drive the emitter). With Ken’s library, the emitter has to be connected to pin 3 – meaning 1 emitter per Arduino and with an Arduino Uno currently costing in the region of £25, attaching lots of these to a small PC would start to take up space required for the control system and significantly increase costs.

I’m now taking a different direction, with LIRC, which has been around for years and is much more established and commonly used for HTPCs in the linux world. I recently found licensing documentation bundled with a new Toshiba Blu-Ray player that showed the player was using LIRC as part of the firmware on the device. Encouraging to know that LIRC is used by big companies in industry.

Since LIRC is most commonly configured to run, as a single instance with a single receiver (for use with a HTPC), how then, can I use LIRC with multiple infrared transmitters and receivers that are both small and cheap? More to follow in my next post!

The idea of the project is based around the control of devices via a PC – the main goals are to make it as cheap, modular, accessible and physically small as possible.

I plan to cover various methods of control but have started with infrared control and aim to focus on this then, time permitting, expand the system at a later date – infrared should, in theory, be one of the easier and simplest methods of communication although it requires hardware that isn’t usually found within a standard PC.

I’ve been researching products manufactured by the big names in control systems, such as Extron, AMX and Crestron which all cater for multiple infrared emitters and have different approaches to learning new codes via a receiver.

I should point out that I’m basing the requirement for multiple transmitters on my past experience of co-designing, installing / configuring and programming 6 major lecture theatres at my place of work at a reasonably sized UK University. Our preference was to control everything over IP as this allows for greater flexibility, ease of configuration and direct remote access. Where products didn’t provide IP control, we settled for RS-232 and as a last resort infrared.
Most equipment fell into the first two categories but some (products we considered as domestic equipment unless you pay a lot of money) were infrared only, such as blu-ray / DVD and VHS players – unfortunately we still had to support VHS at the time. For our systems we had a total of 3 devices controlled by infrared as depicted below, however, in the past I have also seen a wide range of equipment on our campus controlled by infrared, some you might expect, others you would question why a one-way communication method like this had been used.

Over the years I’ve had quite a lot of experience with Extron equipment, and have done my fair share of ‘configuration’ (a term preferred by Extron for ‘programming’ their devices is in a lot of cases, the ‘programming’ is purely drag and drop). However I have had limited exposure to AMX and Crestron systems so was interested to see how the three aforementioned control systems manufacturers compared in terms of infrared provision.

* documentation suggests that additional (up to 3) card slots can be used each providing a further 8 IR outputs

In each case, the learning of infrared codes requires the use of a PC to build and store the infrared control driver. However it’s interesting to see that each manufacturer has chosen a different method of communication between PC and receiving device to achieve this. Each manufacturer has provided their own software for learning IR codes, all of which seem to be available for Microsoft Windows only.

Software required for IR learning

As a Linux user this is a bit disappointing. So why isn’t and why can’t software for control systems be written for a variety of platforms? Or better yet, written to be platform agnostic and available via the web – everything else seems to be going that way and this is the direction I’m hoping to take – perhaps there are very good reasons I haven’t considered that I’m yet to discover..

However one thing that I am hoping to achieve, as with all of the manufacturers listed above is to implement infrared control in a neat, ideally modular and potentially expandable way. The requirements of emitters I plan to use are that they will be low spill/low range wired with minimal components at the emitter end (preferably just a wire with an IR LED on the end) to position over the IR window of the device to be controlled. I have been investigating ways to achieve this and so far this is looking promising – I’ll publish further hardware information and a further comparison of products / software from Control4 / OpenRemote in due course, but my next post will cover some of the popular software options that are currently available for infrared transmission and learning.

As part of my Software Engineering studies at University, this will serve as place to document research and progress of an idea for my final year project which is focuses on control systems and methods of communication.

I’ve been looking at the various well-established commercial products from the likes of Extron, AMX and Crestron in addition to relative newcomers such as Control4 and openremote.

In future posts I’ll document this research, the initial goals and the direction my project is taking with any software releases along the way. This should all serve as a diary to reflect upon when I come to the stage at which I need to write the final project documentation and hopefully, by making everything publicly available, this will invoke some ideas and potentially further development from the online community.