Final update
I have forward ported the code to the latest lirc release, fixed some bugs, and the i2c fixes have been merged into the ivtv-0.4.2. Please see this separate post, where I have removed all of the irrelevant history and only describe steps that are currently useful.

All new update
I’ve updated the ‘firmware’ file to include the new codesets recently released by hauppauge. This was a bit of a pain, as I had to disassemble my myth box to do it (bah, closed source). I hope they don’t do this too often in future! If anyone has got a spare PVR-150 or is willing to stick it in a windows machine and run wacky software then that would be nice the next time around Alternatively you can bribe me I guess!

Update
Quick update: I have been working with the ivtv driver to see if I can resolve the root cause of the problem with the IR chip locking up and needing to be reset. I think that I have done so, but I can’t be sure until I get more testing feedback. I’ve updated the howto below to point at this post which contains the details of how to install the patch to ivtv. If you’ve followed all of the steps below and are still experiencing intermittent remote drop-out issues (as a couple of people have noted), you might want to try this out. I realise that this is quite a long and complicated procedure, so I’m working towards getting all fixes into the release versions of ivtv & lirc eventually. Obviously I’ll keep this updated as things progress. Slight update: up to about 28 hours now with no remote issues. Very encouraging. Further update: it works. Has been for months, and for others too. It’s in the 0.4.2 candidate release, so hopefully this issue should just die at some point. It also looks like hauppauge have put this in their mainline driver, which was updated some time in October. I’ve not disassembled it to check yet though

I’ve uploaded a slightly newer patch/package correcting two bugs. The first is not to reset the IR chip if you try and send an invalid code (by messing with lircd.conf!) since this clearly isn’t necessary. The second is a stack overrun bug spotted by Pascal Brisset, which could have had nasty consequences. I guess since I’ve not seen it the way I use lirc it’s only sending one code at a time to the driver. btw, this stuff is in my SVN repository, under trunk/3rdparty/lirc, if you want to do development on it.

The old stuff
OK, I’ve been playing with this off the back of the basic problem that seems to have been encountered by a lot of people, myself included — after a while the IR chip on the PVR-150 locks up, and hence the remote/blaster stop responding. (This happens with release versions of lirc/ivtv, so is definitely not related to what I’ve been doing with the IR blaster). This problem is pretty difficult to reproduce (i.e. I can’t do it on demand), but only seems to happen if you are using the encoder on the card at the time. I tried reproducing it with the Windows software, but I couldn’t manage it. I might not have tried hard enough; google search show that quite a few people have got this to fail, or it might be that hauppauge fixed the problem at some point. I don’t really know anything about this chip (it’s some software running on a fairly general purpose CPU, so it would be hard to without explicit information from hauppauge or some reverse engineering of that code, which is beyond me at this point in time), so I’m not sure why it happens. If anyone from hauppauge wants to step up and provide me with some information I’d be very happy!

There does exist a sort of solution for this: ivtvctl provides an ioctl that resets the IR chip on the card. Some people have this running every minute from a cron script, whilst that’s not a great solution it is a workable one. My issue with that is if you reset the IR chip, you have to send the boot block again to the IR blaster, so if I’d adopted the cron script I wouldn’t be able to change channel any more.

So after all that, I’ve adopted a delightful solution — detecting when the IR chip has locked up (i.e. stopped responding to i2c traffic), and resetting it in the driver. It’s messy, but it works, and as I do it in the driver, I can transparently retry IR blaster sends, which saves me from recording the wrong channel. Anyway, that was a bit long, so here’s a changelog:

- Split the code out into a new lirc driver, lirc_pvr150.
- TX and RX portions are treated as a single device. This makes good sense as you then only have one lirc socket that supports both receiving and sending (if the TX hardware is actually found).
- The RX device is ‘polled’ in the same way that the windows driver appears to. This is a good place to detect whether it has died or not.
- IR device is reset on failure and operations are retried (needs ivtv patch)
- A local copy of the ‘firmware’ data is made and release_firmware() is called. This prevents a hotplug timeout that I used to see (the script expects that firmware is released when loading is finished).
- Merge with lirc-0.72 release (rather than pre2)
- Module is reference counted properly
- Module has parameters disable_rx and disable_tx. You can use, e.g. modprobe lirc_pvr150 disable_tx=1 if you are not interested in setting up the IR blaster device.

Here’s the updated HOWTO for this version:

1. Get the pre-patched lirc 0.7.2 (or just the patch should you prefer).
2. Unpack the patched lirc (or apply the patch)


cd /usr/src
tar xfj lirc-0.7.2pvr150.tar.bz2
cd lirc-0.7.2pvr150
./configure


Choose:
TV card
h – Hauppauge PVR-150 TV card (note: _NOT_ ‘g – Hauppauge TV card’)
Save configuration & run configure

then:

make && make install.

3. Note that this step is no longer necessary with ivtv >= 0.4.0 (the current stable release series), which is recommended — the export symbol patch was included. Skip right on to step 5 if you’ve grabbed the latest stable release, or go to 3a if you are having ‘remote stops responding’ issues (doesn’t seem to affect everyone).
3a As an alternative to the below, see this post. Don’t do both. I’ll update this if that patch proves to solve problems for people. I am hoping it might, it’s working very well for me so far.
3b Patch your ivtv driver and rebuild it. This step is necessary to be able to reset the IR chip. Download the patch here. Note that this patch does not apply to some versions of ivtv. I’m currently using 0.3.7a, so it should apply cleanly to that. If you want to use a later driver, the change is actually pretty trivial, we just need to export an extra symbol. In drivers/ivtv-driver.c, you need to add:

#include “ivtv-gpio.h”

near the top of the file after the rest of the #include lines, and

EXPORT_SYMBOL(ivtv_reset_ir_gpio);

right at the bottom of the file where all the other EXPORT_SYMBOL lines are. All this does is export that symbol for use by other modules, it does not change the functionality of the driver in any way. If you have trouble with this then drop me a line and I will create a patch for the version of ivtv you want to use.


cd /patch-to-ivtv-driver (e.g. cd /usr/src/ivtv-0.3.7a)
cd driver
patch < ivtv-driver.c.patch
cd ..
make && make install


4. Unload & reload the new ivtv driver. If lucky, rmmod ivtv && modprobe ivtv, otherwise either
kill everything that might be using the driver/unload all dependent modules or just reboot if you can’t be bothered with that.

5. 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 200K) so this makes the driver quite large.
(I have no plans to sort this out, memory is cheap).

6. Check everything is working so far:

modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1

Check the syslog output. This should report something like:

Aug 28 02:09:11 soapbox kernel: lirc_pvr150: chip found with RX and TX
Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR RX,
ok]
Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR TX,
ok]
Aug 28 02:09:11 soapbox kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
Aug 28 02:09:11 soapbox udev[5221]: creating device node ‘/dev/lirc0′
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: firmware of size 20927 loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: 575 codesets loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

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

7. 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.

8. 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.

modprobe lirc_dev && modprobe lirc_pvr150 debug=1
lircd --device=/dev/lirc0


9. 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.

10. 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 (575 at present).

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 and took me a couple of goes to get right. Some people have reported needing
to have the device attached back to front.

If you can’t get this to work:

a) My software doesn’t work properly
b) The device you are trying to control is not supported (please check against the Windows stuff if possible)
c) You didn’t get the device in the right place — did I mention it was touchy?

11. 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).

12. 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.

That’s it, good luck!

I have updated the patch with the following changes:

- Use schedule_timeout not mdelay as mdelay is a busy loop. This fixes high CPU usage during IR sending.
- Drop out of the polling loop when the chip is ready rather than after 1s (can’t believe I didn’t notice this one!). This greatly speeds sending.

As a consequence of the second point, I recommend that you fiddle with the ‘gap’ parameter in lircd.conf. The gap parameter is in microseconds. For my particular cable box, I’ve found that 1/3s (~333,333us) works well. The minimum time is until the chip is ready to send, this works out roughly at about 50-200ms. The minimum delay is fixed at 50ms (avoids wasting CPU; go hack the code if you want to change this), and the maximum wait is 1s.

NOTE: This page has been superseded. Please see this post which has a newer patch & scripts.

I have a basic driver that appears to make this work, based on I2C captures from the Hauppauge windows software. I will say
right now that I have no idea how the hardware actually works — various people have made suggestions but it was not enough
for me to figure it out (search the ivtv-devel list on “cheapi2c/lmilk” for more information).

Here’s a basic HOWTO:

1. Get lirc-0.7.2-pre2 or your favourite version
(the patch is against that version).
2. Get my patch
3. Unpack lirc and apply the patch:

tar xfj lirc-0.7.2pre2.tar.bz2
cd lirc-0.7.2pre2
patch -p4 < pvr150.patch
./configure


Choose ‘TV card’, ‘Hauppauge TV card’, save quit then
make && make install

4. 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. Note that the entire firmware is kept in memory (currently 170K) so this makes the driver quite large.
(I have no plans to sort this out, memory is cheap).

5. Check everything is working so far:

modprobe lirc_dev debug=1 && modprobe lirc_i2c debug=1

Check the syslog output. This should report something like:

Aug 7 23:10:52 soapbox kernel: lirc_i2c: chip found @ 0×70 (Hauppauge IR TX (PVR1
50))
Aug 7 23:10:52 soapbox kernel: ivtv: i2c attach [client=Hauppauge IR TX (PVR150),
ok]
Aug 7 23:10:52 soapbox kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
Aug 7 23:10:52 soapbox kernel: lirc_i2c: firmware of size 174351 loaded
Aug 7 23:10:52 soapbox kernel: lirc_i2c: 470 codesets loaded
Aug 7 23:10:52 soapbox kernel: lirc_i2c: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

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

6. 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.

7. Start lircd. You need two of them as one device is created for the receiver and one for the sender, I use:

modprobe lirc_dev && modprobe lirc_i2c debug=1
lircd --device=/dev/lirc0 --output=/dev/lircd0 --pidfile=/var/run/lirc0.pid
lircd --device=/dev/lirc1 --output=/dev/lircd1 --pidfile=/var/run/lirc1.pid
# mythtv likes /dev/lircd
ln -s /dev/lircd0 /dev/lircd


You need to check in /dev or syslog to see which “lircN” files were created for which device. The IR blaster will
always be second due to the probing order.

8. Next you need to work out which codeset to use, this is the tricky bit. For this I have
send_power, a script that just sends the power
command in every single codeset (470 at present).

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 and took me a couple of goes to get right. Some people have reported needing
to have the device attached back to front.

If you can’t get this to work:

a) My software doesn’t work properly
b) The device you are trying to control is not supported (please check against the Windows stuff if possible)
c) You didn’t get the device in the right place — did I mention it was touchy?

9. 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).

10. 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.

That’s it, good luck!