Infrared is not visible for the human eye, however most digital cameras are able to see it. To troubleshoot IR transmitters just look at them using a digital camera, and if it works IR LED sending out infrared light appear as bright violet.

Figure 4.1. Make IR visible

Infra red LED

See there is also a windows version with nice descriptions

LIRC inside

The lirc package contains two daemons lircd that has a link to the ir device driver and decodes the signals to a socket available for other applications. Additionally there is lircmd that can be used for IR based mice.

Lirc has one side toward the applications and one side toward the kernel device drivers.

Toward the applications it uses the socket /var/run/lirc/lircd that will usually be accessed via its link /dev/lircd. The data exchanged between application and the lirc daemon is human readable ASCII. irw is a program that hooks up there and prints everything coming from the lirc daemon to the console. For the other way, meaning transmitting, there is irsend. However additional daemons might exist as the mouse daemon /var/run/lirc/lircmthat sits above and make use of /var/run/lirc/lircd. There is also lircrcd, a daemon that translates remote and key names in uniform event names that are then exchanged with the applications making use of lirc. Lircrcd use the ~/.lircrcfile or the system wide /etc/lirc/lircrcfor that and can be tested with ircat

Towards the application sw the lircd uses the var/run/lirc/lircd TCP/IP socket on Port 8765 and downwards it uses a /dev/lirc<n> file. It gets usually started via a startup script as /etc/init.d/lircd start, but can obviously be started on the command line where parameters can be directly be passed. As --driver and --device. When started it reads /etc/lirc/lircd.conf, so each time this file is changed lircd needs to be restarted. It is also important that it will find this file and is able to parse it.

LIRC is able to record IR signals from remote controllers, analyze and store them. It is not limited to a given IR protocol, since it can remember waveforms. A huge collection of already registered remote controllers is available, but it is also easy to create such configuration files from scratch.

The device drivers are /dev/lirc. Depending on the type of the hardware device different modes of operation exist.

About the IR signals and the configuration file

The configuration file /etc/lirc/lircd.conf can have two modes how to remember the buttons codes:

  1. When LIRC understands the protocol, it describes them using a single code number per button but a larger common section.

  2. If the protocol is not understood the a raw format can be used where LIRC describes the IR waveform. Such files have a rather small common section but a big section containing the buttons, since there the waveform is described.

See for a description of the contents of those files. Important to know is that a configuration file can have more than one device, this is especially useful for transmitters where a single device (as Android) replaces many IR remote controllers. So do cat config1 config2 > lircd.conf

The wave form contains pulses and spaces. The units for the duration values of a pulse or a space is microseconds. A pulse is where the infrared signal is active, this is usually a modulated frequency in the area of 35kHz. A small pulse contains about 20 periods of the 35kHz modulated frequency and results in a microsecond value of 570. Such a modulated pulse can be technically easily distinguished from IR radiation of the ambient as the constant frequency of infrared sun light or light bulbs producing 100 (or 120) Hz IR signals. A space is where nothing is transmitted between pulses. The last space is the gap, when it is assumed that the buttons are released or some repetition of the code will start.

Figure 4.2. IR signals

infra red signal

the program mode2 returns a description of this wave. It uses the terms pulse for an infrared oscillation and space for dark. It has a resolution of 1microsecond. If the space gets too long then a maximum value is returned.

To see what comes out of /dev/lirc0 cat /dev/lirc0 > lircsamp.bin can be made and Crtl+Z, ps, kill -9<PID>. A binary file is produced that can be observed with a hex editor. It comes as described in blocks of 4 Bytes, the first 3 Bytes are the length of the pulse/space and the forth Byte is 0 for space and 1 for pulse. To make a custom hardware a good try would be connect it to a ttyS or ttyUSB, the same sequence could be produced and instead of creating a device driver just ln -s /dev/ttyS0 /dev/lirc0 could be made or tell lircd to read from /dev/ttyS0 with the lircd -d option. Hopefully lircd would accepts it.

Lirc receivers

Some simple home-brew receiver designs are available, however those are a hack, and RS232 is on many new computers outdated. Working with RS232 leads often to resources conflicts, especially since those devices do not run on a RS232 to USB converter cable. Since the PC must handle the pulses/spaces of the 38kHz modulated IR signal (creates interrupts), delays due to other tasks running in the computer lead to errors in receiving. Transmitting is more critical since the receiving devices expect a jitter-free timing.

Alternative designs are for USB with micro-controllers or communicate via UDP.

An other alternative is using the sound card and use an audio to LIRC converter. This also has the option to make use of bluethooth audio connection between PC and audio to lirc converter.

Lirc transmitters

Receiving is much less problematic than transmitting. With transmitting the timing must be very precise and jitter free otherwise the devices do not accept the signal. Many simple transmitters put the burden to bit banging bit with a precise timing to the Linux kernel, but the kernels scope is do other things as toggling a single bit once in a while. The result s a jitter in the signal that might be too much for a device to accept. Some simpler HW design change and disable interrupts to assure a good IR timing. This obviously looks critical if the PC is used also for things other than lirc.

A way out of this are transceiver that make use of a small microprocessor that does the timing. Examples for that is the UIRT.

A homebrew serial LIRC receiver

The simple proposed home-brew LIRC receiver (HB) shown on the LIRC web page violates the hardware specifications for RS232 and might not work reliable:

A RS232 signal has a voltage swing from at least -3V to 3V whereas the simple HB-receiver has a voltage swing from 0V to about 9V(= RTS-signal level). Not having a voltage swing that goes below 0V violates the RS232 specification and could create various troubles.

Investigate in more hardware to have good and clean signals will pay back! I have tested and recommend the following clean receiver. Here how to build it, it is according to the following schematics

Figure 4.3. Lirc serial receiver


Figure 4.4. Component side

component side

Figure 4.5. Solder side

solder side

Figure 4.6. Isolation


Here is Lirco the infrared sniffling dog

Figure 4.7. Lirco


The following assumes you have a self made receiver ( connected to the serial port /dev/ttyS0. See to find how to build the hardware.

The driver lirc_serial is required to be loaded. Since this driver accesses the serial port it has to made sure that the serial port is free to be used by lirc. To not cause a conflict the 8250 device driver used for serial ports, the system must know that a port will be used for IR and not as regular serial interface. To disable it and have the port /dev/ttyS0 available for the IR receiver emerge setserial and do setserial /dev/ttyS0 uart none. The program setserial has its configuration at /etc/serial.conf where the uart to be used for lirc can be disabled and therefore reserved. It will run at boot when rc-update add serial default due to etc/init.d/serial. So add to its configuration

/dev/ttyS0 uart none

There are two ways to get it, taking it from the lirc package or recently it might be found in the kernel sources.

To use the kernel drivers delivered with lirc /etc/portage/make.conf has to be edited:


As alternative the lirc_serial driver is required and can be selected in the kernel source (Found at Staging drivers > Media staging drivers > Linux Infrared Remote Control IR receiver/transmitter drivers ). The following assumes you select M and build it as module. This gives the driver ls -l /lib/modules/3.0.6-gentoo/kernel/drivers/staging/lirc/

Maybe they will never make it into the kernel and will disappear since they have quite a big impact to the kernel. Enable IR to LIRC bridge with CONFIG_IR_LIRC_CODEC and cat /usr/src/linux/.config | grep LIRC_CODEC add in /etc/portage/make.conf:


Check if you have the outdated kernel driver delivered from the lirc package with: ls -l /lib/modules/3.0.6-gentoo/misc/lirc*. You might delete it manually since re-emerging does not remove it. After that run update-modules --force so the system knows the correct modules.

emerge lirc

update-modules --force

Then run modprobe lirc_serial for the and the udevadm monitor will show you that /dev/lirc0 is created. Then fuser /dev/lirc0 shows you if the device is attached to a process and prints out the process id. For now it should not return anything since it has to be free, later on the LIRC daemon lircd will occupy it.

If modprobe lirc_serial fails check dmesg, it might be busy. If it is busy due to a shared IRQ, you can try to fix it on hardware side as Bios or you can choose an other one that is supported by the hardware modprobe lirc_serial irq=3 . cat /proc/interrupts shows how they are used. To make this persistent there is /etc/modprobe.d/lirc. Since it comes with the kernel, it is also worth to test it having it included in the kernel, so no modprobe lirc_serial is anymore necessary.

To see that all drivers are loaded lsmod

Finally add lirc_serial to /etc/conf.d/modules to have it automatically loaded during next boot.

To test the lirc hardware and drivers mode2 can be used that prints out pulse and space timing, this works obviously just for IR receivers that do not decode the timing as the serial home brew receiver:


Press keys on your IR remote control to produce space and pulses. there is also the -m option that prints out in an other form that might be interesting for manual created config files.

This is basically the wave form of the infrared signal that arrives. When finished do Ctrl + C

As an alternative the is xmode2 that shows it grafically

If it does not work, it could be the hardware or the software? On the 9pin Sub D shorts between pin1 (signal=DCD) and 5 (low=ground) or 7 (high=rts) produce space then open to produces pulse. If this produces an effect on mode2 than the problem is on your hardware.

Audio receivers and transmitters

To use the sound card as IR receiver or transmitter looks like a hack, but it has some practical applications:

Modern devices lack on hardware interfaces but have a sound cards, instead of a headset a LIRC transceiver can be plugged in.

What comes from the IR receiver can easily be captured as audio wave file and then analyzed using a software as audacity. Since the memory space is on the computer, the maximum recording time is nearly unlimited and this could even work better than using an expensive digital storage oscilloscope.

A hardware is used that is able to deal with a precise jitter free timing.

Ideal receiver for debug purposing of other transceivers

Figure 4.8. IR audio schematics

ir audio

Figure 4.9. IR audio hardware

lirc audio hardware

There are two different audio drivers to choose from audio and audio_alsa.

Audio accesses the soundcard directly and is bypassing alsa. This alternative is just recommended if alsa is not installed or when ir signals need to be sent. Actually both drivers can be installed since the lirc command line tools have the option to select what driver to be used instead of just taking the default one.

To be able to transmit the 38kHz IR signal over the <20kHz audio channel, a trick is done, the sinusoidal signal gets rectified and therefore its frequency gets doubled. To have higher voltage on the IR diodes, the diodes are connected between the two audio outputs that have a phase shift of 180°, this way about 3m can be transmitted, for longer distance extra power is required.


To test such transceiver a special stereo audio signal is needed that has a 180° phase shift. A mono signal will never create a voltage difference between left and right channel. A usual stereo signal will have just very little voltage differences between left and right channel.

Testing IR audio hardware

No ir kernel device driver needs to be added, since it uses the standard sound drivers.

To make the first test with the hardware see if alsa works, For the transmitter aplay /usr/share/sounds/alsa/*. To see if alsa hears sound, plug in into the microphone jack something as an mp3 player. If you hear something is not important, since this might be just audio passing the soundcards mixer. But more important is that the sw can see the sound, so record 5 seconds of arecord -d 5 test.wav and the play it back aplay test.wav

Now test if your lirc audio hardware works. Open two console windows one with alsamixer where you have to set microphone boost to something. The second console is then used for arecord -d 5 test.wav and the play it back aplay test.wav. If you press in front of the lirc receiver an IR remote control and you hear something than it is ok, if not do not worry too much. The next step is important. In alsamixer press F4 to see the capture view, make sure here the microphone is enabled with some boost level. Now specify also a sampling rate and type arecord -d 5 -r 40000 test.wav and press some keys on the remote controller try to record and then play back with aplay test.wav. If you here some key presses then everything is ok with the hardware.


The amplitude of the sound received can be very critical. The IR receiver chip has a digital (DC) output but the audiocard has a AC input. Receiver designs and probably also the motherboard use therefore capacitors to block the DC voltages toward the audio chip. If the capacitors are too small then the signal looses it sharp edges and might not be understood, if the capacitors are too big, then they can bring the signal into saturation when a packed of carrier pulses arrive. Usually the IR chip has in idle condition a high level at its output and therefore the capacitor gets charged. If now such a burst of carrier frequency arrives it looks to the capacitor as there is half high level and therefore the capacitor needs to be de-charged for that. This might take some time. During this time the arriving signal might be driven in saturation and not received at all.

Figure 4.10. Running into saturation

lirc audio saturation

A compromise is therefore required. A good way seems to be lowering the amplitude and using rather bigger capacitors (>=47uF). If the signals arrive the average voltage does not change a lot and the voltage on the capacitors is almost constant. It is recommended to open the recorded wav file with a sw as audacity and check if the wav file does not run into saturation of the AD converter (is chopped off at the bottom and top). If this is the case the lirc sw has troubles to understand and analyze it, so you need to decrease the sound level.

Figure 4.11. Understandable signal

lirc audio

The IR signal is actually 39kHz and to high to be used directly by the audio card, luckily the IR detector chip handles this frequency and produces just a digital signal if this frequency is present or not. More advanced hardware debugging can be made with special wave files that send out continuous pluses and/or carrier frequencies. Using such signals allows easy observation of the signals using a simple oscilloscope.

However arecord and audacity and the soundcard can act also as oscilloscope but with a limited sampling rate (arecord allows sampling rates up to 192kHz, this is a bit misleading, since the analog front-end to the card is just designed for 20kHz signals). Additionally since sound-cards are made for up to 20kHz, analog filtering and audio processing (compressing techniques) might occur and have effect when the IR signal looks different from an audio signal. The lirc audio signals to transmit are quite critical since they contain a 19kHz modulated stereo IR signal.

Audio_alsa Transceiver

To use the audio_alsa driver with gentoo add the following line to /etc/portage/make.conf :



emerge lirc

Commands as mode2 do not seem to work with audio_alsa but you can go directly to create your lirc.config file, however irrecord is quite pedantic in what button names it accepts, so do irrecord --list-namespace first or use use the option --disable-namespace (-n) and record the names you want to use. Make sure the lirc daemon is not running: /etc/init.d/lircd stop before doing irrecord

irrecord -n -d hw@48000 <name of remote> or irrecord -n -d hw@44100,l <name of remote> or irrecord -n -d hw@44100,r <name of remote>

Audio Transceiver

Since audio_alsa does not support sending, the audio driver needs to be used. The drivers in the kernel have also some settings to be made to enable transmitting.

There is also the transmitter useflag to be set.

Then lircd needs to be run, if not type /etc/init.d/lircd start

The following command should show your transmitter device irsend LIST "" "" .

If not there might be a problem with /etc/lirc/lircd.conf, fix it and /etc/init.d/lircd restart The command irsend LIST <name of remote controller> "" should show all possible keys that can be sent.

irsend SEND_ONCE <name of remote controller><name of key> sends the key ones irsend SEND_START <name of remote controller><name of key> sends the key repetitively until irsend SEND_STOP <name of remote controller><name of key>


UDP allows having an non time critical interface to the hardware devices on userspace and have it also available on Ethernet. It uses LIRC_MODE_MODE2 that transmits 4 bytes of data. Unfortunately it can not transmit (there are patches for lirc versions around that allow transmitting, hopefully some patches will make it into the stable lirc tree). When using upd, lircd is started with the command line option as --device=5000 where 5000 is the udp port number.


The simple home-brew devices might work well but they put the burden of detecting the IR signal to the Linux PC. A PC is not made for toggling bits at a precise timing a PC is done for processing data and running programs. This is why microprocessor are used in: keyboards to scan key presses, mice for looking at the spinning wheels or dealing with the opto-sensors, hard-disks and many more.

Therefore devices have been developed mostly on the microprocessor PIC16F84A that communicate with the Linux PC via RS232 and do the IR bit banging stuff inside their firmware. Surprisingly the PIC16F84A has not even a UART and needs to do bit banging also for the RS232. Unfortunately many designs violate the RS232 spec that requires negative voltage for transmitting, they simply use 0 volt instead and hope that it works.

The PIC16F84A is quite an old micro-controller that gets therefore expensively. Modern micro-controllers are cheaper and more powerful hand have definitely an UART.

It seems to be an evolution in those devices that somehow started from IRman that seems to be similar to UIR (Universal Infrared Receiver), then UIRT (Universal Infra-Red Transceiver) got developed, followed by UIRT2 and finally USB-UIRT that has a FT232 chip converting the arriving USB into UART signals.

Unfortunately the story is quite old and information got lost in the open source community. Many links to web pages do not work anymore. The most modern design USB-UIRT is a commercial product.

An other topic is that those devices might support more than one operation modes and Lirc has its own names for that. So its sometimes not clear what lirc driver to be used and if the device is still supported by lirc.


Except USB is used the device make use of the control signals as RTS and DTR. So make sure the RS232 cable has them wired as well. There are a lot for RS232 cables that lack of all 9 wires.

UIR, IRman

Bad news first UIR and IRman support in Lirc is broken and nobody tries to fix it. Good news is that IRman can also be used without Lirc.

UIR is used as a synonym of IRman in the Internet. It is difficult to find the historical reason for that. Maybe the reason is that irman is a commercially available product and therefore a brand-name. UIR stands for Universal Infrared Receiver and this means no transmit support. Unfortunately the UIR sites are outdated, but there is still a lot of documentation around:

Info about UIR

A detailed info in Czech (luckily there is google translate) where the above UIR schematics pop up under Irman (clone)

Lirc has support for irman therefore this section uses the term irman for it (UIR).

Testing a irman device is simple open a terminal as gtkterm and set it to 9600,8,N,1 and no handshake, When irman power up a X should be sent, if garbage arrives then an older SW is used or the reset hardware circuitry is not working nicely. To initialize it, send the characters IR (with some delay of >500ms between I and R. The CR is not necessary. Then it responds with a OK. After that it is ready and decodes incoming signal and sends out what it was able to decode.


This means all what it is not able to decode will not be passed to the host. Subsequent IR will no more produce OK this might cause a blockage when a program gets restarted. The clean way is to reset IRman this is done by toggling RTS to 0 and then back to 1.

When something is decoded the result will be sent out to the PC in 6 Byte binary, so strange characters appear on the console. All bits received create a finger print resulting in the 6 Byte code.

Irman is a bit special when it comes to lirc. Things as mode2 do not work, since irman replaces pulses and spaces with a decoded code. There has to be libirman installed that brings /etc/libirman.conf that has to be edited to link the 6 Byte codes to a button and remote name. Lirc then talks to libirman and no more to the device.

For simple and dedicated applications it is possible to use libirman directly and not use lirc at all.

Libirman comes with test programs that do not run under gentoo linux. The reason is that these are just bash wrapper scripts and call the libirman library and this fails. So download the tar.gz manually and ./configure and then make will do it. Don't use make install so the binaries stay in your temporary directory and cause no conflict with your package management system of your Linux distribution..

./test_io /dev/ttyS0 will initialize Irman (IR string) and IRman responses with OK, then it prints out IR codes until a timeout will exit the program. On a well working environment, it waits forever for new IR codes and therefore Ctrl-Z is the only way to exit.

./test_func /dev/ttyS0 is similar to test_io just the output string is formatted. Those formatted strings are now required to edit the /etc/libirman.conf that has to be renamed and put under /~/.libirmanrc

./test_name /dev/ttyS0 will finally replace the formatted strings with the names from /~/.libirmanrc. When working, it is time to move and rename /~/.libirmanrc to /usr/local/etc/irman.conf to have a system wide setup ./test_name /dev/ttyS0 should now take the system wide setup and still work.


The UIRT is still well documented see The UIRT is upward compatible to UIR and IRman and offers some more features as transmitting. After power up or when RTS goes low and back to high the operation mode can be set, once set it stays within this mode.

It can therefore be tested similar to a UIR or IRman.

For reception there is alternatively to the UIR mode the grab mode that is entered by IG and UIRT responses with OG. In grab mode 22Bytes are sent to the host that now describe the wave form and do no more represent a pseudo random number as in UIR mode.

Finally there is the transmit mode, that can be entered by IT and UIRT response with OT. After that the 22Bytes describing the IR wave form have to be sent, and when sent, UIRT blocks until next RTS off on cycle.

Other modes are: IV returns the firmware version of UIRT ID the debug mode to get timing of the received IR signal, Finally there are also the two modes load config and save config that allow configure the UIR mode.


The publicly documented UIRT2 from is outdated. UIRT2 starts differently from UIRT. However it seems that there were in the past different UIRT implementations and one was similar to UIRT2 but no traces can be found anymore on the Internet). It has a higher baudrate of 115200, it goes directly in UIR mode and everything is binary.

It accepts commands from the host to switch the mode. Simple commands are formed by a command byte plus a checksum (command + checksum =0x00). The so called extended commands contain also data and a length byte to be sent with the command byte (as used for transmitting). After receiving the command the UIRT2 responses with 0x21 for ok, 0x20 for transmitting, 0x80 for checksum error 0x81 for timeout and 0x82 for unknown command.

It supports different modes as:

0x20 0xe0 for UIR

0x21 0xdf for raw receiving mode

0x22 0xde for struct mode

Additionally 0x23 0xdd request the UIRT2 sw version

The raw modes do not much data de/encoding, so it gives a nice work share between little microprocessor taking care about the jitter free bit banging and have the fully blown Linux PC doing the decoding without the need to take care about time jitter.

The command 0x21 0xdf puts the UIRT2 in raw receiving mode. In raw receiving mode it acts similar to the lirc mode2. The first two bytes are the pause (big endian) to the previous IR frame. The a byte containing the pulse with of the first pulse comes, next byte is the the width of the space or if the frame is finished 0xff will be sent as frame delimiter. all numbers have to be multiplied by 50us to get the time.

Sending with raw data works with the 0x36 command and obviously the data to be send must be packed to the command. After 0x36 a byte containing the length of the raw data struct+1 and finally the check sum byte is added that makes the sum of all bytes give 0x00.

The structure of the raw data follows what is received in raw mode, except that an additional Byte will be added at the end, this byte defines the carrier frequency the a number defining how many times the IR signal has to be sent out. UIRT2 response with 0x20 telling that it is transmitting. A drawback of raw transmitting is the limit of maximum 23 pulse/space combinations.


USB-UIRT is similar to the devices above but there are differences. Unfortunately it is just commercially available and therefore the SW is not available.

Setting up and testing the LIRC receiver

For testing any remote controller can be used, however when looking for a device to control the PC running applications as home theaters a programmable IR remote controller supporting multiple devices can be used. Look that it has up/down left/right arrows and an ok button and that they are not used as volume and channel up/down. For the computer use e.g. AUX1 as the LIRC device and if it is a programmable remote controller leave it non programmed, so it takes the default values. If you reset the device, change its battery or buy a second one, the default will stay but any programming will be gone.

Figure 4.12. IR Remote controller

Total remote controller

Make sure the lirc daemon is not running /etc/init.d/lircd stop

You need a configuration file that maps the received ir signals to button identifiers. Either get the contents of the file from

Choosing a remote controller from there might save you some work or if you pick a bad one nothing at all.

Many remote controllers are not suited to be used for your application under Linux since you want to be more flexible and open, therefore check that you have at least some up/down/left/right and ok buttons on the remote controller. Use names for the keys as shown with irrecord --list-namespace or if annoying use irrecord --disable-namespace (or -n). You can easily edit and clean up the names later.

A good approach to spend some time and create some documentation, this helps you later to save some time, so to do:

irrecord --list-namespace > lirckeys.txt

Then open this file with a spreadsheet program and edit it look at your remote controller and decide how to assign names to the keys. Print it out or have it ready on the screen for the next step.

|| pause

[] stop

> play

>> forward fast winding

<< reverse fast winding, rewind

|< replay, back

>| skip, forward

To create your own remote controller file:


or if the protocol is not understood

irrecord -f<file4yourremote>

Three steps are required within irrecord, press the keys irrecord tries to understand the protocol, give a name press the key and irrecord saves up, except for the -f option configure the repeat function.

Copy and rename one of those files as /etc/lirc/lircd.conf. Or better leave them as they are and where they are and make a link:

ln -s <here is the config file> /etc/lirc/lircd.conf

Unfortunately it can happen that irrecord does not create a perfect file. The result can be that keys need to press twice to take effect. This is due to bits that the remote controller toggles when key got pressed twice. irrecord detects also toggle bits but sometimes it struggles with them. If the file is understood by using the documentation as, it can be manually edited.

If you want to use more than one remote control you can simply concatenate the configuration files:

cat<config1><config2> >/etc/lirc/lircd.conf.

To start lircd type /etc/init.d/lircd start whereas /etc/lirc/lircd.conf holds the above gained info about your IR remote controller.

Use irw to deviate output of lircd to the console for debug purposes. When finished do Ctrl + C

Be first happy with your IR hardware before you install too many software applications. Otherwise you will have difficulties debugging the low level stuff.

To automate startup check



and then add it to the rc scripts:

rc-update add lircd default

/etc/init.d/lircd start


alias char-major-61 lirc_driver


/etc/init.d/lircd start

Finally there are sender applications where the pc could act as a remote controller.

LIRC troubleshooting

Lirc is sending out IR signals but the receiving device does not do anything.

Use an audio lirc receiver and record wav files.

A wave file from the original remote controller (e.g. press 2 times the power button within a pause of 1 second)

A wave file sent out by lircd using the same button.

Use audacity to compare the two wave forms. If they are the same but it still don't work, then it might be that both carrier frequencies are not the same. This can be easily fixed by adding

frequency <freq>

to the remote control in lircd.conf file. The frequencies are in the range from 34000 to 44000 where 38000 is the default.

irrecord can not even store in raw format. This can happen on devices as an IR garage door opener,that sends out the infra red signal far different from the rest of the world. Check the signal by producing a wav file using an audio receiver or/and try mode2. If mode2 works, capture a file with a single button press: mode2 > mode2.txt this can be imported in a spread sheet program and the length of the pulse can be measured as 202439 us for my garage door opener. mode2 -m > mode2m.txt produces a similar file that can be edited in a text editor to get a lircd.conf file.

Using v4l2 ir devices under LIRC

Maybe your application supports just LIRC or you want to map the keys to some functions. Drawback is that you can not use the receiver for other remote controllers and your v4l2 remote controller probably has not all the buttons that you would like.

Add to /etc/portage/make.conf


Create a kernel with CONFIG_INPUT_EVDEV as module (Input device support => event interface).

modprobe evdev

cat /proc/bus/input/devices to see which event device the IR input device has.

Get the file from the v4l2 site. Copy this and rename this file to /etc/lirc/lircd.conf as backup and name this file inputlayer.

/usr/sbin/lircd -H dev/input -d /dev/input/event<n>

irw to test.

Linurs Servernest startpage