LIRC PVR-150 IR blaster support

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

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

Here’s a basic HOWTO:

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

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

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

4. Now you need the ‘firmware’. This is
a set of data blocks that correspond to those generated by the windows software. This goes in /usr/lib/hotplug/firmware on my
debian system. Note that the entire firmware is kept in memory (currently 170K) so this makes the driver quite large.
(I have no plans to sort this out, memory is cheap).

5. Check everything is working so far:

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

Check the syslog output. This should report something like:

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

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

6. You need to configure lircd, and find out which codeset you are going to be using. The easiest way is to start
with this configuration file which contains
key definitions for everything in the database.

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

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

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

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

You need to stick the IR blaster on the IR receiver of box that you intend to control, being quite careful to position
it correctly — it has a very short range and took me a couple of goes to get right. Some people have reported needing
to have the device attached back to front.

If you can’t get this to work:

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

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

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

That’s it, good luck!

This entry was posted in Random. Bookmark the permalink.

40 Responses to LIRC PVR-150 IR blaster support

  1. Paul Baker says:

    Interested to see this as I am setting up a MythTV box with a PVR-150 at the moment as well. Just at the point of getting lircd to work…

    Installing on Mandrake (or mandriva!!) 10.2.

    I am using devfs.

    Have followed all the instructions – but have a query – do you know when the output sockets should be created ?…

    can see the input devices being created when the modules are loaded.
    These are /dev/lirc/0 and /dev/lirc/1 which then have symbolic links back to /dev/lirc0 and /dev/lirc1. This is done during reboot.

    but the neither lircd output socket device is made – so I am figuring that this means that there will be no output available.

    Can see a note on the lircd website that Mandrake wants to make the lircd devices in /tmp but they are not created in there either.

    Any chance you can post your lircd system config file – I think it is in /etc/sysconfig/lircd?. Or if there are any other ideas that would be cool.

    Thanks.

    –output=/dev/lircd0

  2. Administrator says:

    When the lirc_i2c module is loaded, a character device is created for each of the transmitter and receiver (usually /dev/lirc0 and /dev/lirc1). If devfs is working properly I can’t see why you need a reboot, the devices should appear when the module is inserted. When lircd is run it links the given character device (–device=) to a UNIX socket (–output=) which is what most things talk to. So basically it sounds like you are having trouble running lircd as you are missing the sockets but have the devices.

    Can you post what command lines you are running lircd with? If you are using some mandrake package (which it sounds like from your reference to /etc/sysconfig/), then try uninstalling it, building from source and then running it with appropriate command lines as above. If lircd has trouble starting, then please post/email me the output of lircd (/var/log/lircd or wherever) with -D255.

    Thanks,

    Mark

  3. Brian Topping says:

    Hi Mark, thanks for taking the time to share your work on this. I believe I have things close to working, as I am again able to use IRW, but am not yet able to control my cable box with the ir blaster. It’s a bit interesting to see it operate, it emits visible red light. I presume that is a feature, not a bug, and there is also some nice IR coming out of the unit at the same time. Is that what you’ve experienced?

    Regardless, I’m having no luck using the send_power script against a Pioneer Voyager STB. I’ve run it several times, now with the lights off and the transmitter about 10mm from the bezel. Still no luck. The unit works just fine with the supplied remote. I tried running the transmitter and the receiver “head-to-head” while irw runs in the background, but the machine freezes momentarily with each transmit, leading me to believe the receiver and the transmitter cannot work simultaneously.

    If you have any ideas what I might try, I’d love to hear them!

  4. Brian Topping says:

    Oh, by the way, this is runnng on an Athlon64 box. Not sure if that matters, but I can supply dmesg output and/or work on this with you over IM or phone… thx!

  5. Administrator says:

    Mine also emits visible light when it is operating normally — that it’s doing that is a good sign at least 🙂 The Hauppauge list has codesets 44,45,72,317,337,481 for pioneer although I have no details on which models that covers.

    If it is not working then either it means that I am sending the wrong data to the chip (which I can probably resolve with a bit of debugging) or that your box is not supported. Is there any chance that you could try this with the hauppauge software and see if it works with that? If it does then I have obviously missed something.

    The freezing is interesting — I looked into this. I’m afraid it’s my fault, I’ve got a busy wait loop in the driver [mdelay]. I have changed this in my local copy to a schedule_timeout and that solves the high CPU usage issue.

    For both sending and receiving, it appears that the I2C bus cannot be polled reliably for received signals whilst transmitting is taken place (even without burning all the CPU), I will do some more work on this tonight and try and figure out what the hauppauge thing does wrt to that.

  6. Jakub Velimsky says:

    Hi,

    I just got the transmitter working, also on Mandriva 2005 LE (special kudos to you). At least to the state that the transmitter emits visible light. If anybody still interested, I can post my config files on monday. I’d like to use it to control a SONY TA-FE300R amplifier (it was a second hand purchase without a remote). No luck yet, although some time during the send_power script some unusual noises – sort of cracking – came out of the amplifier. How could I force the transmitter to emulate one of the sony remotes (e.g. RM-S311, lircd.conf is provided in Mandriva’s lirc-remotes)?

  7. Administrator says:

    I’m afraid you can’t really, the only output that I can produce is the same as that in the set provided by the hauppauge windows driver. Either this has a codeset that works with your device or it doesn’t. Given that everything they list is a cable or satellite box I’d guess you are out of luck. You could try sending every known key in the huge lircd.conf rather than just ‘power’ — given that it did something then one of the buttons might map to something useful.

    Theoretically it would be possible to work out what the device is doing and program it to send the correct codes, but neither I nor anyone else has figured this out. You might try bugging hauppauge for a data sheet, if I had one I’d be happy to code it up properly.

  8. piratebab says:

    Hello,
    lirc with the patc is installed. lirc0 un lirc1 installed. very good job!
    I have made the launch of lircd automatic. But now I want to modify the lircd.conf. How can I kill the 2 lircd process that lock the conf file ?

  9. Administrator says:

    With ‘kill’ usually. Here are two methods.

    First, the straightforward one:

    killall lircd

    or the slightly cleaner solution:

    kill `cat /var/run/lirc0.pid’
    kill `cat /var/run/lirc1.pid’

    If you just want to reload the config use ‘kill -HUP’.

    Not sure what you mean by lock — AFAIK lircd does not apply any locking to the configuration file so you should be free to edit it.

  10. piratebab says:

    thanks for your quick answer.
    My conf file was “read only”, I dont know why. I have killed lircd, modified lircd.conf, and reboot.
    Now I am a little bit confused on what to do.
    for the symbolic link: why do you link lircd to lirc0 ? why not lircd to lircd0 ?

    irw dont work. mode2 -d /dev/lirc0 works.
    ./send_power dont work (could not connect to soccet connection refused).

    Is it OK ?

  11. piratebab says:

    For the emiter, I think I got it.
    I have modified the lines in the file send_power as follow:
    irsend -d /dev/lircd1 SEND_ONCE blaster 0_KEY_4

    The LED is blinking.
    I will try it on my SAGEM satellite box.

    I do you create the haup_irblaster.bin file ?
    Is it possible to update it ?
    How can I know whith box is supported ?

    You have done a great job. If it works for the french satellite box, I will make a link to your site in my own how-to!

  12. Administrator says:

    OK, that’s a good sign, just run it through all of the codesets and see if it responds on any of them.

    The haup_irblaster.bin is created from I2C captures of hauppuage’s software. I don’t understand the data that I have captured: I just replay it to the chip and it appears to do the same thing as with the Windows version. Because I don’t understand that data, I can only “update” the codesets by getting a new version of the hauppauge software (when one is available) and rerunning the captures. If the box is not supported, there is nothing I can do about it (you’d have to bug Hauppauge, get updated windows software, and then redo the captures basically). As to whether it is supported, I do have a list (I will put it up somewhere): sagem is supposedly codesets 301,304,375,476. Try using those, e.g.

    irsend -d /dev/lircd SEND_ONCE blaster 301_KEY_POWER

    Sometimes the box will respond to a different codeset, hence that script.

    For you previous question, /dev/lirc0 = IR receiver, /dev/lirc1 = IR transmitter. I use the symlink for mythtv as that only talks to /dev/lircd for remote support. You can just change the –output parameter to lircd if you like, it doesn’t really make any difference which way you do it. irw -d /dev/lircd0 should work, that should respond to the hauppauge grey remote control.

    HTH,

    Mark

  13. piratebab says:

    I have made the test last night, without succes. I have send an email to hauppauge to know if this box is supported. It is one of the most popular in France. Waiting for a response, maybe on monday.
    I can’t believe they ignore it.
    I hope that the hauppage software is the same for all the countries (NTSC, PAL, or SECAM). here is the link for the french hauppauge software :
    [url] http://www.hauppauge.fr/pages/support/support_pvr150.html [/url]

    For the remote, all is clear for me. But I point of your how to confused me. You wrote:
    ln -s /dev/lirc0 /dev/lircd

    but if I understand well, I must be: ln -s /dev/lircd0 /dev/lircd

    am I right ?

    I have also notice 2 points in your how to:
    – step 3: I think something is missing, but I dont remenber what. If I only do what you wrote, make file is missing.
    -step 7: the correct writing is –device, or -d; idem for other options of lircd.

    I am stuck with my PVR box by this problem of changing channel of the on top box. I am so close to the end, after several months of work (I used this PVR job to discover debian).

  14. Daniel Sherwood says:

    Got a setup running the send_power script (once a few typos had been fixed:) but I am still unable to get it to control my SKY box. ANy idea on the codeset for SKY?

  15. thylacine222 says:

    I’m fine up to the part about debugging lirc to see if it is running properly. I looked in syslog, and I got this response:
    Aug 22 09:21:44 localhost kernel: lirc_dev: IR Remote Control driver registered, at major 61
    Aug 22 09:23:29 localhost kernel: bttv: driver version 0.9.15 loaded
    Aug 22 09:23:29 localhost kernel: bttv: using 8 buffers with 2080k (520 pages) each for capture
    Aug 22 09:23:29 localhost kernel: cx2388x v4l2 driver version 0.0.4 loaded
    Aug 22 09:23:29 localhost kernel: lirc_i2c: chip found @ 0x71 (Hauppauge IR (PVR150))
    Aug 22 09:23:29 localhost kernel: ivtv: i2c attach [client=Hauppauge IR (PVR150),ok]
    Aug 22 09:23:29 localhost kernel: lirc_dev: lirc_register_plugin: sample_rate: 10
    Aug 22 09:23:29 localhost kernel: lirc_i2c: chip found @ 0x70 (Hauppauge IR TX (PVR150))
    Aug 22 09:23:29 localhost kernel: ivtv: i2c attach [client=Hauppauge IR TX (PVR150),ok]
    Aug 22 09:23:29 localhost kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
    Aug 22 09:23:29 localhost kernel: lirc_i2c: firmware haup-ir-blaster.bin not available (-2)

    I’m running FC4 and I think it has to do with the fact that I had to make /usr/lib/hotplug/firmware to put the bin file in. Is there another directory I should put it in for Fedora?

  16. thylacine222 says:

    Never mind, it turns out you have to put the file in /lib/firmware.

  17. Troy Michaud says:

    I have followed what you have listed here (Excellent by the way). But I have a problem.

    Unfortunately I can’t cut and past right now but here is the jist of it. I get the following output:
    Aug 7 23:10:52 localhost kernel: lirc_i2c: chip found @ 0×70 (Hauppauge IR TX (PVR1
    50))
    Aug 7 23:10:52 localhost kernel: ivtv: i2c attach [client=Hauppauge IR TX (PVR150),
    ok]
    Aug 7 23:10:52 localhost kernel: lirc_dev: lirc_register_plugin: sample_rate: 0

    But once it gets to loading the firmware – I get :

    wait_for_sysfs[10711]: either wait_for_sysfs (udev 039) needs an update to handle the device ‘/devices/platform/devices/i2c-4/4-0071’ properly (bus pecific file unavailable) or the sysfs-support of your device’s driver needs to be fixed, please report to

    I did a yum update to udev, and I don’t seem to have the above message anymore, but all I get is:

    Aug 7 23:10:52 localhost kernel: lirc_i2c: chip found @ 0×70 (Hauppauge IR TX (PVR1
    50))
    Aug 7 23:10:52 localhost kernel: ivtv: i2c attach [client=Hauppauge IR TX (PVR150),
    ok]
    Aug 7 23:10:52 lel: lirc_dev: lirc_register_plugin: sample_rate: 0

  18. Troy Michaud says:

    oops, forgot to mention (probably important) Fedora core 3.

  19. Troy Michaud says:

    Bad typing day… In my above descriptions it says client=Hauppauge IR TX that is not true it is client=Hauppauge IR

    It seems it is not picking up and blaster stuff.

  20. Dean says:

    Dude, I am like, totally stuck at the “make && make install” part. I need like, some newbie help, n’junk. I am sure it ‘s somthing stupid. Error is…

    make: *** No targets specified and no makefile found. Stop.

    2 Cents.
    2 anyone that comes here from the wilsonnet.com site, because they will, I have been working on setting up mythtv for the last 2 weeks. I have spent at least 40 hours working on this stupid box installing over and over an…………. Finally…. FINALLY I got PVR-150 working on FC4. Just sort of tweaking things out now. Tips so far: Don’t use Apt as much as Yum with FC4! Don’t beat or throw things! If you ever write documentation, dumb it up as much as you can! Don’t give up! Oh, and linux is case sensitive.

    (Just thinking out loud): What the heck am I going to have to do to get this to work on my DISH 811 HD tuner? All I wanted to do is get rid of my ReplayTV tm and 10$ bill. MythTV Rocks and so does Mark’s Brain.

    Sincerly,
    Dean

    PS Mark (AKA;Admin), Thanks for letting everyone in on this and making people smarter. You would be surprised at how people hord information. It is sickening.

  21. Mauricio says:

    Hello, i have executed the steps, but the i still have only de lircd device in /dev.

    I am using knoppmyth R5A16

    My syslog output is:

    Aug 24 02:49:33 mythtvbox kernel: lirc_dev: IR Remote Control driver registered, at major 61
    Aug 24 02:49:39 mythtvbox kernel: lirc_i2c: chip found @ 0x71 (Hauppauge IR (PVR150))
    Aug 24 02:49:39 mythtvbox kernel: ivtv: i2c attach to card #0 ok [client=Hauppauge IR (PVR150), addr=71]
    Aug 24 02:49:39 mythtvbox kernel: lirc_dev: lirc_register_plugin: sample_rate: 10
    Aug 24 02:49:39 mythtvbox kernel: lirc_i2c: chip found @ 0x70 (Hauppauge IR TX (PVR150))
    Aug 24 02:49:39 mythtvbox kernel: ivtv: i2c attach to card #0 ok [client=Hauppauge IR TX (PVR150), addr=70]
    Aug 24 02:49:39 mythtvbox kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
    Aug 24 02:49:39 mythtvbox kernel: lirc_i2c: firmware of size 174351 loaded
    Aug 24 02:49:39 mythtvbox kernel: lirc_i2c: 470 codesets loaded
    Aug 24 02:49:39 mythtvbox kernel: lirc_i2c: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

    What more can I do to make this work?

    Thans.

    Mauricio

  22. Giff says:

    Mark,

    Followed all the instructions, and am getting this in the /var/log/syslog:

    Aug 23 22:52:20 gifftv kernel: lirc_dev: IR Remote Control driver registered, at major 61
    Aug 23 22:52:20 gifftv kernel: lirc_i2c: chip found @ 0x71 (Hauppauge IR (PVR150))
    Aug 23 22:52:20 gifftv kernel: lirc_dev: lirc_register_plugin: sample_rate: 10
    Aug 23 22:52:20 gifftv kernel: lirc_i2c: chip found @ 0x70 (Hauppauge IR TX (PVR150))
    Aug 23 22:52:20 gifftv kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
    Aug 23 22:52:20 gifftv kernel: lirc_i2c: firmware haup-ir-blaster.bin not available (-2)

    Let me know if you have any ideas. Thanks for all your hard work. Keep up the struggle!

  23. Administrator says:

    Sorry, this software (wordpress) doesn’t seem to let you reply to comments in order, so here we go with one big set of replies.

    piratebab: I have made corrections as you have pointed out, thanks. I have no idea if your particular SAGEM box is supported, the codesets listed by hauppuage are as noted earlier.

    Troy Michaud: If it didn’t find the TX chip, then perhaps you have an different card version with some other IR chip? It just does an I2C probe on that address, and if it isn’t responding then it probably isn’t there. Could you post or email me (mark@npsl.co.uk) the full log for modprobe lirc_i2c debug=1 so I can get a clearer idea. Better to cut & paste if possible rather than type it in to avoid confusion.

    Dean: there was an error in the earlier instructions which I have corrected, after running ./configure, in the menu screen please choose Option 3 (Save configuration and run configure) this should create the Makefile.

    Maurico: you should have /dev/lirc0 and /dev/lirc1. If you are not using udev (i.e. static /dev) then you can create these devices manually using:

    mknod /dev/lirc0 c 61 0
    mknod /dev/lirc1 c 61 1

    Running lircd as detailed should then create /dev/lircd0, etc (these are actually sockets that you can talk to the daemon over).

    Giff: You need to find out where your kernel takes firmware from and put the haup-ir-blaster.bin there. The error you are getting is ENOENT (file could not be found). If you give me the details of your distribution then I might be able to find out for you. For me it is /usr/lib/hotplug/firmware; some people have found it to be /lib/firmware. It might also work from /lib/modules. Try “locate firmware” or “find / |grep firmware” and see if anything looks likely.

    HTH,

    Mark

  24. Giff says:

    Mark,

    I actually get a different error when I do not have the firmware file in /usr/lib/hotplug/firmware. So it definitely finds the file when I place it there. Because I don’t care about security on my MythTV box, I chmodded the file to 777 just in case. I am running Debian Woody…. thanks for the help. I’ll keep trying. Good news, the receiver still works with your patch at least… except, it dies after about 2 hours, then I have to cold boot the machine again for the lirc device to be recognized. It isn’t an issue with your patch, but its driving me nuts!

    Thanks again.

  25. Administrator says:

    What’s the other error? Looking at the source for request_firmware, ENOENT could happen if either the firmware has zero size or the firmware load times out (default appears to be 10s). I suspect that hotplug is not returning the firmware to the driver. First off, check that you have the hotplug package installed, and that /etc/hotplug/firmware.agent exists. If so, I guess I’d start adding debugging messages to that script to see at what point it goes wrong. There’s nothing particularly special about the way that the file is downloaded, it’s just a standard request_firmware. Does it work for the ivtv stuff? They use the same method AFAICR.

    There is a thread about the receiver stopping responding on the ivtv-devel list, apparently one solution might be:

    ivtvctl –reset-ir

    Somebody has this running every minute as a cron job (!)

    There are also reports of the same thing happening with the hauppauge windows software, and I have found a version that claims to correct this. At the weekend, I hope to figure out what is causing the IR hardware to die, but I’m a bit short on time right now. I know this definitely isn’t caused by the TX patch as it happens for people with the vanilla release. It also only seems to happen if you are using the card; i.e. recording or watching TV, I can’t reproduce this without doing that.

    HTH,

    Mark

  26. Hey Mark, great work.
    I’m so close but still no cigar.

    Here are the steps I took to setup (knoppmyth r5a16):
    http://gluebox.com/lircd_irblast_steps.txt

    Here’s my output after a reboot:
    http://gluebox.com/irblast_reboot_dmesg.txt

    After “modprobe lirc_dev && modprobe lirc_i2c debug=1” my dmesg looks like this:
    http://gluebox.com/lircd_start_dmesg.txt

    Any hints, tips or thoughts would be great, – I realize you’re probably watching TV.

  27. Administrator says:

    Kind of, I’m playing with a DVB-T card now 🙂 I’ve still got the 150 hooked up though.

    It looks like the driver is loaded OK for you, which is good. However, it looks like no /dev/lirc0 or /dev/lirc1 devices have been created. This probably means that you are using a static /dev. I’m curious as to how lircd starts up without them though (I guess do ls -l /dev/lirc* to be sure).

    If they definitely aren’t present then you need to create them:

    mknod /dev/lirc0 c 61 0
    mknod /dev/lirc1 c 61 1

    Then run the lircds as before. I would at that stage check the remote with:

    irw /dev/lircd0

    Pressing buttons should show events.

    As several people have noted, my send_power script is pointing at the wrong device. I’ve updated it so that it points to the correct device (same download link), i.e. basically you want:

    irsend -d /dev/lircd1 SEND_ONCE a 0_KEY_POWER

    instead of

    irsend SEND_ONCE a 0_KEY_POWER

    At that stage, you should be making the transmitter blink. You don’t look too far off.

  28. YES!
    I’m getting blinkage.
    I think the mknod tip did the trick.

    mknod /dev/lirc0 c 61 0
    mknod /dev/lirc1 c 61 1

    Wow, big thanks!

  29. Daniel Sherwood says:

    Any info on the codeset for SKY Digibox yet.

    Maybe you could put the whole list in your blog somewhere to save future questions.

    Good work.

  30. Administrator says:

    Sorry, I don’t know. The information extracted from the hauppauge codesets is here if you want to look. You’d need to know who makes the box, as a number of people make sky boxes. Also worth googling around to see if it works with the windows software (which this basically emulates). Doing that, I have seen reports that it does not work with one or other of the PACE manufactured models.

  31. Troy Michaud says:

    It does have the IR blaster, or so the packaging says, and the cable contains both reciever and transmitter.

    I agree it looks like the chip is not detected, and it is not loading your firmware. puzzling.

  32. Troy Michaud says:

    FYI. I did some more playing today.

    Your instructions look to be ok, I am not at the location of my system to test full functionality, but I know am getting the chip recognized and firmware loaded.

    The problem was that LIRC was install via RPM a long time ago, and the new version that was compiled was not over writing (guess I should have looked to see what was there first).

    I removed the RPM, re-compiled / installed and all is looking good.

  33. Administrator says:

    This post contains details on an updated driver, however this is only to address (in hackish fashion), the problem where the remote and/or blaster stop responding.

    This won’t help if you’ve got to the blinking lights stage and can’t get the damn thing to control your TV box (has anyone checked these against the windows software btw?)

    HTH,

    Mark

  34. Dean says:

    Wow, manual commands are working for me. Dish811 tuner is turning away with manual commands and the 150 remote is working. Mark, this is really really cool!

    Can you tell us more about the change channel script or how to tell mythtv to use it or should I be looking somewhere else for the answer?

    I changed the lirc.conf blast commands to something more like this assuming this is what you mean by “rename the number keys”.
    name power
    1835010

    I’m stuck again. Any help would really be great.

    Thanks.
    Dean

  35. Clark says:

    Mark, this is fantastic. I am at the blinking light stage, however my General Instruments Cable box does not respond at all. Using WinXP and the Hauppauge ir config software, I select codeset 0039 and it functions within that enviornment. I tried selecting codeset 39 using your software. Lots of blinking, but no changing. Your step by step with a few modifications worked flawlessly to get me to the blinking stage. Any further recommendations.

  36. Administrator says:

    Dean — sorry for the long delay, I’ve been really busy with actual work. By ‘rename the number keys’ I mean something like — say you decide codeset 28 works — so irsend 28_KEY_POWER will turn the device on/off. Then delete everything else (0_KEY_…, 1_KEY…, 29_KEY… leaving just the 28_KEY_s.

    Then:

    name 28_KEY_0
    1835008
    name 28_KEY_1
    1835009

    Goes to:
    name 0
    1835008
    name 1
    1835009

    so you can just do:

    irsend blaster 1 0 0

    rather than:

    irsend blaster 28_KEY_1 28_KEY_0 …

    I hope that gives you a clearer idea. This is just because the channel changing script assumes that the number keys are called 0-9. Alternatively, you can just hack the script up to use the 28_KEY_ prefix.

    Clark: Please see my answer under the v2 post.

    Thanks,

    Mark

  37. shawn says:

    woohooo! thanks much for this. took me an evening but i finally got it working and controling my motorola digital cable box… one thing i noticed that didnt quite match up with what you have above, the lircd.conf file you link to seems to have 0_080_KEY… (basically they all have a 0_ before the code) while the send_power script doesnt have that preceding 0_ in it… once i added the 0_ to that script i got the blinking lights and then just had modify my lircd.conf file… also, did any of this make it into .7.2 final of lirc? i noticed when i went to patch .7.2 it saw one of the files as already patched… i may try it again on that version, but while i tried to figure out why i couldnt get the blinking light (i knew it worked in windows) i ended up recompiling from pre2… anyways thanks again for this!

  38. mark says:

    shawn, this stuff isn’t in the lirc-0.7.2 release. It was still being written at the time. Most of the differences that you’ve encountered are due to the fact that there is an updated patch+HOWTO (here), which corrected a few issues with the original and also tries to work around the problem where the remote control stops responding. You might want to look into that if it causes problems for you.

    Thanks,

    Mark

  39. Dave says:

    Thanks for the link. I have followed it but I cant seem to get anything
    out of Step 8. Everything up to this step seems to have worked but when I
    run this step I dont seem to be getting anything out of the IRBlaster. I
    tried the digital camera trick as well and I didnt see anything either.
    When I try to run another irsend command after the first one I get the
    following error:
    ./irsend: could not connect to socket
    ./irsend: Connection refused

    I am running Fedora Core 4 and I installed mythtv by following this guide:

    http://wilsonet.com/mythtv/fcmyth.php

    I have taken all the stuff that he had you install in the rc.local for lirc and it still didnt help.

  40. mark says:

    Old instructions, try here. irsend is telling you that lircd is not running, or that you have given it a different socket. I’ll need the command lines that you are running lircd with, and the same for irsend to provide any more help.

Leave a Reply

Your email address will not be published. Required fields are marked *