Archives

News

Latest: added a version that compiles with 2.6.27 kernels.
Latest: if you are packaging this, see the note at the bottom as to why I don’t provide a simple patch.
Latest: added an updated version that compiles with 2.6.24 kernels, tested against 2.6.23.12
Latest: updated `firmware` to a later revision from hauppauge (743 codesets)

HOWTO

This is not for the MCE version of the PVR-150. This includes a USB unit which does not work the same way as the normal PVR-150, use standard lirc (and lirc_mceusb) for that.

Use a recent kernel (note: the ivtv drivers have been part of the mainline kernel for a good number of revisions so no external drivers are required — sorry, I don’t know off hand which revision they were merged in), or for older kernels install ivtv-0.4.2+ (from this page). Earlier versions of ivtv _are not supported_.

Get the pre-patched lirc 0.8.5-CVS-pvr150 tarball. There are also earlier versions that can be found here, should you want them. The previous revision may be required for kernels < 2.6.27 (as it is untested on lower revisions -- in theory it should work)

You need the dialog package installed to use the lirc configuration GUI, so install that (apt-get install dialog, yum install dialog, whatever is appropriate for your distribution).

IR blaster only: Now you need the ‘firmware’. This is a set of data blocks that correspond to those generated by the windows software. This goes in /usr/lib/hotplug/firmware on my debian system. Depending on your system this might also be /usr/local/lib/firmware, /lib/firmware or /lib/modules.

Note that the entire firmware is kept in memory (currently 300K) so this makes the driver quite large. (I have no plans to sort this out, memory is cheap).

This means that the driver has detected and initialised the IR blaster hardware — if you don’t see that then let me know.

You need to configure lircd, and find out which codeset you are going to be using. The easiest way is to start with this configuration file which contains key definitions for everything in the database. Do not use other lirc configuration files for specific STBs — these simply will not work. The IR chip is only capable of sending those codes which are in the database.

Start lircd. Note: if you are using a static /dev, you may need to make a device for lirc. If unsure, once you have verified that the module has been loaded ok, run ls -l /dev/lirc*. If you don’t see a /dev/lirc0 or similar, then try mknod /dev/lirc0 c 61 0 if the steps below fail.

You can now check if the remote is working using irw. Run this, and press buttons on the remote. You should see some output like

0000000000001795 00 Down Hauppauge_350.

Next, for the ir blaster you need to work out which codeset to use, this is the tricky bit. For this I have send_power_new, a script that just sends the power command in every single codeset. You may find your codeset number listed here if you are lucky.

Firstly, check that you are seeing the IR blaster blink. If you don’t have blinking lights at this stage, your cable probably isn’t in the card properly (try wiggling it around), or it may be broken.

Next you need to stick the IR blaster on the IR receiver of box that you intend to control, being quite careful to position it correctly — it has a very short range (a few cm) and took me a couple of goes to get right. The best way to do this is to find the IR demodulator on the box — easiest with a torch. Note that this is _not_ the light that comes on when you press a button on the remote, they tend to look like this.

If you can’t get this to work, please try and check it against the Windows driver if possible. If your device will work with the windows driver but not my driver, then it’s a driver bug that I should be able to fix. If it does not work with the Windows driver either then your only options are to use a different IR blaster or bug hauppauge until they add support for the box you are trying to control. At that point, I can update my
database too.

Once you know which codeset you want you can go and delete all of the rest from lircd.conf. They are named “XXX_key” so should be pretty easy to find. I also gave the keys standard names (0-9).

To get mythtv to work, configure a channel change script for your device. There’s one here that should work out of the box if you
rename the number keys.

If you’re happy, you can always send me beer money. If not, add comments at the bottom

That’s it, good luck!

Packaging

The lirc distribution tarball is generated using `make dist-bzip2` which uses the gnu autotools to generate a configure script, and Makefile.in, etc. The contents of these generated files depends very much on the version of autotools that is installed; this varies from distribution to distribution. I don’t have the same auto* as the lirc maintainers, so producing a patch file against a distribution tarball makes a patch bigger than the original source archive. Hence I don’t bother; I just make a new dist bzip2 and drop it here.

I maintain the code by importing a current lirc CVS into a subversion repository hosted on this server. I tag each lirc import, generate a diff from the previous lirc import and apply it to my source tree, then port any fixes from lirc_i2c.c to lirc_pvr150.c, test, and generate a new .tar.bz2. To get the source tree you can do:

I noticed that there’s a new IRBlasterWizard on the Hauppauge website as of Oct 2007 that claims to support 50 new devices, and since I can’t seem to get my BEV 4100 to work, I was wondering if we can get those new codesets? My card (actually an HVR1600) is in a Linux-only box at the moment, but if neccessary, I might be able to find some windows hardware to move it to and help the process…

With the modifications from that patch I was able to compile, but the module won’t load. modprobe lirc_pvr150 gives:
[ 2686.524689] lirc_pvr150: no symbol version for lirc_register_plugin
[ 2686.524691] lirc_pvr150: Unknown symbol lirc_register_plugin

Dear Mark,
I’ve been using your pvr150 module for months, and it’s great, but after an update to kernel 2.6.26, I can’t get it to compile anymore. It complains about a missing autoconf.h, due to a different kernelsource layout??

I was wondering if the ir-blaster firmware has been updated to include all of the codes that are in the ir-blaster setup version 6 from hauppauge? If not, is there any way to get the codes from this version?

Sorry for the massive delays in getting around to this, I’ve been quite a bit side tracked. The good news is that work is being done to get lirc+this driver in the mainline kernels, so hopefully things will all work out of the box for people in future.

Not sure the right place for this, but I’m hoping you can point me in the right direction. My running Mythbuntu 8.10, trying to get lirc running with my pvr-150. Actually, I got it working, sending and receiving, except…

My satellite receiver is a Dish Networks 3xx. That means the codes used for the blaster start at 2156396544. These codes cause lircd to segfault at startup. When I use a code less than 2147483648 (2^31), it works fine; once I pass 2^31, I get a segfault trying to start lircd.

I don’t even know where to report this bug. Is it with the lirc folks, with the Ubunut folks, or here?

Anyway, a year ago, I had everything working fine on a “Myth on Fedora” install hand-patching with your code. Am I going to break things, make things better, or have no change if I take your tarball and install it?

it’s an led on the end of the wire, not an ir transmitter, so the range is short. 1mm is surprisingly short but at high frequencies the distance will be shorter. In summary, it’s not something i can do anything about — it’s just hauppauge using dirt cheap components!

lirc fails to load already a process running.. how do I stop the other instance of lirc running? I thinh Mythbuntu 8.10 loads lirc, however my pvr150 would’nt work out of the box. this is the message I get when I run modprobe lirc_pvr150 debug=1