Filed Under (Random) by mark on 28-08-2005

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!

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

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


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


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,
Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR TX,
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!

226 Responses to “LIRC PVR-150 IR blaster support, version 2”

Pages: « 1 [2] 3 4 5 » Show All

  1. 51
    Giff Says:


    I have spent hours trying to debug the hotplug/firmware problem, including editing scripts with debug info, etc. I would highly appreciate any help in the matter. I am running KnoppMyth, which is obviously based upon Knoppix, which is in turn based upon Debian. Is there a possibility that hotplug is not loading in the correct order during boot? When is your hotplug service started during boot?

    I can open up an SSH session for you once I get home and determine the public IP. Am I blind, or is there no info on this site RE: your email address?

    Also, a few people including myself have offered to send you donations for all your hard work on the project, but I don’t think you’ve responded. Is there any way we can give back to the project? Thanks.

  2. 52
    Administrator Says:

    It’s I’ll see if I can add it somewhere more prominent.

    Still thinking about the donations thing, I’ll get back to you, but thank you for your kind offer.

  3. 53
    J. Longman Says:

    I’m running Knoppmyth – and I had to “apt-get install hotplug”. In addition, it seems there are TWO places to put your various firmware, /lib/modules for ivtv f/w but /usr/lib/hotplug/firmware was where I had to put the lirc firmware for happiness.

    That being said I’ll get on to today’s poking around… HTH…

  4. 54
    J. Longman Says:

    lirc_pvr150: chip found with RX and TX
    ivtv: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    ivtv: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware of size 209327 loaded
    lirc_pvr150: 575 codesets loaded
    lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
    lirc_pvr150: bt878 #0 [sw]: no devices found

    The last line is the line that makes me think that it’s attempting to attach to my bttv card. TIA, j

  5. 55
    Administrator Says:

    That looks absolutely fine, just carry on from step #7 above.

    Don’t worry about the scan on the bt878 — this just happens because that card also has an i2c bus. As it happens I’ve got a bt878 DVB-T card as well as the PVR-150, and exactly the same thing happens on my machine without consequence, so I can’t see it causing any problems for you.

  6. 56
    J. Longman Says:

    Holy moly! RX is working! I re-created the /dev/lirc[0|1] devices, removed and re-plugged the cable, and lo and behold.

    Now, I’m not seeing any visual light from the blaster when I run the script, nor any IR light when I point my night-vision video camera at it…

    Yay! But Hmm….

  7. 57
    J. Longman Says:

    I sure wish I could edit comments… rather than adding 20!

    BTW, in the post above it is marked mknod /dev/lirc0 c 1 0, whereas in the earlier post, or in the comments, it is mknod /dev/lirc0 c 61 0. That wasn’t my problem though

  8. 58
    Administrator Says:

    Duly corrected, thanks. Not sure where the 6 went.

    Can you send me the dmesg output generated by running the send_power_new script for a few seconds? (Make sure lirc_pvr150 was loaded with debug=1, i.e. modprobe lirc_pvr150 debug=1).

    Might be a bit lengthy for this, if so just email it to me (



  9. 59
    J. Longman Says:

    lircd -n –device /dev/lircd0 ./lircd.conf &
    tail -f /var/log/syslog &

    These commands led to:

    lircd 0.7.2pvr150: accepted new client on /dev/lircd
    lircd 0.7.2pvr150: removed client
    lircd 0.7.2pvr150: accepted new client on /dev/lircd
    Sep 15 23:48:49 mythbox kernel: lirc_pvr150: poll called
    Sep 15 23:48:49 mythbox kernel: lirc_pvr150: poll result = 0
    Sep 15 23:48:50 mythbox kernel: lirc_pvr150: 01 60 a3 61 ablirc_pvr150: 05 4d 0d 67 a6lirc_pvr150: 09 72 0d 0f eelirc_pvr150: 0d 68 fa 47 falirc_pvr150: 11 36 08 34 86lirc_pvr150: 15 8c e6 df b2lirc_pvr150: 19 74 ef 05 bdlirc_pvr150: 1d 63 af 35 fblirc_pvr150: 21 5d a0 2a 49lirc_pvr150: 25 29 38 40 22lirc_pvr150: 29 ab 7e a0 a1lirc_pvr150: 2d fd 0f e0 b7lirc_pvr150: 31 98 7b 99 4alirc_pvr150: 35 f7 99 dc 4clirc_pvr150: 39 93 e1 d2 66lirc_pvr150: 3d e2 17 9d 19lirc_pvr150: 41 f5 5c a9 54lirc_pvr150: 45 b2 f2 98 59lirc_pvr150: 49 8d f2 f0 11lirc_pvr150: 4d 97 05 b8 05lirc_pvr150: 51 c9 fe f0 74lirc_pvr150: 55 84 04 93 4dlirc_pvr150: 59 8b 10 fa 42lirc_pvr150: 5d 9c 50 e8 6alirc_pvr150: 61 00 00 00 6alirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 1)
    Sep 15 23:48:50 mythbox kernel: lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 2)
    Sep 15 23:48:50 mythbox kernel: lirc_pvr150: sent code 0, key 10
    Sep 15 23:48:50 mythbox kernel: lirc_pvr150: poll called
    Sep 15 23:48:50 mythbox kernel: lirc_pvr150: poll result = 0
    Sep 15 23:48:50 mythbox kernel: lirc_pvr150: poll called
    Sep 15 23:48:50 mythbox kernel: lirc_pvr150: poll result = 0
    Sep 15 23:48:50 mythbox kernel: lirc_pvr150: poll called
    Sep 15 23:48:50 mythbox kernel: lirc_pvr150: poll result = 0
    Sep 15 23:48:50 mythbox kernel: lirc_pvr150: poll called
    Sep 15 23:48:50 mythbox kernel: lirc_pvr150: poll result = 0
    lircd 0.7.2pvr150: removed client

  10. 60
    Administrator Says:

    That looks fine to me. Is the jack firmly seated? If wiggling it about doesn’t help then I guess try it in Windows if possible and see if it works with the hauppauge software.

  11. 61
    J. Longman Says:

    “Windows”? What is this “Windows” you speak of? (apt-get install windows? :-))

    I’ll have to see what I can do. I wish I had a live cd, just for testing. I do own a license for w2k that came with my laptop. But it’s probably oem crippled.

    I’m a little concerned that maybe it was burned out from earlier testing – at one point it was on all the time. I think if I could remember how I achieved even that I would try it again right now.

    But you’re right: Hauppauge’s software will definitely be the easiest/most effective way to test the transceiver’s integrity. Thanks… -j

  12. 62
    Administrator Says:

    I agree, it’s a pain in the arse. I had to borrow a machine from someone to do the captures in the first place. The only reason I keep suggesting is that it’s a good way of eliminating a bunch of things that might be wrong.

    Given that at the software level everything looks fine (the onboard IR chip/program is responding as it should be), then I can’t think why the LED wouldn’t be blinking other than it not being connected (I can’t really see you ‘burning out’ an LED by using it).

    I suppose if wiggling the jack doesn’t help you could crack the plastic case open and stick a oscilloscope/multimeter on the pins to see if anything is actually happening at that end, probably quicker than installing windows at any rate.

  13. 63
    Lee Says:

    First off thanks for creating support for the PVR150 ir blaster.
    Second I just wanted to know if anyone has got this working in Gentoo.
    I can’t seem to get it to find the firmware, everything else seems to be loading properly. Anyone know where the firmware belongs? I’ve tried every directory listed in the instructions above.

    Sep 16 10:59:58 mythmaster lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes
    Sep 16 10:59:58 mythmaster lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes
    Sep 16 10:59:58 mythmaster lirc_pvr150: chip found with RX and TX
    Sep 16 10:59:58 mythmaster lirc_pvr150: poll thread started
    Sep 16 10:59:58 mythmaster lirc_pvr150: poll thread ended
    Sep 16 11:00:08 mythmaster lirc_pvr150: firmware haup-ir-blaster.bin not available (-2)


  14. 64
    Giff Says:


    You are the man. Thank you so much for the help. I did have problems when I restarted the machine, but then did some rmmodding and some modprobing and life was all good again. I set up an rc.local script to do this for me at the end of every bootup. I do think KnoppMyth starts the hotplug way too late, which is why it doesn’t work initially. But I spent so much time trying to re-order hotplug, that I’d rather just waste a few seconds doing things twice during boot if it just works.

    Let me know what you decide about donations. Also, are you in touch with the lirc/ivtv dudes? This would be a great addition to the main releases of both.

  15. 65
    Administrator Says:

    Great! Have you got it controlling a box yet?

    I am in touch with both the ivtv & lirc lists. I’m not sure I’d consider this for inclusion just yet, it seems a little bit difficult for people to set up right at the moment (I think 4 people have got it working so far, excluding me). Also, there is the chance of getting information out of hauppauge about how the IR chip/program actually works, which would allow me to write a far better driver (with any luck, I might get a recorder going which would dispense with the ‘firmware’ nonsense altogether). Someone has a contact at hauppauge, and has forwarded my list of questions to them — I don’t have any timescales on that though.

    Regarding donations, it’s very kind, thanks to all those who have offered. I have added a paypal button so that you can send me money if you want! Don’t feel any obligation though — I started out on this as just a bit of a fun, and am quite happy to share the results.



  16. 66
    mark Says:

    Lee — have you got hotplug installed? This might be helpful. It either can’t find the file, or can’t the hotplug scripts.

    This seems to be the most tricky area, I’ll look into how ivtv does it (I thought it was the same, but obviously I must be missing something).

  17. 67
    Lee Says:

    Thanks, I had installed hotplug and hotplug_base, but didn’t realize I needed udev too.
    Now everthing is working it seems. (I have to wait until I get home to test whether or not it changes channels!)

    Thanks again,

  18. 68
    J. Longman Says:

    I installed udev and a linux 2.6.13 kernel and it hasn’t worked any better. I think I’m going to have to resort to digging out windows… Carp.

  19. 69
    J. Longman Says:

    It was long and arduous – but I’m getting the same behaviour in windows, no light. 🙁 I guess its reassuring the problem is in the physical domain. Thanks for your help, and I hope to be using your work soon!

  20. 70
    J. Longman Says:

    My multimeter shows no variation in resistance and voltage when no channels are being changed and a wide variation when “Test all” is turned on, when using windows, so clearly a signal is being sent.

  21. 71
    mark Says:

    Sounds like you’ve diagnosed a dead LED — somewhat surprising. Since it doesn’t work under windows, I guess it shouldn’t be too hard to get hauppauge to send another one.

    Hardware is such a pain!

  22. 72
    Joe Says:

    I know you have been working with mostly the blaster part of the pvr-150. But I was curious about the receiver part. I am a little bit unsatisfied with the responsiveness when using the remote control. Is it normal for the button presses to come in bunches of 6 or 7 when I look in irw? Do you know if that behavior is a product of the hardware or the driver/software?

    The blaster is working beautifully, by the way. Thanks again.

  23. 73
    J. Longman Says:

    A liberal return policy at staples allowed me to get a new cable, right quick. Everything worked right away, but ultimately I couldn’t get video AND sound at the same time. Eventually, a Sept 20th build of ivtv-0.3.9, coupled with audio firmware, worked. Hooray!

    The machine has crashed a couple of times – but probably because of the video driver. I still have to go through the mythbackend.log to see if there are any clues.

    Another note related to some postings – not using udev i.e. using a static device filesystem – I had to put the modprobe for lirc_pvr150 into the rc.d lirc script. Otherwise it wouldn’t acknowledge the existence of the firmware in the firmware directories, and probably because of that the device /dev/lirc0 etc.

    I imagine the hotplug had to be before the modprobe in the boot sequence.

    In general I find the channel changing is slow, but I haven’t yet played with it to see what I can do about it. I will…

    Thanks for all your help!

  24. 74
    Chris K Says:

    having an issue with the firmware. the firmware is in the same place as the firmware for ivtv and it loads without issue. Here’s a snip of dmesg.
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes
    lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes
    lirc_pvr150: chip found with RX and TX
    ivtv: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    lirc_pvr150: poll thread started
    ivtv: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware haup-ir-blaster.bin not available (-2)
    lirc_pvr150: poll thread ended

    this did load once but after a reboot it does not anymore. I have redownloaded the firmware again, played with permissions and tried all the possible locations with no luck. Any help would be appreciated

  25. 75
    J. Longman Says:

    Here’s a simple perl script which will pull out the lircd.conf for a specific cable/sat and remote configuration. I’m not happy with the first choice I found for the remote (using send_power_now, of course) so I’m trying others, but I found it repetitive to keep doing the same cut and paste job.

    (boy am I rusty – I thought it would take 15 minutes to write, it took an hour!)

    Visual inspection is necessary, as I noticed a few mistakes in the file. I just spend another half hour trying to figure out how to better match underscores (sigh – i had a typo somewhere else – and it seems an underscore works as a literal in one place, but it just matched everything in another place) – as some of the codes are not well-formed. I’ve _tried_ to preserve malformed key labels.

    It definitely would have been faster to do it by hand.

    # lircd splitter
    $cablesat = $ARGV[0];
    $remote = $ARGV[1];

    print(” cablesat>” . $cablesat . “” . $remote . “lircd.$cablesat.$remote.conf”);
    while ()
    print(OUTLIRC $_);
    last if (m/raw_codes/);
    $copyit = 0;
    $phrase = $_;
    if ($copyit)
    print (OUTLIRC $phrase);
    $copyit = 0;
    elsif ($phrase =~ m#$cablesat\_$remote\_(.*)# )
    if ($phrase !~ m#$cablesat\_$remote\_KEY\_*#)
    print (OUTLIRC $phrase);
    } else
    $phrase =~ m#$cablesat\_remote\_KEY\_(.*)#;
    print (OUTLIRC “\tname $1\n”);
    $copyit = 1;
    elsif ($phrase =~ m/
    print (OUTLIRC “\t\t$phrase”);
    $copyit = 0;
    last if ($phrase =~ m/ ;
    print(OUTLIRC $_);

    close IN;
    close OUTLIRC;

  26. 76
    joelones Says:

    great work!

    having the same problem as Lee and Giff
    Sep 24 11:28:57 tuse lirc_dev: IR Remote Control driver registered, at major 61
    Sep 24 11:28:57 tuse lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    Sep 24 11:28:57 tuse lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes
    Sep 24 11:28:57 tuse lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes
    Sep 24 11:28:57 tuse lirc_pvr150: chip found with RX and TX
    Sep 24 11:28:57 tuse ivtv: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    Sep 24 11:28:57 tuse ivtv: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    Sep 24 11:28:57 tuse lirc_pvr150: poll thread started
    Sep 24 11:28:57 tuse lirc_dev: lirc_register_plugin: sample_rate: 0
    Sep 24 11:28:57 tuse lirc_pvr150: firmware haup-ir-blaster.bin not available (-2)

    using gentoo, i believe the problem is because of /etc/modules.d/ivtv needs to be aliased to lirc_pvr150 instead of lirc_i2c that way the /dev node gets aliased to the correct module. just don’t know how to fix it


  27. 77
    joelones Says:

    Ok solved my problem,
    hotplug 20040923-r1 (gentoo) expects the firmware in /lib/firmware

  28. 78
    Christian Says:

    Man. You are a god. Add me to your list of successfully working people.

    By the way- I’m currently sniffing around trying to figure out how those blobs build. I’ll let you know if I come up with anything.


  29. 79
    scott Says:

    Hey guys!

    Just found this while searching, and i followed the directions completly, and mabey its me (or the beer im drinking (being Canadian and all) i have found the code to turn my sat. receiver off, it worked out to be irsend “SEND_ONCE blaster 1_27_KEY_POWER”

    now im trying to get that change_chan script working and i cant figure it out, any help? this is the output when i try it

    root@mythtvmd:/tmp# ./change_channel 381
    channel changing 381
    /usr/local/bin/irsend: could not connect to socket
    /usr/local/bin/irsend: No such file or directory

  30. 80
    mark Says:

    OK, here’s the latest bunch of out of order replies.

    Joe: yes, button presses seem to come in weird bunches. I’ve not investigated this, it is on my TODO list though. This is the same behaviour as with the standard lirc_i2c driver however.

    J. Longman: thanks for the script, and glad you’ve got things working now. In terms of channel change time, the device takes something like 20-50ms to set itself up, then the rest is controlled by the ‘gap’ parameter in lircd.conf. The gap parameter is in us, try adjusting that. It’s set to ~1/3rd of a second in (which makes my cable box happy – much faster and it stops registering button presses).

    Chris K: could you let me know what distribution you are using? Basically you need udev/hotplug, etc working — I’m not sure why ivtv is better at this, again, on my TODO list is to figure it out as this seems to be the biggest setup problem for people. If you read around the other comments you can find some things to check to see if hotplug is working properly.

    Christian: good luck! One of the ivtv developers has a contact with hauppauge, and has passed a list of questions on for me, I’m still waiting for the response though. Apparently they are pretty helpful (if busy), so that might be enlightening.

    scott: The change_channel script is wrong (it was as per old instructions). You can either download a new one, or edit the line that runs irsend (remove the -d /dev/lircd1) and it should work fine.



  31. 81
    scott Says:

    Mark, if i can get this to work, You Da Man Cool Cat! ill reply in about an hour, as well, being someone new to this, but having built myth boxs for myself, what are the odds of this being able to run on 2 receivers? controlling 2 boxs with 2 of the blasters? (multiple instances)?

  32. 82
    scott Says:

    Sorry for another question, im thinking it still may be the wobbly pops playing an effect on me, but i can not fine the line in that channel changing script that has “-d /dev/lircd1” in it, im using the one from the walkthrough which is the same as:

    1 small step in the right direction, if i run
    irsend SEND_ONCE blaster 1_27_KEY_POWER
    it does turn off my box and on my box (if i run it again) but still the change chan script errors on me,

    :/tmp# ./change_channel 1
    channel changing 1
    /usr/local/bin/irsend: command failed: SEND_ONCE blaster 1
    /usr/local/bin/irsend: unknown command: “1”

    sorry for being wet behind the ears! BTW Mark, amazing work needless to say.

  33. 83
    scott Says:

    hot digity-dog … i got it to work…. for people that can not follow directions to well, im going to make a dummy’s version for ya soon…. now to see if i can get this to work with a 2nd instance!

  34. 84
    scott Says:

    k, jumped the gun, sorry to keep rambling on here and using this as a thought pad, it works when i start lirc from doing a /etc/init.d/lirc start – i can get irw to work, but when i do a clean reboot it doesnt… another thing, the RX (receive) works fine, but TX (transmit) is not working anymore. i start lirc by typing in /etc/init.d/lirc start and then if i do a IRW i can see the remote codes its getting, but when i try to send anything to the IR blaster it can not connect – thanks

  35. 85
    mark Says:

    scott: You have skipped skip 12. You need to rename the number keys for that script to work, removing 1_27_KEY_ from the front of them. You can delete everything that doesn’t start with 1_27_KEY_. Alternatively you can use the perl script posted by J. Longman above to do this for you.

    On reboot — it appears that you have another version of lirc installed. You are probably loading the lirc_i2c driver.

    killall lircd
    rmmod lirc_i2c
    modprobe lirc_pvr150

    would get you going again in that case. You should remove the other version of lirc.

    If you still have trouble, please post dmesg output with “modprobe lirc_pvr150 debug=1”.

  36. 86
    scott Says:

    Thank You Mark for replying again so quick i did fix step 12, but on bootup i still have problems with it not loading lirc.

    im hoping this is what your looking for for the dmesg, i did it before the
    modprobe lirc_pvr150

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: no
    lirc_pvr150: ivtv i2c driver #0: no devices found
    lirc_pvr150: probe 0x70 @ ivtv i2c driver #1: yes
    lirc_pvr150: probe 0x71 @ ivtv i2c driver #1: yes
    lirc_pvr150: chip found with RX and TX
    ivtv: i2c attach to card #1 ok [client=Hauppauge PVR150 IR RX, addr=71]
    ivtv: i2c attach to card #1 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: poll thread started
    lirc_pvr150: firmware of size 209327 loaded
    lirc_pvr150: 575 codesets loaded
    lirc_pvr150: 01 60 00 01 bflirc_pvr150: 05 02 00 22 1alirc_pvr150: 09 fe 06 0e 43lirc_pvr150: 0d 98 2e 56 53lirc_pvr150: 11 6e 99 94 5dlirc_pvr150: 15 46 70 30 6alirc_pvr150: 19 be 6e a3 56lirc_pvr150: 1d ab 4d 0d 67lirc_pvr150: 21 a6 72 0d 0flirc_pvr150: 25 ee 68 fa 47lirc_pvr150: 29 fa 36 01 0flirc_pvr150: 2d 8b 7b fb 6clirc_pvr150: 31 b2 74 ef 05lirc_pvr150: 35 bd 63 af 35lirc_pvr150: 39 fb 5d 22 2alirc_pvr150: 3d 38 58 49 31lirc_pvr150: 41 50 6b fd 5flirc_pvr150: 45 5e 02 f0 1flirc_pvr150: 49 48 67 84 66lirc_pvr150: 4d b5 08 66 23lirc_pvr150: 51 b3 6c 1e 2dlirc_pvr150: 55 99 1d e8 62lirc_pvr150: 59 e6 0a 45 39lirc_pvr150: 5d 67 6c 9f 76lirc_pvr150: 61 00 00 00 76lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

    as well, when i do the killall lircd and other steps, here is the output:

    root@mythtvmd:/var/log# killall lircd
    lircd: no process killed
    root@mythtvmd:/var/log# rmmod lirc_i2c
    ERROR: Module lirc_i2c does not exist in /proc/modules
    root@mythtvmd:/var/log# modprobe lirc_pvr150
    root@mythtvmd:/var/log# lircd
    root@mythtvmd:/var/log# irw
    0000000000001794 00 Up Hauppauge_350
    0000000000001795 00 Down Hauppauge_350
    0000000000001796 00 Left Hauppauge_350
    0000000000001796 01 Left Hauppauge_350
    0000000000001797 00 Right Hauppauge_350
    0000000000001797 01 Right Hauppauge_350

    so i get errors when i try to ‘killall lircd’ of
    lircd: no process killed
    and rmmod lirc_i2c
    ERROR: Module lirc_i2c does not exist in /proc/modules

    but after the next 2 it works and i have control, now to make it start with boot.

    Off topic as well, Once again, im happy you hae a paypal donate button, how can i get the other pvr150 card in my box’s ir working so i can have 2 sat. receivers working?

    Thanks Mark

  37. 87
    mark Says:

    OK, the module is just not loading from the boot script, so there’s no real issue — you just need to add it in. The normal place to put this depends on your distribution, but trying adding lirc_pvr150 to /etc/modules (if it exists), alternatively add “/sbin/modprobe lirc_pvr150” to /etc/init.d/lirc, somewhere near the top after the #!/bin/sh should do. Not sure where you got /etc/init.d/lirc from — this is not part of the lirc distribution.

    Regarding your second IR blaster, it doesn’t appear to be present (from the dmesg output, the devices are not found on card #0). It ought to work with two cards, but I’ve not tested it. Can you confirm that you have 2xPVR-150s, 2xIR blasters and that they both have a Zilog Z8F0811 CPU on on them if possible? To do the latter, you need to look at the card, the chip should be near the bottom left of the device.

    In any case, can you send me the output of running i2cdetect? You need to modprobe i2c-dev, then run i2cdetect -a . Run it on each bus that appears in /dev (/dev/i2c-0, /dev/i2c-1 etc). For anything large please email it directly to



  38. 88
    scott Says:

    Will do, im reinstalling right now, trying to get this working properly and making my own walkthrough as i go. at last go i had the remote being picked up, but was getting errors when trying to send ir commands to the chip (tx).

    will post in about 30 mins or so… mabey we can make a dummy’s guide out of all of this.

  39. 89
    scott Says:

    k here is the outputs from the i2cdetect: hope it makes sense to you

    Installed I2C busses:
    i2c-3 unknown ivtv i2c driver #1 Algorithm unavailable
    i2c-2 unknown ivtv i2c driver #0 Algorithm unavailable
    i2c-1 unknown SMBus nForce2 adapter at 5500 Algorithm unavailable
    i2c-0 unknown SMBus nForce2 adapter at 5000 Algorithm unavailable

    as well, i emailed you the output from my syslog, which is showing the 2 cards… now to make it work…

  40. 90
    mark Says:

    i2c detect looks a bit bizarre, but never mind — it appears that it found both IR blaster devices on reboot.

    To get the other one working, you need a second instance of lircd — first check if you have a /dev/lirc1. If so, run lircd –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/ You should then be able to do irsend -d /dev/lircd1 SEND_ONCE xxx and it should use the other blaster device. You should also see remote input from irw /dev/lircd1.

    IOW you just need to specify which device you are using. It all looks like that should work. For the change_channel script, I urge you to look at it — it’s really simple and just decodes change_channel 123 -> irsend SEND_ONCE blaster 1 2 3 for example. For the case you have, you’ll probably need a change_channel2 with “irsend” changed to “irsend -d /dev/lircd1” for the second blaster (or add a parameter). If you have trouble with that bit let me know and I can provide further assistance. Obviously you need to get the second blaster doing something first for this to have any relevance.



  41. 91
    scott Says:

    K totally lost on that one man (again newbie)

    i did a
    ls -l /dev/lirc*

    and this came back

    crw-r–r– 1 root root 61, 0 Jul 30 2004 /dev/lirc
    srw-rw-rw- 1 root root 0 Sep 25 20:46 /dev/lircd
    prw-r–r– 1 root root 0 Jul 30 2004 /dev/lircm

    so, im assuming i need to do a

    mknod /dev/lirc0 c 61 0

    to get my lirc0.

    Thanks for the quick reply’s mark

  42. 92
    scott Says:

    im now using this as a channel change script

    for digit in $(echo $1 | sed -e ‘s/./& /g’); do
    /usr/local/bin/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

    seems to work fine…

  43. 93
    scott Says:

    k now this is messed, i cant even connect with irw anymore

    i do the
    killall lircd
    rmmod lirc_i2c
    modprobe lirc_pvr150

    manually, finally an irw and nothing, right back to prompt – if i do it again i get a connect: Connection refused

    man, im puzzled now – i have no clue how to find out how to fix this one

  44. 94
    scott Says:

    k fixed the ir by
    rmmod lirc_pvr150
    modprobe lirc_pvr150

    and im back to working…

  45. 95
    scott Says:

    k got it working perfectly on 1 tuner now, edited my /etc/init.d/ file to include at the bottem

    /sbin/modprobe lirc_pvr150

    reboot and she works off the top, now just to get that 2nd ir blaster working,

  46. 96
    scott Says:

    alrighty, i think i found all the root of my problems….

    seems with knoppmyth, you have to edit some other files in order to make lirc_pvr150 load properly. i had to edit /etc/lirc/hardware.conf

    and find the line
    MODULES=”lirc_dev lirc_i2c”
    and replace it with
    MODULES=”lirc_dev lirc_pvr150″

    then edit /etc/init.d/
    and add at the bottom

    modprobe lirc_pvr150

    so far so good, its still working, hopefully it wont freeze up on me. now just to get blaster 2 working…. i hope this helps someone.

  47. 97
    scott Says:

    hey mark, just curious what your think with the send blaster. I checked for a second lirc (lirc1) and i dont have one in my dev folder.

    this is the output of my ls -l /dev/lirc*

    root@mythtvmd:/dev# ls -l /dev/lirc*
    crw-r–r– 1 root root 61, 0 Jul 30 2004 /dev/lirc
    crw-r–r– 1 root root 61, 0 Sep 26 21:31 /dev/lirc0
    srw-rw-rw- 1 root root 0 Sep 26 22:22 /dev/lircd
    prw-r–r– 1 root root 0 Jul 30 2004 /dev/lircm

    i linkd lirc0 to lirc as per your instructions

    mknod /dev/lirc0 c 61 0

    any help?

  48. 98
    mark Says:

    You need a second lircd, try:

    mknod /dev/lirc1 c 61 1
    lircd –-device=/dev/lirc1 -–output=/dev/lircd1 -–pidfile=/var/run/
    irsend -d /dev/lircd1 SEND_ONCE blaster xxx

  49. 99
    Pascal Says:

    Congratulations for the hard work, code capturing and all.

    I am trying to control a device which uses SPACE_ENC instead of RC5. That is, bits are encoded into variable-length delays between constant-length pulses ( ).

    Is this supposed to work, or does the PVR150 IR blaster only support RC5/RC6 ?

  50. 100
    scott Says:

    Mark, yup that worked
    you the man cool cat! now where is that paypal donate button – oh, i posted your walkthrough modified with what i discovered with knoppmyth here.

Pages: « 1 [2] 3 4 5 » Show All

Leave a Reply