Notes on building a separate instance of LIRC to control a
satellite receiver or cable box using a simple IR LED
transmitter connected to a serial port on a MythTV system

(note: can be used for ANY set top box supported by LIRC)

jds-myth !at! losdos.dyndns.org
version 2.7 @ 29sep2005
a work in progress(tm)

UPDATE: need a pre-made IR BLASTER? see www.irblaster.info

If you have any comments, corrections, clarifications, suggestions, hate mail, success stories, etc regarding this HOWTO please let me know at the address above.  This way I can make the procedure better and thus hopefully prevent folks from having to spend extra time troubleshooting the configuration.

Introduction

MythTV relies on either an  internal (e.g., PVR250/350) or an external (e.g., cable box, DirecTV, DISH) tuner to select a channel for viewing or recording.  In the case of an internal tuner, the method of channel selection is straightforward as there is a direct electrical connection to the hardware and the tuner API is at least understood if not fully documented.  In the case of an external tuner (hereon in referred to as a receiver or set top box), two methods of control are possible.  First, a hardwired connection between the MythTV system and the receiver can be employed.  Typically this connection uses RS232 as the physical layer, but USB may be used as well.  The hardwired link and an understanding of the receiver's API enable MythTV to issue commands to tune the receiver.   The second method of control is to have the MythTV box, in conjunction with some external hardware, emulate the receiver's remote.  That is, as far as the set top box is concerned, it is receiving commands from the remote that it was sold with.  In this case unidirectional communications are carried via infrared (IR) energy, and the receiver's API again has to be understood to the extent that the MythTV box can issue channel change commands.  Fortunately, the IR protocols used by most receiver manufacturers are either documented or can be readily reverse engineered.

The external hardware needed for the IR solution varies depending on the receiver application and the division of labor.  Regarding the latter, some "smart" IR devices connect to the serial port and do the hard work of converting simple commands ("select channel 100") generated by userland software like MythTV into a sequence of carefully timed flashes emitted by the IR LED.  So in this case, you have relatively expensive external hardware and trivial userland software.  In other implementations, including the one described below, simpler IR hardware is attached to the MythTV system and software is responsible for directly driving the IR LED.  So, as opposed to the aforementioned technique, this method uses a minimum of external hardware however requires more investment in software infrastructure.  Hence, the hardware used below is very inexpensive, but the software to drive it is somewhat more complex.  Fortunately, there is an open source effort dedicated to the software needed to interface with both the smart and simple types of IR hardware -- it's called the Linux Infrared Remote Control (LIRC) project.  Refer to http://www.lirc.org/ for more information on LIRC.

While most DirecTV receivers have rear panel RS232 ports which make interfacing to MythTV trivial, the majority of DISH receivers and cable boxes either lack a documented hardwired control port or the control port has been administratively disabled. For these cases, a simple IR LED transmitter driven by LIRC can be used to emulate the remote and change channels prior to recording.  This HOWTO describes the implementation of this technique, and has specifics for interfacing with DISH receivers.  As will be noted, it is very straightforward to use this implementation to control alternate (i.e., non-DISH) IR-enabled devices.

The following information and procedures assume:
  1. you have a MythTV system built from KnoppMyth R4 or a similarly configured MythTV system.  
  2. you know enough about Linux to do basic configuration, compilation, installation, and troubleshooting.
  3. you know enough about electronics to solder three discrete components and a connector onto a pair of wires.
  4. you have an available serial port on your MythTV box (i.e. COM1 or COM2 is unused).
  5. you have LIRC currently running as part of your MythTV setup (i.e. for a PVR-x50 remote) and you don't want to break it.
  6. you want MythTV to be able to change channels on a LIRC-supported receiver (e.g. DISH) via a simple IR LED transmitter.
First, a little explanation of how the implementation works.  I have borrowed an idea which I came across on the MythTV mailing lists.  The issue is that getting the IR LED transmitter to emit keycodes depends on getting LIRC to do the work for you.  And, that in turn conflicts with having a pre-existing instance of LIRC already running on your MythTV box (e.g., the "OEM" LIRC which comes with KnoppMyth is used to handle input from your PVR-x50 remote).  The solution implemented here is one in which the general purpose LIRC source tree is modified such that a *second* IR LED-specific instance of LIRC can run on the same MythTV box, and handle the task of transmitting keycodes to the DISH receiver via the IR LED.

Thus, the trick is to reconfigure the LIRC source tree and device names such that the second LIRC instance is completely independent of the first, and then set up a system environment to support it.  Credit should go to Robert Wamble (rwraithr !at! iwamble.net) for being the first to implement this method in a general way to support an external remote.  Below, I have simply automated much of the process and simplified some areas due to the fact that the IR LED subsystem does not have to receive anything, just transmit.

Finally, none of the steps below involve recompiling your kernel nor any other drastic measures; in fact, the procedure described by this HOWTO was designed to have negligible impact on your current MythTV and Linux system configuration.

During the course of following the procedure below, it may be useful to refer to the LIRC project documentation at http://www.lirc.org/ and understand the LIRC driver model at http://www.lirc.org/html/technical.html#overview

Aside: Non-DISH receivers

You can adapt the procedure below to send keycodes to ANY infrared-enabled device, not just a DISH receiver; you simply have to obtain or construct the proper /etc/ledxmitd.conf file with directives specific to the device you are trying to control (e.g. cable box, stereo receiver, transmogrifier, etc.).  This is left as an exercise to the reader, however many folks have written to tell me that they have had success with alternate set top boxes.  There are dozens of configuration files for various receivers here: http://lirc.sourceforge.net/remotes/ -- for example, the config file for the ubiquitous Motorola DCT2000 is here: http://lirc.sourceforge.net/remotes/motorola/DCT2000.

Aside: Multiple DISH receivers

There is info at the end of this document which provides some general info on dealing with multiple DISH receivers.

Aside: Linux Kernel 2.6

While this document is generally geared towards the current KnoppMyth distro (kernel version 2.4), refer to this link and to this link, both of which provide pointers regarding compiling LIRC under 2.6.  Also see the troubleshooting section of this document where there are a multitude of user-contributed hints on configuring LIRC and your kernel sources for various distros.  Also, if you are using Fedora FC3 -- which straight out of the box lacks included kernel source code, making compiling LIRC impossible --  you may want to use this writeup to get LIRC to control your set top receiver.

Aside: Using other types of commercial IR Hardware instead of the simple LED transmitter

Jeteye:
This HOWTO (WITH SEVERAL MODIFICATIONS) WILL WORK  with the JETEYE IR transmitter module -- making the modifications are fairly straightforward, but note that I do not have one of these modules and thus can not answer any questions about it's operation nor configuration.  The Jeteye WILL NOT work with DISH receivers as DISH uses a 56KHz IR protocol, but it will work with other receivers that employ a 38KHz IR protocol.

Actisys 200L:
This HOWTO WILL NOT DIRECTLY WORK with the Actisys 200L IR transmitter module -- this device is NOT a simple IR LED transmitter and requires a different LIRC driver than is employed below.  For details on how you might configure a separate instance of LIRC for an Actisys 200L IR transmitter, see Robert's page at http://www.iwamble.net/index2.html.  Alternatively, you can change the "./configure" statement in my script below to cause LIRC to be compiled with the necessary "lirc_sir" driver along with any other necessary parameters.  If you do this and it works, please send me your revised ./configure command.  If you are feeling adventurous you can follow the same process as for the Jeteye -- that should "just work".  The Actisys 200L WILL NOT work with DISH receivers as DISH uses a 56KHz IR protocol, but it will work with other receivers that employ a 38KHz IR protocol.

The Procedure

STAGE 1:

Much of the hard work in stage 1 is done by a shell script, and you just need to follow the directions. All of stage 1 can be done as a normal user up until it comes time to "make install", which will require you to be root.

--> Get LIRC version 0.7.2 from the LIRC download page (http://prdownloads.sourceforge.net/lirc/lirc-0.7.2.tar.bz2):
$ cd ~
$ mkdir myth-ledxmit ; cd myth-ledxmit
$ wget http://internap.dl.sourceforge.net/sourceforge/lirc/lirc-0.7.2.tar.bz2
$ bzip2 -d *bz2 ; tar xf *tar

--> Check what you have now:
$ ls -sl
   4 drwxr-xr-x    8 jds      jds          4096 Nov  7 08:39 lirc-0.7.2
2736 -rw-r--r--    1 jds      jds       2795520 Nov  7 10:16 lirc-0.7.2.tar

--> Cut-n-paste the shell script below and save it as "myth-ledxmit.sh":
OR you can retrieve the file via the following command
$ wget http://losdos.dyndns.org:8080/public/mythtv-info/myth-ledxmit.sh
OR by pointing your browser at
http://losdos.dyndns.org:8080/public/mythtv-info/myth-ledxmit.txt
then changing the extension from .txt to .sh when you save it.

-------- CUT BELOW HERE / SOF------------
#!/bin/bash
#
# myth-ledxmit.sh
#
# by jds-myth !at! losdos.dyndns.org
# portions by rwraithr !at! iwamble.net
#
# for details on how and why to use this script, see
# http://losdos.dyndns.org:8080/public/mythtv-info/MythTV_DISH_IR_LED_TX_via_Modified_LIRC.html
#
set -e
#
#
if [ ! $# -eq 1 ]
then
  echo "usage: $0 lirc-directory"
  exit 1
fi

if [ ! -d $1 ]
then
  echo "error: directory '$1' not found."
  exit 1
fi

rm -rf myth-ledxmit.WIP
echo "$0: Copying lirc source directory..."
cp -r $1 myth-ledxmit.WIP

cd myth-ledxmit.WIP
if [ $? -ne 0 ]
then
  echo "error: unable to cd to 'myth-ledxmit.WIP'."
  exit 1
fi

echo "$0: Moving lirc directories"
mv ./drivers/lirc_atiusb   ./drivers/ledxmit_atiusb
mv ./drivers/lirc_mceusb   ./drivers/ledxmit_mceusb
mv ./drivers/lirc_bt829    ./drivers/ledxmit_bt829
mv ./drivers/lirc_dev      ./drivers/ledxmit_dev
mv ./drivers/lirc_gpio     ./drivers/ledxmit_gpio
mv ./drivers/lirc_i2c      ./drivers/ledxmit_i2c
mv ./drivers/lirc_it87     ./drivers/ledxmit_it87
mv ./drivers/lirc_parallel ./drivers/ledxmit_parallel
mv ./drivers/lirc_serial   ./drivers/ledxmit_serial
mv ./drivers/lirc_sir      ./drivers/ledxmit_sir
mv ./drivers/lirc_sasem    ./drivers/ledxmit_sasem
mv ./drivers/lirc_igorplugusb ./drivers/ledxmit_igorplugusb

# lirc 0.7.2 adders
mv ./drivers/lirc_imon     ./drivers/ledxmit_imon
mv ./drivers/lirc_streamzap  ./drivers/ledxmit_streamzap
mv ./drivers/lirc_cmdir    ./drivers/ledxmit_cmdir
mv ./drivers/lirc_mceusb2  ./drivers/ledxmit_mceusb2

echo "$0: Moving lirc files"
find . -name '*lirc*' -print > lircfiles.txt
for i in `cat lircfiles.txt`
  do
    if [ -f $i ] ; then
    NewFileName=`echo $i | sed 's/lirc/ledxmit/'`
    mv $i $NewFileName
  fi
done

echo "$0: Renaming lirc vars in files"
find . | xargs grep -l lirc > lircvars.txt
for i in `cat lircvars.txt`
  do
if [ -f $i ] ; then
    cat $i | sed 's/lirc/ledxmit/g' > $i.newfile
    mv $i.newfile $i
  fi
done

echo "$0: Renaming LIRC vars in files"
find . | xargs grep -l LIRC > LIRCvars.txt
for i in `cat LIRCvars.txt`
  do
    if [ -f $i ] ; then
    cat $i | sed 's/LIRC/LEDXMIT/g' > $i.newfile
    mv $i.newfile $i
  fi
done

echo "$0: Restoring exec permissions"
chmod +x ./configure ./*.sh

# while the following configure statement makes the default port COM2 (= /dev/ttyS1),
# there are examples later in this document which show how to tell the driver that you
# in fact want to use COM1 (=/dev/ttyS0) instead.

echo "$0: Running configure"
./configure --program-prefix=ledxmit- --prefix=/usr/local/lirc-ledxmit \
  --with-major=72 --with-port=0x2f8 --with-irq=3 --with-transmitter \
  --enable-sandboxed --with-driver=serial

echo "$0: Running make"
make
echo "$0: Complete"

-------- CUT ABOVE HERE / EOF ------------

--> Make myth-ledxmit.sh executable:
$ chmod 755 myth-ledxmit.sh

--> And run it against the LIRC source tree that you just downloaded, un-bzip2'd, and un-tar'd:
$ ./myth-ledxmit.sh lirc-0.7.2

NOTE: Errors during 'configure' or 'make'?  
THIS IS NOT UNCOMMON DUE TO VARIANCES BETWEEN LINUX DISTROS -- DO NOT PANIC!!!     :*)
Read TROUBLESHOOTING LIRC MAKE at the bottom of this document.

--> As a result of successfully running the above script, a new directory called "myth-ledxmit.WIP" will be created, the relevant filenames and variable names etc will be adjusted, the revised source files will have been compiled, and the result will be a LIRC-lookalike that can run without interfering with the original:
$ ls -sl
   4 drwxr-xr-x    8 jds      jds          4096 Nov  7 08:39 lirc-0.7.2
2736 -rw-r--r--    1 jds      jds       2795520 Nov  7 10:16 lirc-0.7.2.tar
   4 drwxr-xr-x    9 jds      jds          4096 Dec  4 14:29 myth-ledxmit.WIP
   4 -rwxr-xr-x    1 jds      jds          2553 Dec  4 14:27 myth-ledxmit.sh

--> Now change into the "myth-ledxmit.WIP" directory:
$ cd myth-ledxmit.WIP

--> And (as root) run make install to copy the files into the proper places:
$ make install

Aside:  All of the newly created LIRC executables are copied by "make install" to a separate tree under /usr/local/lirc-ledxmit.
No MythTV nor Linux configuration files are touched during this process.

STAGE 2:

Now we have to set up the system environment... most of this has to be done as root.

--> The configuration file "/etc/ledxmitd.conf" needs to be created.  This file describes to LIRC the keycode protocol which will be emitted by the IR LED.  For the DISH receivers (e.g. 2700, 2800, 3900, 4700, the newer 301, etc) this file is quite lengthy and will not be reproduced in full here.  For other types of receivers, you have to obtain or construct the proper /etc/ledxmitd.conf file with directives specific to the device you are trying to control (e.g. cable box, stereo receiver, transmogrifier, etc.). 

(Aside: there are many configuration files for various receivers here: http://lirc.sourceforge.net/remotes/ -- for example, the config file for the ubiquitous Motorola DCT2000 is here: http://lirc.sourceforge.net/remotes/motorola/DCT2000)

Partial (edited) contents of the DISH-specific /etc/ledxmitd.conf:

$ more ledxmitd.conf
# this config file is based on the JVC_4700 file, <...snip...>
# I crafted this file using a C program (jvc_raw.c, which was based
# on jvc_send.c). Hopefully you don't need those programs.
# contributed by Karl Bongers (karl !at! turbobit.com)
#
begin remote
name JVC_RAW
flags CONST_LENGTH|RAW_CODES
<...snip...>

To generate this rather long file file you can a) use what i'm using, b) download it from various MythTV-related websites/posts, or c) get jvc_raw.c, compile it, and run it to produce the required info.
Here is a local copy of what I am currently using; I've made no changes from what I downloaded off of the web:
http://losdos.dyndns.org:8080/public/mythtv-info/ledxmitd.conf
Here is the link to the source code tar file which includes jvc_raw.c:
http://www.turbobit.com/software/jvc_send-0.0.4.tgz
As noted in the mailing list post linked to above, it is sometimes the case that various parameters in this file need to be tweaked to compensate for differences in DISH receivers.  See also http://www.turbobit.com/software/jvc_README.txt and http://www.turbobit.com/lirc.html.

Hence, if you are using a DISH receiver, the simplest method is
$ wget http://losdos.dyndns.org:8080/public/mythtv-info/ledxmitd.conf
then move the file to /etc/ledxmitd.conf  and set reasonable permissions
$ mv ledxmitd.conf /etc/ledxmitd.conf
$ chmod 644 /etc/ledxmitd.conf
and proceed onward.

NOTE: Using Fedora?  Special instructions apply right now!  Click HERE for details, and then skip only the next two steps.

--> Create /etc/modutils/lirc-ledxmit, which will be used by update-modules to configure the loadable kernel modules, with the following:  (Does not apply to Fedora)
# this is /etc/modutils/lirc-ledxmit
alias char-major-72 ledxmit_serial
below ledxmit_serial ledxmit_dev
# !!! note DEFAULT is COM2 !!!   how, you ask? see configure statement in myth-ledxmit.sh script above.
# for COM1, simply uncomment the following:
# options ledxmit_serial irq=4 io=0x3f8
# for COM2, do nothing, or uncomment the following:
# options ledxmit_serial irq=3 io=0x2f8

--> Build the new module list, incorporating the above:  (Does not apply to Fedora)
$ /sbin/update-modules

--> Make the char-special ledxmit device:
$ /bin/mknod /dev/ledxmit c 72 0

--> Disable the normal serial port driver:
$ /bin/setserial /dev/ttyS1 uart none     # (or use /dev/ttyS0 for COM1)

--> Install the ledxmit_serial module:
$ /sbin/modprobe ledxmit_serial

--> Confirm all is well:
$ lsmod | grep ledxmit
ledxmit_serial          7104   0
ledxmit_dev             8560   1  [ledxmit_serial]

--> Start up the ledxmit daemon (w/ optional logging enabled for initial debugging):
$ /usr/local/lirc-ledxmit/sbin/ledxmit-ledxmitd -L /tmp/ledxmitd.log
(this starts the deamon ledxmitd which in turn creates a listening socket at /dev/ledxmitd)

--> Check that both ledxmit-related devices are now present and have the proper attributes:
$ ls -sl /dev/led*
   0 crw-r--r--    1 root     root      72,   0 May  4 20:57 /dev/ledxmit
   0 srw-rw-rw-    1 root     root            0 May  4 20:57 /dev/ledxmitd

--> To start the whole operation up every time you boot, use an adder to /etc/init.d/bootmisc.sh:
# < ...add to end of existing bootmisc.sh file... >
# start up custom LIRC to handle IR LED transmission
#
/bin/setserial /dev/ttyS1 uart none     # use this for COM2
# /bin/setserial /dev/ttyS0 uart none   # use this for COM1
/sbin/modprobe ledxmit_serial
if [ -x /usr/local/lirc-ledxmit/sbin/ledxmit-ledxmitd ]
then
  /usr/local/lirc-ledxmit/sbin/ledxmit-ledxmitd
fi
#

n.b.: When you boot your MythTV box, you should see the following as Linux comes up (or in dmesg output):
 ledxmit_dev: IR Remote Control driver registered, at major 72
 ledxmit_serial: auto-detected active high receiver
 ledxmit_dev: ledxmit_register_plugin:sample_rate: 0

STAGE 3:

--> Now onto the HW-end of things:

UPDATE: PRE-MADE IR BLASTERS ARE AVAILABLE AT VERY LOW COST --> SEE www.irblaster.info FOR DETAILS.

The modified LIRC module drives the simple IR LED transmitter by toggling the DTR pin on the serial port.  When DTR [pin 4] is high (usually around 10Vdc), current flows from DTR through the IR LED to GROUND [pin 5], and IR energy is emitted from the LED.  When DTR is low (usually around -10Vdc), current flow is blocked by the reverse biased diodes.

!!! BEFORE YOU SOLDER THE  IR LED INTO THE CIRCUIT PLEASE READ THE FIRST PARAGRAPH OF STAGE 4 !!!

To build an IR LED transmitter, use the info at http://www.lirc.org/transmitters.html, especially http://www.lirc.org/images/simple_transmitter.gif.  The hard part is really just procuring then correctly orienting the IR LED.  The anode (usually longer LED lead) goes to DB9 DTR [pin 4], the cathode (usually shorter LED lead) goes to DB9 GROUND [pin 5]. It does not matter which leg you put the 1Kohm resistor in. The reverse blocking diode (1N4148, 1N914, 1N4001, or equivalent) must be oriented as shown in the picture above, with the cathode (banded end) toward the LED anode.  This blocking diode prevents the sensitive IR LED from being reverse biased past its maximum rating (typically 5Vdc).  I have run informal distance tests with the above configuration, using a Radio Shack Catalog Number 276-0143 "High Output 5mm Infrared LED" in series with a 1K resistor and a 1N4001 diode.  It works to about a meter, but since there are quite a few variables here (e.g. COM port driver current), well "Don't Blame Me" if your setup only goes half a meter.  For what I am doing, a meter is sufficient.  There are web pages (such as the lirc.org site) detailing more complicated IR LED drive circuits should you need greater range, for example http://www.lirc.org/improved_transmitter.html.

Here is a complete list of Radio Shack parts submitted by someone who successfully built the "simple LED transmitter" described in the links above :
Note that using the 3.3Kohm resistor lowers the forward current on the IR LED, thus reducing it's power output as compared to the 1Kohm I used.  Also, the Radio Shack IR LED specified above can safely be driven to 100mA forward current, however your PC's serial port is not capable of sourcing anywhere near 100mA.  My view is that 1Kohm is the lowest resistor value that should be used in the "simple LED transmitter" circuit; using 1Kohm results in a IR LED forward current of about 10mA.  Again, higher forward currents (= greater remote control range) can only be achieved using the more complex IR LED drive schemes.  Contrary to the assertions on some other websites, I don't believe that it's possible to damage your serial port by attempting to draw too much current.  The modern RS232 chips used for PC applications (e.g. the Maxim MAX232 and derivatives) are very robust and employ short circuit protection across all pins.

Here are some user-contributed pictures of their IR LED setups...

Simple IR LED transmitter with stick-on IR LED and components inside DB9 backshell:
http://www.irblaster.info/ir_blaster.jpg  (see http://www.irblaster.info/ for ordering details)

Simple IR LED transmitter built onto a DB9 backshell:
http://losdos.dyndns.org:8080/public/mythtv-info/1-ir_transmitter.jpg

Simple IR LED transmitter on a cable, all prettied up with heat shrink tubing:
http://losdos.dyndns.org:8080/public/mythtv-info/2a-ir_transmitter.jpg
http://losdos.dyndns.org:8080/public/mythtv-info/2b-ir_transmitter.jpg
http://losdos.dyndns.org:8080/public/mythtv-info/2c-ir_transmitter.jpg

STAGE 4:

--> Testing 1 2 3 ... some hints and tips on validating the install:
You may want to start by soldering a REGULAR "visible light" LED in place of the IR-LED.  This way you can observe whether ANYTHING is happening when data is sent through the SW and HW food chain.  If it is not immediately obvious at this point, it is not possible to see the emissions from the IR LED, hence the reason for substituting a visible light LED for testing.  Ordinarily the LED should be OFF.  When data is transmitted the LED should blink ON very briefly.  (While the individual 56KHz pulses are too short to see, the chain of them are integrated quite nicely by the hardware, firmware, and software of your eyes and brain -- so you'll just see a single blip as the data goes by).  Note that if you find the visible light LED is on all of the time, the cause is either reversed connections to serial port pins 4 and 5, or misconnection to the wrong serial port pins.  Revisit stage 3 above and make the right connections.

Alternatively, you can take advantage of the fact that many digital cameras and digital video camcorders are sensitive to IR light.  So, first make a test run: take a working remote control, for example from your TV set, and point it directly at the lens of your camera.  While looking at the LCD display on your camera (do not look through the optical viewfinder!), press the "On/Off"or other button on the remote.  You should see a brief flash the IR energy hits the camera's CCD.  If this test works, it tells you that the camera can detect IR light and you can then employ it to help test whether the simple IR LED transmitter is working.  Follow the troubleshooting hints in the paragraph above. 

--> Next, you can enable realtime viewing of  the log from the ledxmitd process as follows:
In a prior step in stage 2 above, you ran "ledxmit-ledxmitd" with the debugging flag "-L /tmp/ledxmitd.log" which enabled log output of the ledxmit instance.  So now you can
$ tail -f /tmp/ledxmitd.log &
and you can see what is going on while the setup is in operation. 

--> With the logging enabled as above, send a single keycode:   ("Give me one ping, one ping only." -- THFRO)
$ /usr/local/lirc-ledxmit/bin/ledxmit-irsend SEND_ONCE JVC_RAW 2
You should see messages as such:
May  4 22:32:04 mythtv ledxmitd 0.7.2: accepted new client on /dev/ledxmitd
May  4 22:32:04 mythtv ledxmitd 0.7.2: removed client
And of course the visible LED should blink ON briefly, OR if you have an IR LED in the circuit the DISH receiver should react to the number "2" being sent.

--> The following shell command will cause the IR (or visible LED) to blink every second until <ctrl-c> is pressed.   This is useful for trying to measure the maximum distance that the IR LED will operate the receiver at, or for debugging other problems.
$ while [ 1 ]
  do
  /usr/local/lirc-ledxmit/bin/ledxmit-irsend SEND_ONCE JVC_RAW 2
  sleep 1
  done
Either the visible LED should be blinking at ~1Hz, OR if you have an IR LED in the circuit the DISH receiver should be receiving a "2" once per second.

STAGE 5:

--> Getting MythTV to change channels (i.e. send multiple character keycode data back-to-back via the IR LED) now simply requires a small shell script parser as such:
#!/bin/sh
REMOTE_NAME=JVC_RAW
for digit in $(echo $1 | sed -e 's/./& /g'); do
  /usr/local/lirc-ledxmit/bin/ledxmit-irsend SEND_ONCE $REMOTE_NAME $digit
  sleep 0.4  # note, you may have to tweak the interdigit delay up a bit, depending on your DISH receiver model
done

--> Save the simple script above as "change_chan.sh", place it /usr/local/bin, and then make it executable:
$ mv change_chan.sh /usr/local/bin
$ chmod 755 /usr/local/bin/change_chan.sh

Regarding the "sleep" statement in the script above -- not all models of receivers can digest keycodes at the same rate.  There must be some interdigit delay or you could have problems with missed digits when changing channels.  My receiver sometimes misses keycodes at 0.2 second delay, but I have never seen a problem at 0.3 seconds.  Thus, I use 0.4 seconds just to be safe.  For a 3 digit channel selection, that costs an extra 300ms when changing channels -- not a big deal.

Now you should be able to run
$ /usr/local/bin/change_chan.sh 123
and the DISH receiver should react accordingly -- that is, the results should be exactly as if you had pressed "1 2 3" on the remote control keypad.  If this does not happen, do not proceed.  Back up and find out what the problem is.  If you can't change channels via the command line, there is no way that MythTV is going to be able to do it automagically.

The script above will be the executable that you call from within MythTV; remember to use the full pathname "/usr/local/bin/change_chan.sh" when you enter it into the MythTV dialog box.  To get to the proper dialog box you must exit from MythTV, then run "mythtv-setup", and finally navigate to the "input connections" section.  Also, when you put the script into the box, enter it exactly as I have shown.  MythTV will take care of appending a space and the target channel number when it spawns the script.

IMPORTANT NOTE #1:
MythTV will not use your newly entered change channel script until you restart the myth-backend process. I've seen that some other folks on the mailing lists have observed that their change channel script works fine from the bash command line but not from within MythTV.  The solution is to enter the info into the dialog, back out of mythtv-setup, and then restart myth-backend as follows :
# /etc/init.d/mythtv-backend restart

Now start the MythTV GUI up.  At this point, MythTV should be in full control of your set top box.  Each time you change the channel from within MythTV, your change channel script will be executed with the desired channel as the first parameter to the script.  The external receiver should follow along accordingly.  Congratulations!

IMPORTANT NOTE #2:
Some folks have noticed that, on occasion, the receiver "misses" digits from MythTV.  This of course leads to erroneous recordings.  There are three general causes of this problem: 1) transmitter to receiver distance too far, 2) transmitter to receiver distance too short, and 3) poor interbit timing due to other system activities.  The first two are generally easy to rectify.  If the LED signal reaching the receiver is too weak, methods to increase LED power output are available via more complicated transmitter circuits.  On the other hand, if the LED is too close, it can overdrive the IR photodiode in the receiver.  This is an unusual circumstance but can be easily rectified in the simple LED transmitter circuit by increasing the resistor value.  Finally, solving the problem of poor interbit timing requires a few paragraphs to explain.

Keycodes are transmitted from the LED to the receiver in a manner analogous to Morse code.  A concatenated series of 1's and 0's are sent, and the receiver interprets and validates these bits as a keycode.  And, as with Morse code, the receiver has an expectation regarding the rate at which these keycodes are sent.  For DISH receivers, that rate is nominally 56KHz, plus or minus several percent to allow use of  inexpensive crystal or RCL-based oscillators in the remote control.  At 56kHz, the bit-to-bit time is approximately 18uS.  What happens then if the MythTV box sends a few bits, then has to perform some other activity (disk I/O, for example) which delays the transmission somewhat, and then finally gets around to sending the rest of the bits?  The receiver interprets the first few bits, but then times out waiting for the remaining bits.  It discards the received bits and returns to waiting for start-of-keycode synchronization. Then, the second batch of bits arrives, and again the receiver times out waiting for the remaining bits.  Finally, the receiver returns to waiting for start-of-keycode synchronization.   In networking circles the discarded bits are referred to as a "runt" packet, and that's pretty much exactly the situation we have here.   We end up with two runts worth of discarded bits, and the result is that the transmitted keycode has been missed by the receiver.  Or, in some instances, the receiver incorrectly interprets a runt as a valid keycode, however it's a different keycode from what was intended.  So you may see that MythTV has seemingly pressed the "Menu" button or some such nonsense.

The root of the problem lies in the fact that Linux is first and foremost a multitasking operating system, and a non-realtime one at that.  This means that scheduling of most userland activities is done on a time sharing basis, which (due to high CPU clock rates) gives the illusion that the machine is doing more than one thing at once.  It is not, however.  As noted above, the ledxmitd process can be preempted temporarily due to other processes contending for CPU time.  (As an informational note, some kernel and userland functions can be programmed to be "atomic" -- that is, they have a temporary monopoly over the CPU and will not be interrupted in the middle of what they are doing.  Generally, this is done to maintain data structure coherency or to prevent task synchronization and race condition issues.  One example is low level network driver code -- it's important that the act of copying data from the network adapter to RAM not be interrupted by a process that may be trying to read that exact same memory area.  If that were to happen the reading process may end up with half new bits and half old bits.  I'm not going to discuss the related problems of interrupt handling, but suffice to say that deleterious effects of interrupts on timing-sensitive processes are for the most part the same.)

Hence, oftentimes the problem of missed digits (and similar anomalies) is the result of interbit timing violations caused by the ledxmitd process being interrupted by other processes running on the MythTV system.  So the question remains, what can we do to resolve the problem?  One method, which is simultaneously the most direct and easiest to implement, is to raise the priority as which the ledxmitd process runs at.  The higher priority has the effect of increasing the affinity of the scheduler to the process, and this will result in more deterministic interbit timing (within reason, bounded by the Linux scheduler algorithms).  Basically, you are telling the scheduler, "unless there is something even more important to do, do this", rather than "all these processes are equal, and share CPU cycles among them". 

Programmatically, this is easily implemented at boot time by editing the startup script (see end of Stage 2) to read as follows:
if [ -x /usr/local/lirc-ledxmit/sbin/ledxmit-ledxmitd ]
then
  nice --15 /usr/local/lirc-ledxmit/sbin/ledxmit-ledxmitd
fi

Also, without rebooting, you can first find the process ID (PID) of ledxmit-ledxmitd using
$ ps -C ledxmit-ledxmitd
and then (as root)
$ renice -15 PID_OF_ledxmit-ledxmitd_PROCESS
this will lead to an immediate increase of priority to the ledxmit-ledxmitd process.

The highest priority available is -20.

nb: man nice && man renice.

NON-IMPORTANT NOTE:
Just as an aside, you can send a "select" after the last digit (i.e., after the "done" statement above), and that *may* decrease the time it takes to change channels. Upon receipt of the "select", the receiver knows that no additional digits are forthcoming and can immediately jump to the channel instead of having to wait to time out.  I don't use this approach as my time out period is pretty short, but others may find sending the "select" useful.  In addition, you can implement other features as well.  For my recording purposes, I use a slightly more complex channel change scenario which looks like this::

$ cat /usr/local/bin/dish_chan.sh
#!/bin/sh
# SCRIPT 1: change the channel
#
REMOTE_NAME=JVC_RAW
for digit in $(echo $1 | sed -e 's/./& /g'); do
    /usr/local/lirc-ledxmit/bin/ledxmit-irsend SEND_ONCE $REMOTE_NAME $digit
    sleep 0.4  # note this may have to be adjusted up for some models
done
/usr/local/lirc-ledxmit/bin/ledxmit-irsend SEND_ONCE $REMOTE_NAME select
#
# asynchronously display the program info screen
if [ -s /usr/local/bin/dish_info.sh -a -x /usr/local/bin/dish_info.sh ]
then
  /usr/local/bin/dish_info.sh &
fi


$ cat /usr/local/bin/dish_info.sh
#!/bin/sh
# SCRIPT 2: display the info screen
#
REMOTE_NAME=JVC_RAW
# wait for mythtv to begin recording
sleep 1
# now display the info screen for N seconds
/usr/local/lirc-ledxmit/bin/ledxmit-irsend SEND_ONCE $REMOTE_NAME info
sleep 5
# and cancel back out of the info screen
/usr/local/lirc-ledxmit/bin/ledxmit-irsend SEND_ONCE $REMOTE_NAME cancel


The first of the above pair of scripts changes the channel, and then the second displays the "INFO" overlay screen for a brief period (5 seconds) to assist the viewer in identifying what program was taped or provide a record of other information (air date, episode, cast, etc.).  You'll note that the second script is run with the ampersand (&), which puts it in the background and allows dish_chan.sh to complete.  This is so MythTV can begin recording before the info screen is displayed.  Note that I don't use MythTV to watch live TV; instead I only record with it.  If you use MythTV to watch live TV, you will not want to use the above "two-step" approach as it very much lengthens the time that it takes to surf among channels.  To minimize latency when using MythTV to surf, tweak the "sleep" statement as low as you can get it, and send a "select" (or "enter" for some receivers) after sending the final digit of the target channel.

STAGE 6:

Have a beer or two and watch your Linux box control your DISH receiver via the IR LED.


ps1:  The astute reader will notice that a clever use of "grep ^$" against this document, followed by a touch of "sed s/$ //g", will result in a shell script which will do everything described above in one fell swoop with the exception of constructing the myth-ledxmit.sh script and synthesizing several config files.  I had considered adding a link to this generated script but there is a lot that could go wrong here and running a script as root without error checking poses some hazards to the continued welfare of your system.   You have been warned.  :^)

ps2: original link, in case you print this out and want to come back here:
http://losdos.dyndns.org:8080/public/mythtv-info/MythTV_DISH_IR_LED_TX_via_Modified_LIRC.html

ps3: version history
1.0 initial relase.
1.1 lots of edits to clarify process and fix wording.
1.2 fixed out-of-order operation with "/bin/setserial /dev/ttyS1 uart none" coming after modprobe.
1.3 added jpegs of IR hardware and included alternate channel change/display method.
1.4 added information for using alternate (non-DISH) receivers, inclding links to LIRC config files..
1.5 tweaked myth-ledxmit.sh to accommodate LIRC version >= 0.7.0pre7.
1.6 added link to mysettopbox thread regarding unpacking kernel sources in the event of configure or make problems.
1.7 added info on restarting myth-backend after entering change channel script into the myth dialog (thanks mike).
1.8 added notes regarding increasing the priority of the ledxmit process.
1.9 added note about specifics of unpacking the kernel under KnoppMyth R4V5. (thanks marty).
2.0 tweaked myth-ledxmit.sh to accommodate LIRC version >= 0.7.0pre8. (thanks dan).
2.1 UPDATE: need a pre-made IR BLASTER? see www.irblaster.info
2.2 updated to reflect the release of LIRC 0.7.0, errata on linux kernel version 2.6 (thanks jon), and notes on controlling two DISH boxes (thanks mark).
2.3 updated to provide all kinds of hints regrading building LIRC on different distros (thanks mark and dave) and some jeteye hints (thanks len and jon).
2.4 added info on using a digital camera as an IR detector suited for troubleshooting (thanks mike).
2.5 added info pointing toward Fedora FC3-specific writeup which resolves the "no kernel source code" issue (thanks andy).
2.6 added Gentoo-specific info to troubleshooting section (thanks dan).
2.7 updated to reflect lirc 0.7.2 (thanks todd).


APPENDICES FOLLOW

Troubleshooting, Distro-specific info, and other miscellaneous tidbits

Notes for troubleshooting LIRC make

It is unfortunately fairly common that the LIRC make fails.  In most cases, this is due to the fact that the kernel sources are either not installed or they are installed but not configured correctly.  Nevertheless, these issues need to be fixed before you can proceed... and once you do get your kernel source configured correctly, be sure to start fresh with a virgin LIRC tree rather than attempting to continue with a previously aborted make attempt.

KnoppMyth R4V5/R5Vxx/Debian:
1) With a right-off-the-CD install of Knoppmyth R4V5, you will very likely have to upack the kernel source files
as root:
   # cd /usr/src
   # rm linux
   # bzip2 -d linux-2.4.25-chw.tar.bz2
   # tar xf linux-2.4.25-chw.tar
   # ln -s linux-2.4.25-chw linux
   # cd linux-2.4.25-chw
   # make oldconfig dep
Now delete the WIP working directory and start the myth-ledxmit.sh shell again against a virgin LIRC directory.
2) Also, you may want to read this thread regarding unpacking your kernel sources:
    http://mysettopbox.tv/phpBB2/viewtopic.php?p=11542
3) Trying out the new R5VAxx.x versions of Knoppmyth? See this post:
    http://mysettopbox.tv/phpBB2/viewtopic.php?p=25946#25946

Gentoo:
1) Insert the following into the myth-ledxmit.sh shell script right above the "configure" line:
   # Gentoo mods
   libtoolize --copy --force || die "libtoolize failed"
   sed -si "s|/usr/src/kernel\-source\-\`uname \-r\` /usr/src/linux\-\`uname \-r\` ||"\
         acinclude.m4 aclocal.m4 configure || die "/usr/src/linux sed failed"
   export WANT_AUTOCONF=2.5

Fedora FC2, FC3, others:
0) Using FC3? (i.e, no kernel sources included) Go here for a writeup which doesn't require compiling a second instance of LIRC.  See also this thread.
1) Installing kernel sources
This is for the current FC3 build 2.6.9-1.681_FC3, change version as needed:
as root:
   # rpm -ivh http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/SRPMS/kernel-2.6.9-1.681_FC3.src.rpm
   # tar -xjvpf /usr/src/redhat/SOURCES/linux-2.6.9.tar.bz2
   # cd /usr/src/redhat/SPECS
   # rpmbuild -bp --target noarch kernel-2.6.spec
   # ln -s /usr/src/redhat/BUILD/kernel-2.6.9/linux-2.6.9 /usr/src/linux-$(uname -r)
   # cd /usr/src/linux-$(uname -r)
   # make oldconfig
   # make include/asm
   # make include/linux/version.h
   # make SUBDIRS=scripts
Now delete the WIP working directory and start the myth-ledxmit.sh shell again against a virgin LIRC directory.
2) libtool: unrecognized option `--tag=CC'
The reason for this is that the shell script myth-ledxmit.sh changes the LIRC configuration, which in turn forces automake to run again. When automake runs, it calls the system version of libtool for configure to use. The problem is that lirc is packed with an older version of libtool that gets used when you run make. So, an old version of libtool is being run from a script generated by a newer version. The solution?
In the lirc source directory:
/home/mythtv/myth-ledxmit/lirc-0.7.2 or whatever yours happens to be
   # libtoolize --force
This replaces the libtool version that's with the lirc source to be linked to the system libtool. Now when automake runs, it calls the system version rather than the source version.
3) unresolved symbols when compiling LIRC
try this:
   # export MYKERNEL=`uname -r`
   # apt-get --reinstall install kernel-source#$MYKERNEL
4) unresolved symbols when modprobe'ing LIRC
try using the latest CVS version of LIRC rather than 0.7.2; there have reportedly been some fixes to address this problem:
[root@localhost etc]# /sbin/modprobe ledxmit_serial
WARNING: Error inserting ledxmit_dev (/lib/modules/2.6.9-1.681_FC3/misc/ledxmit_dev.ko): Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting ledxmit_serial (/lib/modules/2.6.9-1.681_FC3/misc/ledxmit_serial.ko): Unknown symbol in module, or unknown parameter (see dmesg)

[root@localhost etc]# dmesg
ledxmit_dev: Unknown symbol copy_to_user
ledxmit_serial: Unknown symbol copy_from_user
ledxmit_serial: Unknown symbol ledxmit_unregister_plugin
ledxmit_serial: Unknown symbol ledxmit_register_plugin

SUSE, others:
1) See note above regarding libtool.

Other misc notes on building LIRC:
1) Run the following simple test using an unmodified LIRC tree:
   $ mkdir tempdir
   $ cp lirc-0.7.2.tar tempdir
   $ cd tempdir
   $ tar xf lirc-0.7.2.tar
   $ cd lirc-0.7.2
   $ ./configure --with-major=72 --with-port=0x2f8 --with-irq=3 --with-transmitter --enable-sandboxed --with-driver=serial
   <...lots of configure messages...>
   $ make
   <...lots of make messages...>

Does that run clean through ok? If not, you very likely have a problem with your system's kernel source files vs LIRC (or something along those lines).  This test is independent of anything other than LIRC and your system, and if it doesn't work you will not be able to proceed with the procedure documented here.

Notes for Fedora FC1/FC2 users  (courtesy of pete, tyrstag !at! earthlink.net)

There is no /etc/modutils/* in Fedora -- instead, add these lines to /etc/modules.conf:
# Module for IR out
alias char-major-72 ledxmit_serial
below ledxmit_serial ledxmit_dev
options ledxmit_serial irq=3 io=0x2f8  # shown for com2; for com1 use: "irq=4 io=0x3f8"
pre-install lirc_serial /bin/setserial /dev/ttyS1 uart none  # shown for com2; for com1 use: "/dev/ttyS0"
There is no /sbin/update-modules either -- so then
# /sbin/depmod -a

NOTE: IF YOU ARE USING FEDORA FC3, READ THIS FC3-SPECIFIC WRITEUP.

Notes for Multiple DISH receivers (courtesy of mark, MarkRShirley !at! eaton.com)

Note: See also this howto... http://www.lircsetup.com/lirc/multi/index.php

DISH receivers can be programmed to respond to unique "personality codesets" emitted by the remote.  This allows two or more receivers to be controlled by MythTV for simultaneous recording or watching live TV.  Here are some notes:

ASSUMPTIONS
This document assumes you already have installed lirc, and have a working lircd module running.  This will only change the lircd.conf file found in /etc (or /etc/ledxmit.conf as noted the parent document above).  The JVC_RAW file found at www.lirc.org is suitable for any shipped receiver using codeset #1 as is.  If you don’t have a reason to change the code, IE, you don’t have two or more  receivers in the same room, or aren’t attempting to utilize two or more UHF receivers in the same house, then don’t change the codeset and just use the provided JVC_RAW.   If you do have a reason to change codesets, either because you want to control more than one receiver in the same room, or need to control a receiver with a codeset other than #1, proceed.

PROCEDURE
Download the jvc_send-0.0.4.tgz archive from www.turbobit.com/software and untar it to a location for work.  The jvc_send.c file in the archive is what we use to generate the config file we need for each receiver codeset. 
The portion of the file that looks like this:
Lookup lookup[] = {
  {"tv/video",      0x000000000000A3FF},
  {"power",         0x000000000000F7FF},
  {"menu",          0x000000000000D3FF},
  {"page_up",       0x000000000000C3EF},
  {"page_down",     0x000000000000E3EF},
  {"guide",         0x000000000000AFFF},
  {"pointer_up",    0x00000000000097FF},
  {"pointer_left",  0x0000000000008FFF},
  {"pointer_right", 0x0000000000009FFF},
  {"pointer_down",  0x00000000000087FF},
  {"select",        0x000000000000BFFF},
  {"recall",        0x00000000000093FF},
  {"info",          0x000000000000FFFF},
  {"view",          0x000000000000A7FF},
  {"cancel",        0x000000000000B7FF},
  {"sys_info",      0x0000000000006FFF},
  {"record",        0x00000000000083FF},
  {"1",             0x000000000000EFFF},
  {"2",             0x000000000000EBFF},
  {"3",             0x000000000000E7FF},
  {"4",             0x000000000000DFFF},
  {"5",             0x000000000000DBFF},
  {"6",             0x000000000000D7FF},
  {"7",             0x000000000000CFFF},
  {"8",             0x000000000000CBFF},
  {"9",             0x000000000000C7FF},
  {"0",             0x000000000000BBFF},
  {"*",             0x0000000000006BFF},
  {"#",             0x00000000000067FF},
  {"", 0} };
contains the codeset information.  The information in jvc_raw.c as downloaded will produce the raw codes for codeset #1.  All you need to do is change the hexadecimal code for each function to the function for whatever codeset you wish to use.  In my case, I used codeset #9, which changes the last two bits above from FF to BF, except on page up and page down, which becomes AF.
Make your changes to the file as appropriate, and save the changes.
Then compile the jvc_raw.c file as follows:
  gcc –o jvc_raw_9 jvc_raw.c
which gives you a binary file jvc_raw_9.
Now make it executable:
  chmod a+x jvc_raw_9
and execute the file:
  ./jvc_raw_9 > JVC_RAW_9
which should dump the output of the file into another file JVC_RAW_9
edit the file JVC_RAW_9 and make sure everything looks ok.  If it does, copy that information to the end (concatenate) of your existing /etc/lircd.conf file.
Now edit the /etc/lircd.conf file and give the new remote definition  a different name than
The remote used in the original JVC_RAW file.  I use JVC_RAW_1 for the first remote definition, and JVC_RAW_9 for my second remote definition.  Save the file.
Now stop the lircd daemon as root (su):
  killall lircd
And restart it:
  lircd
Lircd should now have the remote definitions for both remotes.  Now make a copy of your script for changing channels for whatever program you use (I use mythtv) and change the remote definition to the second codeset, and save it as a descriptive file.  I used change_channel_lircd.pl in the mythtv contrib directory.  First I renamed the file to something descriptive, which in my case, was 4700channel.pl, since I have one model 4700 receiver.  I edited 4700channel.pl to use JVC_RAW_9 as the remote definition, and saved the file.  I then saved a separate copy of change_channel_lircd.pl as 1000channel.pl
And edited the file to use the JVC_RAW_1 remote definition.  This will operate my model 1000 reciever using the #1 codeset.  Note you’ll also need to modify both of the change channel scripts to add the 4th digit that these receivers use.  A quick look at the script will show what changes need to be made.  Just follow convention and it’ll work fine.
Now copy both channel scripts to your script directory:
  cp 4700channel.pl /usr/local/bin
  cp 1000channel.pl /usr/local/bin
To complete the installation, go into your application and add the scripts to the input connection for each card that the receiver is hooked to.  I use a pvr250 hooked to my 4700 box, and a WinTv401 hooked to my 1000 box.  I added the relevant script path to the input connection for satellite on each card respectively.  Make sure you have the right script entered in the right card location, or you will change channels on the opposite receiver than you intended when mythtv calls for a channel change.
This completes the software side of the configuration.

HARDWARE
First you need to change one of your receiver’s codesets to #9 (or whatever you used in jvc_raw.c)
To do this, enter the system information screen on your receiver, and then hold down the satellite mode button until all four buttons light up dimly.  Then press  9,  then #, wait for the three flashes! Then hit record to complete.  The system info screen should now show the receiver address as #9.  This procedure needs to be right in front of your receiver so that the remote AND receiver have the same code.  It might make sense to pull the card or remove the power from the second receiver if it’s already in the room and connected.
Power up or replace the card for the second receiver and verify that changing channels on the #9 box does NOT change the #1 codeset box.  If not, you have successfully completed the codeset change.
Now you need to add a transmitter diode to your homebrew lirc transmitter and put one diode in front of each receiver.  The diodes should be in parallel.  There is no orientation to the diodes, they will be transmitting the same thing at all times.  Only the box that matches the codeset being transmitted will change channels.
That’s it!  Open a cold beverage of your choice and enjoy multiple dish boxes on mythtv in one room with only one lirc instance!
Good luck!


Notes for using JETEYE IR transmitters (courtesy of len, stolwyk !at! look.ca /and/ jon, jmarkevich !@! gmail.com)

1) Change the driver in the script myth-ledxmit.sh to "--with-driver=sir" prior to running it.
2) During setup in stage 2, change all occurences of ledxmit_serial in system files/commands to ledxmit_sir.  e.g, /etc/modutils/lirc-ledxmit should contain:
   # this is /etc/modutils/lirc-ledxmit for the jeteye
   alias char-major-72 ledxmit_sir
   below ledxmit_sir ledxmit_dev
   # !!! note DEFAULT is COM2 !!!   how, you ask? see configure statement in myth-ledxmit.sh script above.
   # for COM1, simply uncomment the following:
   # options ledxmit_sir irq=4 io=0x3f8
   # for COM2, do nothing, or uncomment the following:
   # options ledxmit_sir irq=3 io=0x2f8

NOTE: THE JETEYE DOES NOT SUPPORT THE 56KHZ IR PROTOCOL USED BY DISH RECEIVERS. 
MOST OTHER TYPES OF RECEIVERS USE A 38KHZ IR PROTOCOL COMPATIBLE WITH THE JETEYE.