Filed Under (Random) by mark on 15-01-2006


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
Latest: updated `firmware` to a later revision from hauppauge (743 codesets)


  1. 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.
  2. 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_.
  3. 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)
  4. 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).
  5. Unpack the patched lirc:

    cd /usr/src
    tar xfj lirc-0.8.3-CVS-pvr150-2.tar.bz2
    cd lirc-0.8.3-CVS-pvr150-2

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


    make && make install.

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

  7. 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 302355 loaded
    Aug 28 02:09:11 soapbox kernel: lirc_pvr150: 743 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.

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

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

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

  12. 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).
  13. 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.
  14. If you’re happy, you can always send me beer money. If not, add comments at the bottom :)

That’s it, good luck!


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:

svn co http://svn.blushingpenguin.com/svn/trunk/3rdparty/lirc lirc

and you can get the changes I made to the CVS revision of lirc with:

svn diff http://svn.blushingpenguin.com/svn/vendor/lirc/current http://svn.blushingpenguin.com/svn/trunk/3rdparty/lirc

366 Responses to “LIRC PVR-150 IR blaster support, version 3”

Pages: [1] 2 3 4 5 6 7 8 » Show All

  1. 1
    mikey utah Says:

    Hi Mark,
    Good show. Bought the PVR-150 card two days ago, and the ivtv update (which got the TV portion of the card working) happened yesterday, thankfully. Now having probs with the remote. Have followed your instructions to the letter. Here’s what I get in the dmesg:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    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

    Any thoughts? I’m running a 2.5.15-rc6 kernel on Debian sarge, if that makes a difference.


  2. 2
    mark Says:

    It can’t find the chip. Can you try a cold reboot and let me know what happens? (Turn off, unplug power cord, press power button to drain residual power, wait for a bit, plug in power cord and turn on).

  3. 3
    mikey utah Says:

    Seemingly no change.

  4. 4
    Mark Roy Says:


    I was trying to get patched lirc last night (the one with lirc version 0.7.2) and then I found this. Anywho, I am now having the same problems with the new patch, when I try and modprobe lirc_pvr150 it can’t find the firmware.

    I am running gentoo with 2.6.14-gentoo-r5 kernel and I have hotplug and UDEV installed. I have tried putting the firmware in multiple directories (several of the ones you listed are present on my system).

    Any ideas how I could narrow down the problem? Thanks for your help

    — Mark Roy

  5. 5
    Jesse Says:

    Works great for me on Gentoo with 2.6.14-ck6 and ivtv-0.4.2

    I’m still working on a ebuild that I’ll I post once it’s finished

  6. 6
    Xavier Says:

    First of all, thanx for all the stuff, the prepatched verion of lirc is usefull as well as the send_power_new script.
    I use to have the same problem as mikey.
    A cold boot doesn’t solve the problem.
    at the end, I unpluged and plug again the pvr150 and it seems to work.
    the only trouble is already done this for the version 2 and sometimes lirc still don’t want to work and i miss some recordings :(
    I hope it will not appeared again.
    anyway, ty for your work !

  7. 7
    mark Says:

    Hi, sorry for the delays, work again.

    mikey utah: Do you have a Zilog Z8F0811 CPU on the card? Can you find it with i2cdetect? Does it work with lirc_i2c? Does it work with windows? Basically, if it can’t find the chip, it’s not going to get very far. Other people have seen this and I’d be really interested in finding out what it is, so I’d really appreciate some help tracking it down.

    Mark Roy: udev/hotplug just ends up running a program, which runs a bunch of scripts. If you do cat /proc/sys/kernel/hotplug, that will give you the name of the hotplug program. That then decides what it is being asked to do, and typically ends up running some script or other. On my boxes, the script is called /etc/hotplug/firmware.agent. If you can find the firmware loader script, then you can stuff some lines in to debug it. The driver version won’t make any difference — this is a local configuration issue.

    Jesse: Great, thanks very much!

    Xavier: Glad it’s mostly working for you. I do find it odd that reseating the card solved the problem though. When you say “doesn’t work”, what precisely is the issue?

  8. 8
    mikey utah Says:

    Actually, I may have been a dunderhead here. Doing some additional research into my card lead me to find that what I have is, in fact, a MEDIA CENTER EDITION PVR-150. The difference is thus: with the MCE edition, the tranciever does not plug into the TV card but rather is a USB device. I believe my model is made by SMK, and it is *seemingly* supported by the lirc_mceusb2 driver. (I say seemingly because I still haven’t gotten it to work, but I believe this to be an issue of lirc configuration, as the driver seems to load correctly. Couldn’t get it to work under Win2K, either. Ugh.)

    More information can be found here:

    Thanks for your help, Mark!

  9. 9
    Mark's Fan Club Says:

    You’re the man, Mark. Works for me on kernel 2.6.15 with ivtv 0.4.2, with lirc_pvr150 added as its own line in /etc/modules and after a cold power-off reboot.

    Any word on why this fix has not been integrated upstream into the main lirc branch?

  10. 10
    Mike Says:

    Thanks for updating the driver. I’m so close (hopefully) to getting it to work. I’ve followed the instructions, but it’s still not working.

    Here’s my syslog output when I load the modules:
    Jan 27 12:07:12 localhost kernel: [4297529.937000] lirc_dev: IR Remote Control driver registered, at major 61
    Jan 27 12:07:14 localhost kernel: [4297531.313000] lirc_pvr150: chip found with RX and TX
    Jan 27 12:07:14 localhost kernel: [4297531.313000] ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    Jan 27 12:07:14 localhost kernel: [4297531.326000] ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    Jan 27 12:07:14 localhost kernel: [4297531.330000] lirc_dev: lirc_register_plugin: sample_rate: 0
    Jan 27 12:07:14 localhost kernel: [4297531.395000] lirc_pvr150: firmware of size 229018 loaded
    Jan 27 12:07:14 localhost kernel: [4297531.395000] lirc_pvr150: 608 codesets loaded

    It’s missing the last line about the firmware version. When I check if it’s working with ‘irw’ I get nothing. Do you have any advice? Thanks.

  11. 11
    Ron Simpkin Says:

    First: Thanks for your work Mark :) it’s much appreciated – the light now flashes.

    However the send_power_new script seems to list the 2.2 beta version from Hauppauge’s site whilst the firmware you have available for download is still for 1.3, giving errors like the following when run:
    irsend: command failed: SEND_ONCE blaster 0_85_KEY_POWER
    irsend: transmission failed

    I’ll be honest and say I’m particularly interested in 1_663 for the Sky Digibox which is one of the new ones in the 2.2 beta version.

    Mark Roy:: Putting the firmware in /lib/firmware worked for me on Gentoo

  12. 12
    John Nissley Says:

    When I try to do the ./configure I get this error message.
    which: no dialog in (/usr/kerberos/sbin:/sbin:/usr/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/mythtv/bin)
    dialog not found!
    Please read the documentation!!!

    How do I resolve this and where can I find the documentation?

  13. 13
    Ryan Says:

    Thanks for the upgraded version of lirc. I upgraded ivtv from 0.4.0 to 0.4.2, and lirc-0.7.2 to your patched 0.8.0pre4 today. Works great!

    Since I’m running AMD64, I still had to edit config_file.c and remove the lirc_t check, but after doing that it worked like a charm with my existing configuration files.

  14. 14
    Matt Says:


    Just wanted to say thanks for all of the work you’ve done. I installed the new ivtv a few weeks ago and the remote hasn’t cut out once since. Thanks again.


  15. 15
    Andrew Barbaccia Says:

    Hello Mark,

    Great to see you’ve been making progress here. I’ve done much work with Ubuntu and mythTV so I thought getting the IRBlaster and including a how-to on my webpage would be worthwhile (giving credit where it is justly due). If you could help me out i’d appreciate it. My dmesg output is as follows.

    [4294690.212000] ivtv: ==================== START INIT IVTV ====================
    [4294690.212000] ivtv: version 0.4.2 (tagged release) loading
    [4294690.212000] ivtv: Linux version: 2.6.12-10-686 686 gcc-3.4
    [4294690.212000] ivtv: In case of problems please include the debug info between
    [4294690.212000] ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    [4294690.212000] ivtv: any module options, when mailing the ivtv-users mailinglist.
    [4294690.213000] ivtv0: Autodetected WinTV PVR 150 card (cx23416 based)
    [4294690.269000] tveeprom: ivtv version
    [4294690.269000] ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50]
    [4294690.289000] tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0
    [4294690.289000] ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61]
    [4294690.687000] cx25840 0-0044: ivtv driver
    [4294690.687000] cx25840 0-0044: cx25841-23 found @ 0x88 (ivtv i2c driver #0)
    [4294694.499000] ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44]
    [4294694.557000] wm8775 0-001b: ivtv driver
    [4294694.557000] wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0)
    [4294694.567000] ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b]
    [4294695.308000] ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
    [4294695.518000] ivtv0: Encoder revision: 0x02050032
    [4294695.519000] ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    [4294695.551000] ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    [4294695.552000] ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    [4294695.554000] ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    [4294695.554000] tuner: type set to 50 (TCL 2002N) by ivtv i2c driver #0
    [4294695.769000] ivtv0: Initialized WinTV PVR 150, card #0
    [4294695.769000] ivtv: ==================== END INIT IVTV ====================

    [4294695.774000] lirc_dev: IR Remote Control driver registered, at major 61
    [4294695.775000] lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    [4294695.817000] lirc_pvr150: ivtv i2c driver #0: no devices found

    Seems like it’s not picking up the chip although ivtv is. Its version 0.4.2 of ivtv and the prepatched version of lirc. Lemme know what you get of all this.


  16. 16
    JJones Says:

    what sort of debugging is available in IRW? As far as I can tell (I will post my logs a little bit later today), all of the steps work fine up until IRW comes into play, and then I don’t get any output to my console. So I load IRW, and it just sits there staring at me. Is there anything I can do for debugging, or is IRW so basic that what it outputs is all there is.

    Also, I followed this step by step, so I used the pvr150 lircd.conf and firmware file, but might this work with any remote? I have already swapped out the reciever,so put possible problems in the setup with the modules, the remote, or the card itself. Thanks for the help, so far, this tutorial has gotten be farther than any other web resource.

  17. 17
    Xavier Says:

    Sorry for the delay, I wasn’t be able to know where was my comment :)
    The version 3 is pretty stable, and I don’t have any problem with it, if I don’t stress it. I was sending a “fake” key every two secondes during the recording to be able to know if a can switch the channel on the NTL box or not, but it take to much cpu if i’m watching an other show at the same time. and sometimes the device stop to work. But since I stop this dirty script, i don’t have any problem.

    However I got a problem, sometimes I recorded on the wrong channel. And I just realise today what append. If I try to change the channel to a channel with double number, the NTL box won’t change the channel (144 -> 14) (117 -> 17), only the first number is taken. So I try to play with a bigger gap in the lircd.conf without success. I finally fix it by changing the script change_channel. so when i want to switch to 144, it send “1 4 5 CH_DOWN”. it isn’t really pretty at all, so I will be glad if you know the solution to my problem. (and it can be worth 118 -> “1 2 0 CH_DOWN” or 117 -> “1 2 0 CH_DOWN VOL_UP CH_DOWN” with a VOL_UP between CH_DOWN otherwise it doesn’t work)

  18. 18
    Xavier Says:

    I talk a bit too fast :(
    After 1 week without problem, I got this last night:
    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

    And I still don’t know how to resolve properly the repetition signal problem.

  19. 19
    Scott Says:

    Followed everything to the ‘T’ yet when I try and execute the ‘send_power_new’ script I get the following :

    irsend: command failed: SEND_ONCE blaster 1_678_KEY_POWER
    irsend: unknown remote: “blaster”

    Not sure what is going on here. The remote is working fine.

  20. 20
    mark Says:

    From the top,

    Mark’s Fan Club: fab! It’s not integrated because there are potential issues with distributing the database dump. I’m working on it, slowly, but it’s not likely to end up in the main version of lirc any time soon.

    Mike: not sure. Can you load the module with debug=1 and post the output?

    Ron: the reported firmware version is the version of the IR chip firmware, not the database. Can you post the dmesg output with the module loaded with debug=1?

    John: install the dialog package. Documentation is included with LIRC.

    Ryan: splendid. That patch should probably go back to lirc (as it’s lirc specific code) if it affects AMD64 generically.

    Andrew: Can you try ivtvctl –reset-ir before loading the module and let me know if it find it then?

    JJones: to debug IRW, you need to compile lirc with debug enabled (available from the configure dialog). You can also try loading the module with debug=1 and posting the dmesg output.

    Xavier: hmm, odd. Have you tried checking what other codesets the box will respond to, it doesn’t sound like it quite has it right. The gap parameter does affect the timing between digits AFAICR.

    Xavier#2: try running ivtvctl –reset-ir before loading the module.

    Scott: You aren’t using the right lircd.conf.

  21. 21
    Scott Says:

    Thanks, figured it out, had an extra lircd.conf laying in /etc/ and for some reason… it was using that one

  22. 22
    Xavier Says:

    Hi Mark,
    thx for the tip (ivtvctl –-reset-ir), it’s seems to work so i added this in my script when irsend failed. I will see in the future if that’s fix this problem.
    Concerning my repetition, I will try with other codeset.
    I use NTL with samsung SMT-2100-c box, if someone use it as well, please give me the codeset you use.

    Currently I use the 384 and the power button turn off the box but can’t turn it on.
    I try as well 661, same result (turn off only and repetition don’t work) and 666 (turn on only and repetition don’t work)

    I will try to find a codeset capable to turn off and on the box, but it will take me a while …


  23. 23
    Chris, Ohio Says:

    Hello Mark,

    First Id like to say excellent work. This is just what Ive been looking for Santa brought me a PVR-150 for Christmas but its a newer version than most of the writeups ive seen. It is not a MCE but it has both the RX and TX on the same minijack port. Ive noticed one difference in the lircd.conf it does not include the new generation 3 150 remote commands.
    Ive located these on another site that most MythTV users should already know of.
    I noticed the codes are different.
    Any how to my point im currently formatting my server due to 2 SCSI drives failing on me (I guess 4 years is good life for 24/7 server).
    I can get my TX to blink and can use Terminal to change channels but in my frontend the remote only changes the server and not my Sat dish. In the myth setup when I type the path to the change_channel script do I require ” “? Or am I on the wrong path here?
    Sorry for being so vague but im a bit new to linux. Learning everything for the first time. Once I get it back up Ill let you know what else I run into.

    P.S. on a personal note I dont mind searching the www to locate things such as step #5 Check the syslog output. (whats the command?). I used to write up step by step instructions for Dos based programs years ago. My theroy always was pretend the person reading your walkthrough knows absolutely nothing about what he/she is doing. I know it may be a PITA but it would make everything more user friendly.


  24. 24
    bob Says:

    Hi guys,

    anxious to get version 3 of mark’s setup working. using gentoo. can anyone provide ebuilds for this (patched lirc).??? Thanks.

  25. 25
    bob (first bob) Says:

    Hi guys,

    Nevermind, i just created an ebuild for lirc-0.8.0_pre4 for gentoo with the patch, let me know if anyone needs it.

  26. 26
    marc Says:

    Bob can you make your ebuild available, and since I am pretty new to gentoo, tell me how to use it.

    I have got the lirc code from Mark, but I can not configure it.
    The configuration dialogue comes up nicely, but if I choose driver configuration, software configuration, save configuration & run configure, save configuration & exit, or Exit WITHOUT doing anything, then it just goes back to the Mainmenu. I don’t get any of the options. Cancel works fine.

    Has anybody seen such a thing.

  27. 27
    marc Says:

    I got build to configure after emerge’ing mythtv and lirc, and then removing lirc with “emerge -C lirc”. There probably is a dependency that is needed, that caused the problem with the menu.

    I still can’t get the remote to work. I have teases, but no joy.
    Periodically I can get irw to report a single key press, then nothing. Othertimes I get nothing. If I use cat, I get one or two strange characters (are they binary?).

    Hints appreciated.

  28. 28
    Francisco Says:

    Hi Mark,

    After almost one week tryng to configure my PVR-150 remote control for MythTV on MEPIS, thank God I found your HowTo.

    It is working now. Some adjustments and personalization tasks are nedded now.

    This note is to thank you and please continue you efforts to maintain this HowTo.

    From, Ciudad de Panamá, Panamá with nice view of the Canal de Panamá (your postcard!), again THANK S A LOT MARK!!!



  29. 29
    fri Says:

    A million thanks to you and your hard work. Your instructions worked perfectly and now us pvr-150 users can have onboard ir blasting. The send power script was a smart way to find a compatible codeset, and the set top is under control again.

    Keep up the great work.
    kernel 2.6.15, mythtv .19

  30. 30
    Pucky Says:

    worked like a charm on FC 4,

    Thanks Mark

  31. 31
    Joe Says:

    Have any of you experienced “tinny” audio?


    I am in gentoo with ivtv 0.4.2 (package) and the prepatched lirc pre4 and I am having these problems.

  32. 32
    Yadav Says:

    Is it possible to use the IR receiver with any other remotes other than the Hauppauge remote? I tried putting info for other remotes in lircd.conf. but the remote still can’t see them. I also tried irrecord, but that didn’t work. I’m hoping that it will work, but I doubt it.

  33. 33
    Adam Says:

    I followed this up to the send_power_new script. When I run it $./send_power_new
    It scrolls through the terminal really fast and the blaster only flashes a few times once it is about half way through the script. Am I running the script right, or do I need to run it differently?

    Is the script just trying to see if it will turn the STB on? Or does the script scroll through and if it turns on the box it knows to stop and show the code? It seems like the way I am running it right now there is no why I will be able to find the codeset from running the script.

    On a side note has anyone found a list for the codesets for the supported boxs like these: http://www.hauppauge.com/pages/support/blaster_table_update_1105.html

  34. 34
    Adam Says:

    Got it figured out. I am kind of new to linux so I forgot to add #!/bin/sh as the first line in the script. After that everything worked.

    Thanks for this driver support Mark!

  35. 35
    mark Says:

    Gosh, it’s been a good long time since I’ve looked at this — I’ve been caught up in work, and other projects. So here we go, from about a month behind, and I’ll try and stay more up to date from now on.

    Xavier: I don’t have access to anything other than the hauppauge codes as a dump (and they are encrypted so there is not much chance of generating my own). Unfortunately therefore you are stuck with what they provide, good luck finding one that works.

    Chris: hope you’ve sorted yourself out now. It’s more of a mythtv question, but yes, basically you put the script path in somewhere and make sure the freqid columns have the channel numbers in the database. As mythtv-users if unsure.

    marc: I’m not sure what’s going on there, you’d have to give me some more configuration details, e.g. dmesg output with modprobe lirc_pvr150 debug=1, lircd log when compiled the with debug option.

    joe: ask ivtv-devel, it’s a known issue that is being worked on, albeit slowly.

    Yadav: if it is an RC5 remote you might be able to pick it up, but as is it’s designed to work with the remote that comes with it. A learning remote ought to work.

    Adam: must have missed that line off. To stop it, just hit CTRL+C and manually run the commands to work out which codeset it was. You can also whack “sleep 1″ lines in between the runs if it is going too fast.

    Seems to be mostly working for people, which is pretty good — I guess I’ve worked out most of the bugs now. btw if it doesn’t find the remote you might want to try modprobe ivtv newi2c=0 (after rmmod) as this has caused issues for a couple of people.



  36. 36
    SteveH Says:

    Hi Mark,

    Thanks for the new release!

    Over on the hauppauge uk support forum there has been a lot of discussion about getting the IR blaster to work with SKY Digiboxes (codeset 0663). The beta they put out in Nov 05 didn’t work as advertised.

    They have released a new version of the IR Blaster software on the forum:

    Would it be possible to get an updated firmware binary generated from this release? Is this something we could do, or do you have to do it?


  37. 37
    mark Says:

    Andrew Shuttlewood kindly did the capture this time. I have updated haup-ir-blaster.bin, lircd.conf & send_power new using the new capture. Just grab all these again and follow the instructions at the top.

    I intended to do this at the weekend (I’m just letting it run on my box for a test), but as it seems fine and there is already interest I’ve done it now. Andrew reports that this works with his sky box.

    So thanks to Andrew for this release, and good luck with it!


  38. 38
    mark Says:

    I’ve also added a list of codesets (derived from the hauppauge stuff) here.

  39. 39
    nzruss Says:


    Ive been following the instructions here (http://hyams.webhop.net/mythtv/myth_ubuntu.html) and everything is working great. I just need to get the IR blaster working for my DirecTV box.

    I have a couple of questions as I dont really want to undo my hard work on getting the remote working. My remote config file is coppied from Daniels Hyam’s file: http://s91928265.onlinehome.us/hfamily/mythtv/lircrc-haupgrey-g3.txt )

    I really want to keep the parameters as they are, but want to add the Blaster functionality to control my DirecTV D10

    I have ivtv-0.4.4, and lirc-0.7.2, with firmware v4l-cx25840.fw and
    v4l-cx2341x-enc.fw. (If that doesnt make sense check from the link above, as I followed it to the letter)

    Q: do I have to do all the steps you mention? or can I just do a subset? if so, where can I start?

    Any help really appreciated. I’ll be posting my build experience on my blog once done.


  40. 40
    mark Says:

    Do steps 2-10 inclusive, then cut and paste the result of step 10 (i.e. the blaster configuration) into your existing lircd.conf. That’s about as much as you can trim off it – the blaster driver is different from that provided with the standard lirc. (However you will not need to remap your keys as the IR RX portion will generate the same input codes, hence will work with your existing mappings).

  41. 41
    nzruss Says:

    Hi Mark,

    Thanks so much. Will give it a try. I really appreciate your help.


  42. 42
    nzruss Says:

    Hi Mark. No luck. I think I had a few issues, so ive written my results at:


    just cos there are a few. If you (or anyone) can offer adivce, i’ll report back here.

    aim of my quick page was to provide feedback for your how-to. and i’ll be taking it down once ive got the issue resolved.


  43. 43
    mjhorn Says:

    Hi Mark,
    First of all another thanks, as until I came across your page here I was getting absolutely nowhere. Currently, I’ve followed your instructions up to testing with irw, and everything has worked perfectly. Things compiled correctly, modules loaded, correct dmesg outputs so up to there it seems everything is great. However, when I run irw, i get no response to pressing buttons on the remote whatsoever. Any ideas?
    thanks again

  44. 44
    boggie Says:

    Hi Mark,

    Thanks for the hardwork. I have tried out your instructions. A few problems that I encounter. I am using Ubuntu Breezy with the 2.6.12-10-686 kernel.

    I have configured according to your instructions and I noticed that it created the lirc0 device node but there was no lircd and lircmd daemons in the device folder. Without the lircd daemon, it is not possible to get it to work as it will report an error “could not connect to socket”.

    I use dmesg |grep lirc and and also dmesg|grep ivtv and got those messages that you got.

    Any idea why those daemons are not generated. Also, irw did not work. Thanks for the hard work and I look forward to your solution.


  45. 45
    boggie Says:

    Hi Mark,

    Got it working. I found some old posting exchanges between yourself and Scott. I put the following into bootmisc.sh

    modprobe lirc_pvr150
    /usr/local/sbin/lircd –device=/dev/lirc0

    That created the lircd daemon in the /dev folder on bootup. Then I removed all references to lirc_i2c in the other files.

    Thank you for the hardwork! It is much appreciated.


  46. 46
    boggie Says:

    Hi Mark,

    Any likelihood of using the codesets via haup-ir-blaster.bin working through the serial ports for PVR-250 and PVR-350? This is the most elegant solution if it can be made to work. There are implementation using serial ports but the problem is always with locating the raw codes for the codesets.


  47. 47
    Adam Says:

    I upgraded from FC3 to FC4 and am having problems when I issue the make command. I look at the previous problems with FC4 but it didn’t seem to help. Here is what I get when I run make:

    make[3]: Leaving directory `/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_dev’
    Making all in lirc_pvr150
    make[3]: Entering directory `/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150′
    mv Makefile Makefile.automake
    cp ../Makefile.kernel Makefile
    make -C /lib/modules/2.6.16-1.2069_FC4/build/ SUBDIRS=/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150 modules \
    make[4]: Entering directory `/usr/src/kernels/2.6.16-1.2069_FC4-i686′
    mkdir -p /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/.tmp_versions
    make -f scripts/Makefile.build obj=/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150
    gcc -m32 -Wp,-MD,/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/.lirc_pvr150.o.d -nostdinc -isystem /usr/lib/gcc/i386-redhat-linux/4.0.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer -g -pipe -msoft-float -fno-builtin-sprintf -fno-builtin-log2 -fno-builtin-puts -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4 -mregparm=3 -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -DIRCTL_DEV_MAJOR=61 -DEXPORT_SYMTAB -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/../.. -I/lib/modules/2.6.16-1.2069_FC4/build//include/ -DMODULE -D”KBUILD_STR(s)=#s” -D”KBUILD_BASENAME=KBUILD_STR(lirc_pvr150)” -D”KBUILD_MODNAME=KBUILD_STR(lirc_pvr150)” -c -o /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/.tmp_lirc_pvr150.o /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c
    /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1157: error: unknown field ‘name’ specified in initializer
    /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1157: warning: initialization makes integer from pointer without a cast
    /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1158: error: ‘I2C_DRIVERID_EXP3’ undeclared here (not in a function)
    /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1159: error: unknown field ‘flags’ specified in initializer
    /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1159: error: ‘I2C_DF_NOTIFY’ undeclared here (not in a function)
    make[5]: *** [/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.o] Error 1
    make[4]: *** [_module_/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150] Error 2
    make[4]: Leaving directory `/usr/src/kernels/2.6.16-1.2069_FC4-i686′
    make[3]: *** [lirc_pvr150.o] Error 2
    make[3]: Leaving directory `/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150′
    make[2]: *** [all-recursive] Error 1
    make[2]: Leaving directory `/usr/src/lirc-0.8.0pre4-pvr150/drivers’
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/usr/src/lirc-0.8.0pre4-pvr150′
    make: *** [all] Error 2

    The lirc_dev driver gets made ok but not the lirc_pvr150. I have kernel 2.6.16-1.2069_FC4 installed from atrpms also gcc is installed and I just did a yum upgrade. The ivtv version is ivtv-0.6.1-109.rhfc4.at from atrpms.

    Any help?
    Thanks, Adam

  48. 48
    Dave Rose Says:

    Adam, I am seeing the exact same thing. I am running the same versions as you…hope Mark can help.

  49. 49
    mark Says:

    Sorry, haven’t had much time recently. Unfortunately I don’t get much free time to work on this due to the everyday business of work & looking after a couple of groups of ferrets (fun but time consuming 😉

    Anyway, replies in order:

    nzruss — Please uninstall whatever lirc you have installed already and then start from the beginning, making sure each step succeeds before proceeding to the next.

    mjhorn: not sure, can you load lirc_pvr150 with modprobe lirc_pvr150 debug=1 & post the output from that? Also worth checking that the jack is in the back of the card, it can take some wiggling to get it connected properly.

    boggie: glad you were able to help yourself! Sorry I didn’t get to replying before you did! Unfortunately there’s no hope of using the codesets files with any other kind of card; the binary dumps are in fact encrypted. I work basically by capturing & replaying the encrypted stream, but because I have no idea of the content of the data it’s only any use with a PVR-150.

    Adam & Dave: please try this updated file and let me know if it works. It’s based of a recent CVS dump of lirc; there is as yet no lirc release that supports the 2.6.16 kernel. Unfortunately I don’t have a 2.6.16 based machine to test the compile against at present — I’ve made the same fix as in lirc-i2c.c, so hopefully it should work.

  50. 50
    Dave Rose Says:

    Thanks Mark, but it does the same thing:

    /usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1166: error: unknown field ‘name’ specified in initializer
    /usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1166: warning: missing braces around initializer
    /usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1166: warning: (near initialization for ‘driver.list’)
    /usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1166: warning: initialization from incompatible pointer type
    make[5]: *** [/usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/drivers/lirc_pvr150/lirc_pvr150.o] Error 1

    Would it help if I gave you an account to log into my box and try to compile it yourself? This way you’d have access to a 2.6.16 kernel?

Pages: [1] 2 3 4 5 6 7 8 » Show All

Leave a Reply

eight + 2 =