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!
chad: Just found something out — it looks like this might well be fixed by the new i2c implementation (the patch that sorts out remote issues). Can you please test again against the 0.4.2 ivtv release You will find instructions for getting this here. Do report back if it helps because it is probably going to help everybody else who’s been having the same issue.
Thanks,
Mark
Since I’m on xmas hols right now I can give it a shot. I’ll have a look at lirc’s setup tomorrow (hopefully) and see if your patch applies to their head version.
OK I’m trying to get this to work on my setup and I’m having some trouble with the IR blaster. I can get irw to work just fine with the remote but when I try the irsend commands to find out which power send effects my device that’s where things go wrong.
Here’s all the relevant information I can think of.
syslog after modprobing lirc_dev and lirc_pvr150:
Jan 4 21:12:40 localhost kernel: lirc_dev: no version magic, tainting kernel.
Jan 4 21:12:40 localhost kernel: lirc_dev: IR Remote Control driver registered, at major 61 Jan 4 21:12:53 localhost kernel: lirc_pvr150: no version magic, tainting kernel. Jan 4 21:12:53 localhost kernel: lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes Jan 4 21:12:53 localhost kernel: lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes Jan 4 21:12:53 localhost kernel: lirc_pvr150: chip found with RX and TX Jan 4 21:12:53 localhost kernel: ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71] Jan 4 21:12:53 localhost kernel: lirc_pvr150: poll thread started Jan 4 21:12:53 localhost kernel: ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70] Jan 4 21:12:53 localhost kernel: lirc_dev: lirc_register_plugin: sample_rate: 0Jan 4 21:12:53 localhost kernel: lirc_dev: plugin lirc_pvr150 registered at minor number = 0 Jan 4 21:12:53 localhost kernel: lirc_pvr150: firmware of size 229018 loaded Jan 4 21:12:53 localhost kernel: lirc_pvr150: 608 codesets loaded
Jan 4 21:12:53 localhost kernel: lirc_pvr150: 01 60 00 01 81lirc_pvr150: 05 02 04 5b 0flirc_pvr150: 09 91 2f 45 0flirc_pvr150: 0d 34 f5 79 fblirc_pvr150: 11 53 b4 66 02lirc_pvr150: 15 2e d9 17 7clirc_pvr150: 19 20 cc 63 26lirc_pvr150: 1d 33 6b 26 12lirc_pvr150: 21 61 6b 0a 66lirc_pvr150: 25 7e 95 1e 17lirc_pvr150: 29 25 12 0a 8dlirc_pvr150: 2d 28 06 00 50lirc_pvr150: 31 4f 02 55 2clirc_pvr150: 35 4b 1c 6d 72lirc_pvr150: 39 6b ad 2f 3dlirc_pvr150: 3d 22 fb 55 e4lirc_pvr150: 41 7c 6a 54 06lirc_pvr150: 45 71 dd 59 c7lirc_pvr150: 49 2a 6c 7f 40lirc_pvr150: 4d 2e a9 52 c6lirc_pvr150: 51 c4 c7 b7 31lirc_pvr150: 55 56 dc 5e cdlirc_pvr150: 59 0c 56 53 fblirc_pvr150: 5d 97 b9 62 6blirc_pvr150: 61 00 00 00 6blirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
Jan 4 21:12:54 localhost kernel: lirc_pvr150: poll thread ended
Now to get these to work I have to run ‘modprobe -f’ otherwise I get the following:
# modprobe lirc_dev
FATAL: Error inserting lirc_dev (/lib/modules/2.6.8.1-12mdk/misc/lirc_dev.ko): Invalid module format
# modprobe lirc_pvr150
FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.8.1-12mdk/misc/lirc_pvr150.ko): Invalid module format
I’ve heard this might be because I’m not using gcc 4.0 or higher. Is that a requirment?
I’m running:
Mandrake 10.1 2.6.8.1-12mdk
gcc 3.4.1
ivtv 0.4.0
Anyway when I try the irsend commands here’s what I get:
$ irsend SEND_ONCE blaster 0_0_KEY_POWER
$ irsend SEND_ONCE blaster 1_0_KEY_POWER
irsend: could not connect to socket
irsend: Connection refused
The first command will cause the led to blink in the blaster. However, I can never get a second command to run.
Any help would be appreciated. Thanks.
Figured it out. Somehow when I upgraded to xorg 7.0 it uninstalled my kernel source and then urpmi kernel installed the wrong kernel level. Once I got the right source on here it worked fine.
Thanks for all your hard work on this project!!
Looks great, and I’m thrilled to find this … but does it work with lirc-0.8*, which seems to be the current lirc module?
Mark,
Is support for the pvr 150 going to part of the 8.0 lirc release or will you release a patch for it when the time comes? Thanks,
Mark Maz
Pingback: Mark’s Braindump » LIRC PVR-150 IR blaster support, version 3
Hi, Dave Zysk. It sounds like lircd is crashing after the first command — I guess this could be a segfault from the module blowing up in the kernel. You certainly shouldn’t have to modprobe -f it to get it to load, and indeed, this is quite likely to lead to bad results.
You definitely don’t need to use gcc-4.0 to get this to work (I don’t, I’m using gcc-3.3.5), but you should use the same compiler that you used to compile the kernel, and compile it against the same set of sources. I’m not quite clear on what you are doing: I would guess the best bet would be to post some more details on how you are compiling the driver.
To everybody who wanted lirc 0.8 support, I have now forwarded ported the driver to the current CVS snapshot (lirc-0.8.0pre4). I will be submitting it to lirc shortly as ivtv-0.4.2 (the current stable release) now has the i2c fixes and all of the required support for my driver. You can get the details of this from here.
Thanks,
Mark
Thanks for this invaluable resource, Mark! I was running FC4-kernel-2.6.11, but I recently upgraded to kernel 2.6.14 since that is what the ivtv drivers seem to support.
Anyways, following your instructions, my PVR-150 is now successfully blasting IR signals to my STB ok; however, I cannot get the remote to work for the life of me. When I run ‘irw’, I don’t see any sort of output on the screen. I’ve done a lot of research, but haven’t found a solution yet. I know this is kind of a vague description of the error, but I was wondering if you might have a good starting point… BTW, I checked the batteries in the remote 😉
Thanks,
kg
Kevin: sounds like an old bug. Please check with the v3 driver and let me know if it still happens.
Sorry to consume your time with that question, I just realized that I had not inserted the mini-plug for IR RX/TX firmly into the jack :). It is very new, and the jack was very tight. Everything is now working fine with respect to the IR Blaster and Remote.
The only issue that remains is that my linux system no longer has sound. I was running 2.6.11-1.1369_FC4, but to install the ivtv drivers I need to upgrade my kernel to 2.6.14-1.1656_FC4. After upgrading the kernel, I ran ‘yum upgrade’ to make sure all my packages were up-to-date. Now, I can no longer get sound to work on my system. The soundcard is detected correctly by alsaconf correctly; however, I don’t get any sound output.
It doesn’t work when logged in as ‘root’ or as a regular user. The only thing I notice every now and then are permission issues when using a regular user to play a video from Myth:
“alsa-init: playback open error: Permission denied”
however, this does not occur all the time.
I am using a simple A-Open soundcard (C-Media PCI CMI8738)
If anyone has encountered this, any help would be great. By the way, for this issue the plug IS inserted fully into the jack 😉
Thanks,
kg
Not much activity on this thread lately. I recently purchased a
150 and mine came with a usb sensor and blaster attached to
that. So it doesn’t appear that the i2c driver will be of much use
with this. I’m looking for another solution, possibly a
blaster/sensor combo that will plug into the serial port. Any ideas??
Thanks,
Scott
Scott,
It has moved on a version — see the home page. Regardless, the driver you are looking for is probably lirc_mceusb (part of the standard lirc distribution).
Mark
Mark,
How would I select that driver? Would this be selected within the
lirc configuration utility?
Thanks,
Scott
Mark,
I have been reading your site regarding using a Scientific Atlanta 4200 box with the IR Blaster and downloaded the files. I am not sure how to go about installing the files and having the ir blast the required codes. if you can help me with this i would greatly appreciate it!
Thanks,
Erik
Hi,
I have been looking how to add IR Blaster support to my PVR150 usign KnpooMyth (R5C7 from memory).
I have the receive working but the transmit does not, (the IR Blaster is connected via the plug in jack on the card and not USB) and I have assumed from the mythtv.org mailing lists that the support for this has not made it into lirc and the thread pointed to this page.
I assume I still need to apply the patches listed above, or is support going to be / is now in lirc?
The following information is intended to supplement
Thenks, good works
my wintv 2000 keeps giving me error that it cannot locate the capture filter
I’ve spent a lot of time, with much hair pulling trying to get my PVR-150MCE IR blaster working. Now I discover after reading the replies that there’s an issue with this card. I really hate to ask this but has this this issue ever been fixed or are those of us with MCE cards basically SOL?
You are using the wrong driver, use plain lirc for an MCE card.
I got the driver installed, the remote works, but the ir blaster fails when sending commands to the cable box, but works when sending to satellite box’s.
Heres the error message:
irsend: command failed: SEND_ONCE blaster 0_80_KEY_5
irsend: transmission failed
My cable box is the Motorola 2224. If I send the 1_80_KEY_5 command, the LED on the blaster blinks (which is what I am assuming means its working), yet when sending to 0_80_KEY_5 it fails with the above message.
Anyone have tips for me to solve this? I’ve spent hours searching online and this page is the best source for information yet I still cant get over that final hump to get it working!
Joe: this page is obsolete, like it says at the top.
But anyway, 0_80 and 1_80 are two different codesets, presumably the 0_80 codeset simply does not exist. If your box responds on 1_80, then why not just use that?
Yea, sorry it wasn’t clear, but the 1_80 codeset, while triggering the LED on the blaster, does not get the STB to respond. The 0_80 codeset does exist in the lircd.conf (same one linked to in this article).
In more testing, I notice that none of the 0_## codesets work and all give the above error. Only the 1_## codesets run and trigger the LED to flash. It seems other people have PVR-150 MCE’s and Motorola 2224 working together so I assumed I missed something along the way.
I know you mentioned this guide is obsolete, but really its the best documentation on this situation on the net. I can’t even find a remotely useful article elsewhere so this was my only hope 🙂
When I say obsolete, I merely mean that the post is out of date — there is a separate post covering “v3” (and all subsequent updates of the driver), which is linked at the very top, so you may be looking at old code and are certainly looking at old instructions!
The MCE IR blaster is a completely different device from the one included with the non-MCE edition PVR-150, and the voodoo required to get them to work is totally different unfortunately :/
I am pretty sure that the 0_ codesets work, could you check that you haven’t picked up an old version of the code? I had to go back and rejig things because originally I hadn’t picked them up, so possibly you are just running into that.
HTH
Awesome items!! Give us the full lowdown along with loads of pictures when you get back.