Aug
28
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!

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

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

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

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

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

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

Here’s the updated HOWTO for this version:

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


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

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

then:

make && make install.

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

#include “ivtv-gpio.h”

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

EXPORT_SYMBOL(ivtv_reset_ir_gpio);

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


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

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

5. IR blaster only: Now you need the ‘firmware’. This is
a set of data blocks that correspond to those generated by the windows software. This goes in /usr/lib/hotplug/firmware on my
debian system. Depending on your system this might also be /usr/local/lib/firmware, /lib/firmware or /lib/modules.

Note that the entire firmware is kept in memory (currently 200K) so this makes the driver quite large.
(I have no plans to sort this out, memory is cheap).

6. Check everything is working so far:

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

Check the syslog output. This should report something like:

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

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

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

8. Start lircd. Note: if you are using a static /dev, you may need to make a device for lirc. If unsure, once you have verified that the module has been loaded ok, run ls -l /dev/lirc*.
If you don’t see a /dev/lirc0 or similar, then try mknod /dev/lirc0 c 61 0 if the steps below fail.

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

9. You can now check if the remote is working using irw. Run this, and press buttons on the remote. You should see some output like

0000000000001795 00 Down Hauppauge_350.

10. Next, for the ir blaster you need to work out which codeset to use, this is the tricky bit. For this I have
send_power_new, a script that just sends the power
command in every single codeset (575 at present).

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

If you can’t get this to work:

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

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

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

That’s it, good luck!


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

  1. 1
    thylacine222 Says:

    I have installed both ivtv and lirc as per your instructions, using ivtv-0.3.7a and your patched lirc. When I attempt to modprobe lirc_pvr150 and lircdev, it replies with this:
    # /sbin/modprobe lirc_dev debug=1 && /sbin/modprobe lirc_pvr150 debug=1
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.12-1.1398_FC4/misc/lirc_pvr150.ko): Unknown symbol in module, or unknown parameter (see dmesg)

    And dmesg says:
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: Unknown symbol ivtv_reset_ir_gpio

  2. 2
    thylacine222 Says:

    Sorry, clicked submit early. I think that it said something along the lines of this when I tried to compile ivtv with patch in ivtv-0.3.7h, but I had no messages for it in 0.3.7a

  3. 3
    Administrator Says:

    I tried this with 0.3.7h, and the patch fails to apply. It’s pretty trivial, you need to add:

    #include "ivtv-gpio.h"

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

    EXPORT_SYMBOL(ivtv_reset_ir_gpio);

    right at the bottom of the file where all the other EXPORT_SYMBOL lines are. All it does is export that symbol for use by other modules.

    Try doing that and you should then be able to load the module.

  4. 4
    kenadak Says:

    using knoppmyth r5a16 (auto install) I get a error when I try to compile pre-patched lirc 0.7.2 the error is something like:

    libtool invalid option “–tag=CC”

    (not a programmer but I’ve built my share of kernals in the past)

    I have upgraded libtool to 1.5.6-6

    any recommendations?

    P.S.
    does this lirc support the remote that came with the pvr-150 in ADDITION to the blaster or am I stuck with one OR the other?

  5. 5
    Administrator Says:

    OK, can you try downloading it again (file has been updated — same URL), and let me know how it goes? (details below)

    In answer to your other question, both the remote and the IR blaster are supported. They appear a a single device, which supports both writing (irsend) and reading (irw). You can disable one or other portion with the module parameters disable_rx=1 (remote) or disable_tx=1 (IR blaster).

    Detail: basically this was me not understanding autotools at all — some hours later I think I understand it (basically I was editing a bunch of autogenerated files, which you obviously aren’t supposed to do). I’ve fixed this by regenerating those files in the right way (something like autoreconf -f -i && make dist-bzip2, with some mucking about to get an appopriate version of autoconf). None of that should matter btw, the whole point is you are just supposed to be provided with the correctly generated output in the distribution tarball.

    Thanks,

    Mark

  6. 6
    Giff Says:

    Mark,

    I attempted the new patch, and dangit if it isn’t SOOO close. After making lirc, I attempted to patch ivtv. Alas, there is no file ivtv-driver.c.patch to be found in the drivers/lirc_pvr150 directory. I’m possibly missing something, but I have followed your new directions twice to no avail.

    I skipped that one part because I couldn’t find the file, and here is the new error in dmesg:

    lirc_pvr150: Unknown symbol ivtv_reset_ir_gpio

    I’m sure that is related to being unable to patch ivtv before I recompiled it. I can’t stress how much of a help you have been through all of this. Although I’m still without a remote, the new version of IVTV still works, so no harm done, and the tuner seems much better with the development release anyways. Thanks again.

  7. 7
    Administrator Says:

    I obviously need to test my instructions a bit more! After some people had compile problems, I updated the .tar.bz2 appropriately. Unfortunately this doesn’t include the patch any more. *sigh*. Sorry about that.

    I have revised step 3 in the HOWTO to include a link to the patch (here in fact).

    You are correct in that what you are seeing is exactly what is expected with an unpatched ivtv driver.

    HTH,

    Mark

  8. 8
    Giff Says:

    Mark,

    Would it be too much trouble for you to post your relevant settings files (ie the ivtv module file) that you use for the .3.7 branch of IVTV? I am only able to compile and use ~.3.3 without having major issues (though the patch on .3.3 doesn’t seem to work), and I’m hoping they are only related to settings files for .2.0. I would really appreciate it.

    I can’t give further info at this time on specific error messages, as I’m not near my ivtv/lirc box.

  9. 9
    Administrator Says:

    Sorry, not sure what you mean by settings files. If you can let me know exactly which file(s) you are after I’ll happily send them on.

    I had a look, and the 3.3 branch (nor the 0.20 branch, which basically does not properly support the PVR150/500 anyway) will not work as it does not include the necessary support for resetting the IR device of the PVR-150. If you ask the ivtv-devel list they should be able to help you out with getting the 0.3.7 branch working with your card. If you tell me what specific issues you are having I might know, but there are far more knowledgeable people on the list.

    Mark

  10. 10
    Giff Says:

    Mark,

    One last thing – you got any info on a way I can donate financially to you for all this help? I can’t really provide coding assistance – I’m a high-level SQL and MS Studio tools guy… business IT, not nitty-gritty code. But I would like to throw in for all your hard work that saves my ass ages of pain.

  11. 11
    Giff Says:

    Mark,

    I’m beginning to be the “problem child” for you. I have everything resolved except loading haup-ir-blaster.bin. I have placed that sucker into every directory imaginable. Dmesg output shows these lines:

    lirc_i2c: chip found @ 0x71 (Hauppauge IR (PVR150))
    ivtv: i2c attach to card #0 ok [client=Hauppauge IR (PVR150), addr=71]
    lirc_dev: lirc_register_plugin: sample_rate: 10
    lirc_i2c: chip found @ 0x70 (Hauppauge IR TX (PVR150))
    ivtv: i2c attach to card #0 ok [client=Hauppauge IR TX (PVR150), addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_i2c: firmware haup-ir-blaster.bin not available (-2)

    After loading the machine, if I run “modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1”, this is shown in /var/log/messages:

    Aug 31 21:16:08 gifftv kernel: kobject_register failed for i2c ir driver (-17)
    Aug 31 21:16:08 gifftv kernel: [kobject_register+59/64] kobject_register+0x3b/0x40
    Aug 31 21:16:08 gifftv kernel: [bus_add_driver+64/160] bus_add_driver+0x40/0xa0
    Aug 31 21:16:08 gifftv kernel: [driver_register+59/64] driver_register+0x3b/0x40
    Aug 31 21:16:08 gifftv kernel: [pg0+548132078/1067987968] i2c_add_driver+0x3e/0xc0 [i2c_core]
    Aug 31 21:16:08 gifftv kernel: [pg0+559328698/1067987968] init_module+0x5a/0x60 [lirc_pvr150]
    Aug 31 21:16:08 gifftv kernel: [sys_init_module+370/560] sys_init_module+0x172/0x230
    Aug 31 21:16:08 gifftv kernel: [syscall_call+7/11] syscall_call+0x7/0xb

    Do you have any ideas? Thanks for all of the help.

  12. 12
    Administrator Says:

    Assuming this is still a debian woody system, try apt-get install hotplug.

  13. 13
    Daniel Sherwood Says:

    Mark

    Cheers for this update, it should make things a bit
    cleaner (I had modified the send_power script to reset
    the device and retry whenever a failure occurred).

    I still have a couple of issues though.

    1) My IR blaster cable only has a bare red LED on the
    end of it rather than the clear capsule containing the
    red and IR LEDs. I have requested a new one from
    Hauppage but they insist that this is how it should
    look. Any chance you could send me a photo of yours
    so I can send them this as a comparison and hopefully
    get a new one.

    2) I asked before about the codeset for the Pace SKY
    Digibox and you said that this could be found from the
    XML file. Please can you tell me how you get this
    from the XML file as all I see is a list of hex.

    Cheers

    Daniel

  14. 14
    Blerghass Says:

    I have gotten things working to the point where I can see the IR blaster blinking when sending (which is good). However, I can’t get it to control the cable box. I’ve run the send_power script several times and it doesn’t ever turn off the cable box. It works in windows, with numbers 41 or 72. Do you have any idea what could be wrong?

    I have also tried http://lirc.sourceforge.net/remotes/time_warner_cable/UR4-P360 since that is my remote control. It causes a low-level error though.

  15. 15
    Joe Says:

    I left a comment here a little while ago but it looks like it got deleted. It was under a different name. Not sure why.

    Anyway, I have the blaster blinking in red similar to what it does in Windows. However, after running the send_power script over and over I can’t get the cable box to respond at all. It works in Windows with either the numbers 41 or 72 (codesets I think). Any idea what could be wrong?

  16. 16
    Joe Says:

    I posted before but it’s not showing up. Not sure why.

    It works in Windows (codeset 41 or 72). I got the red light blinking. I’ve tried 41 and 72 KEY_POWER individually as well as send_power a few times. I can’t get the cable box to respond. Any ideas? Thanks.

  17. 17
    Joe Says:

    Sorry for the double post. Still not sure why my original post is gone.

    Daniel, a picture of the blaster can be found here:
    http://www.newegg.com/Product/Product.asp?Item=N82E16815116625
    It’s not a very good one, but it is obviously more than just a single LED.

  18. 18
    Joe Says:

    Sorry to keep posting, but I wanted to give you some more information.

    I am in the US and using the NTSC version of the PVR-150). I am using encoder firmware version 0x02040024. I am using your haup-ir-blaster.bin, and it loads as version 1.3.0. I am in gentoo with a 2.6.12 kernel.

    I have discovered that codesets 41, 72, 74, 75, 76, 78, and 313 all work in Windows. I am pretty sure that my HcwMako and HcwFalcn are the same as the ones that load in Windows.

    Does this differ from what you are using? Anything I can try?

  19. 19
    Administrator Says:

    Sorry, I haven’t had any time to work on this recently (actual work has been piling up, unfortunately).

    Here’s some more out of order replies:

    Daniel — I’ll try and find the time to take a picture of my IR blaster device, but it is a single LED in a clear plastic case (I’ve already taken it apart). So it should be ok, but I rather suspect it should have come with the case.
    The XML file has a section at the top that lists the windows manufacturer->codeset mappings, that’s where I look. However if you can’t get it to power on/power off using any of the codesets that’s not going to help.

    Joe — I’m not sure what’s going on there. I’m using the encoder firmware version 0x02050032 & ivtv-0.3.7b, but I doubt that really matters too much as the driver just talks to some embedded program running on a Zilog CPU on the board via I2C. It is possible I guess that the firmware could affect it, but I wouldn’t have thought so — I guess you can try it out to eliminate it). Do any of the other button presses work?

    I collated the data from I2C captures from the windows software. Can you point me at the windows software you are using? I can always run another capture through it if it is different.

    Sorry that’s not much help. If I can think of anything else to try I’ll let you know.

    One other person seems to have got the driver to change channels, so at least I’m not the only one now!

  20. 20
    Patrick Says:

    Ok, so I successfully loaded your PVR150 driver, and verified that all my /dev/lirc* entries existed. When I tried to submit some irsend commands, lircd segfaulted.

    I examined the debug output and didn’t see anything I could decipher. I do have one question, are you running this on an SMP kernel?

    Here’s the output of my dmesg:
    lirc_dev (lirc_pvr150[0]): open called
    lirc_dev (lirc_pvr150[0]): ioctl called (0x80046900)
    lirc_dev (lirc_pvr150[0]): ioctl called (0x40046911)
    lirc_dev (lirc_pvr150[0]): ioctl called (0x40046912)
    lirc_dev (lirc_pvr150[0]): ioctl called (0x8004690f)
    lirc_dev (lirc_pvr150[0]): poll called
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_dev (lirc_pvr150[0]): poll called
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_dev (lirc_pvr150[0]): write called
    lirc_pvr150: failed to get data for code 0, key 400 — check lircd.conf entries
    lirc_pvr150: sending to the IR transmitter chip failed, trying reset
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    printing eip:
    00000000
    *pde = 00000000
    Oops: 0000 [#2]
    SMP
    Modules linked in: lirc_pvr150 lirc_dev isofs zlib_inflate nls_iso8859_1 vfat fat wm8775 firmware_class tuner tveeprom ivtv videodev parport_pc lp parport snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore usbcore radeon drm intel_agp agpgart sbp2 ohci1394 ieee1394 3c59x mii st
    CPU: 0
    EIP: 0060:[] Not tainted VLI
    EFLAGS: 00210286 (2.6.11-gentoo-r9)
    EIP is at 0x0
    eax: fffffff2 ebx: 00000000 ecx: 000002cc edx: 00000007
    esi: 00000000 edi: 00000000 ebp: 00000000 esp: c5f93f5c
    ds: 007b es: 007b ss: 0068
    Process lircd (pid: 25778, threadinfo=c5f92000 task=dfbf3020)
    Stack: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    Call Trace:
    Code: Bad EIP value.
    lirc_dev (lirc_pvr150[0]): close called

    Thanks for your work on this!
    -Patrick

  21. 21
    Joe Says:

    I got all my windows software from here: http://www.hauppauge.com/pages/support/support_pvr150.html
    Specifically, I used that IR blaster setup program in “Accessories” with some of the other files there.

    I don’t know why my firmware version is different from yours. I pulled my .rom files from /windows/system32/drivers or something like that. I’m not sure where to get other firmware. I also do not know why your firmware is newer than mine.

    I am in ivtv-0.3.7c. Everything on my system is happy except that the IR blaster doesn’t affect the cable box.

  22. 22
    Administrator Says:

    I’ll try it with some older firmware this evening and get back to you. There are a whole stack of firmware images on the ivtv firmware page if you want to try it sooner.

  23. 23
    Administrator Says:

    Patrick: that’s a kernel oops, which is caused by a bug in the driver. Somebody else pointed this out to me recently. It is caused by sending invalid key codes to the driver. Please check that you are using the version of lircd.conf linked to above, it should work then (you’ll probably have to reboot though if you haven’t done so already).

    I’m using it on a UP kernel, but I don’t believe that that is the issue.

  24. 24
    Joe Says:

    Mark, are you using the same hardware as me otherwise? NTSC pvr150, US bought? I just got it recently, I don’t know if there are any revision numbers or anything. BTW, I’m on an i815 system with a tualatin celeron, sb live, gf2mx, not much else. I don’t think this would affect it, but who knows.

    Gonna try the newer firmwares now–I’ll let you know.

  25. 25
    Joe Says:

    02050032 didn’t work. What else should I try?

  26. 26
    a crick in the net » Yay! Says:

    […] I think I have the reference I need: it’s nice to find a page that solves the problems you haven’t encountered yet. But I’m reaching the tiredness point I was at last night where no further progress was made. […]

  27. 27
    Joe Says:

    Mark,

    I really appreciate your help here. I noticed something weird in the Windows software that may be related. This is in the simpler “blastcfg” part of the software. When I put code 72, it works only if I have “cable box” selected. If I have “satellite” selected, still code 72, it does not turn off my cable box, even though it still flashes red. Is there some other state bit in the card that may be important? I figured it could be relevant since it is the same light blinking, but no IR effect symptom.

    By the way, I tried 0x02040011 also, no dice. Thanks again.

  28. 28
    Administrator Says:

    Ah, thanks — I think you’ve probably nailed it there. I didn’t realise that satellite vs cable box made a difference, whereas it obviously does — I though that only the codeset number was important.

    Unfortunately it’s not even as simple as a state bit; the data block (99 bytes) seems to change substantially even between runs of the application. So basically what I need to do here is another I2C capture of all of the codesets again (hurrah!), and regenerate the ‘firmware’. I will attempt to do this in a bit. I’ll try and see if the other fields make any difference at the same time. After I’ve done that, I’m pretty optimistic that it will work for you.

    Thanks,

    Mark

  29. 29
    Joe Says:

    Thanks so much for your fast response! I’m excited now, this is the last step to making my myth box work.

    I’ll keep checking the page to look for the update.

    Hopefully this will help lots of cable box people.

  30. 30
    Administrator Says:

    I have done some experiments, and it appears that the selected device definitely changes the data that the hauppauge stuff sends over the I2C bus. To be a bit more thorough I changed the vendor & region settings as well, but they don’t appear to make any difference. I’m running another capture now, then I’ll have to post process the data + update the software to cope with it — I don’t know if I’ll manage to finish it tonight, but I’ll give it a go. I’ll send you an email when I’ve finished so you don’t have to keep checking back with this page. Funnily enough, I do happen to have a cable box but it responds as a satellite box.

    Thanks for you help with this — that was a really sharp piece of detective work.

    Mark

  31. 31
    Joe Says:

    No hurry, I won’t be able to test this tonight. Looking forward to it tomorrow though. Thanks again.

  32. 32
    Administrator Says:

    Patrick — your oops — that’s when trying to reset the IR chip. There is a bug in the code (it shouldn’t bother resetting the IR chip when sent an invalid code), but it’s actually the call to ivtv_reset_ir_gpio that’s causing it.

    Can you send me the complete dmesg output after loading the module & then the output of lsmod so I can try and track this down? Plus can you let me know which version of the ivtv driver you are using?

    What strikes me as really weird is that the “modules linked in” output from the oops doesn’t show ivtv — but lirc_pvr150 requests ivtv explicitly in the init_module function. It really looks like ivtv isn’t loaded, which ought not be possible.

    Thanks,

    Mark

  33. 33
    Clark Says:

    Mark,
    You are a king, I am in the exact same situation as Joe, light is blinking again after running through your version 2 instructions. I tested the same process as Joe in windows, using my codeset 39, and my cable box responds the same. Looking forward to your updated captures. Best regards,

    Clark

  34. 34
    JerseyJoe Says:

    Mark,

    Having the same issue as Clark and Joe, but I donn’t have a Windows side to boot too. I am fairly certain that once you get the new stuff out it should work. BTW I my Cable Box is a Scientific Atlanta Explorer 4200 from Cablevision/Optimum Online in Morristown, NJ, USA. I include this information as I am curious if Joe and Clark have anything in common with my setup.

    I have a question though. I tried putting some remote configs in my /etc/lircd.conf that should work with my cable box, but they only caused the lircd program to segfault when I called an irsend for any of the codes under these remotes. Just curious why your remote codes work and those others cause a segfault. Anyway the offending remote conf files are here.

    http://lirc.sourceforge.net/remotes/scientific_atlanta/

    Joe

    PS: Email me sometime as I think you might be able to help me out with another computer problem with my Gyration MCR having buttons that only work under Windows but not linux. If you can help me out with that I will make it worth your while.

  35. 35
    JerseyJoe Says:

    Hmm I posted a comment here yesterday but it didn’t seem to register.

    I am having the exact same issue as both Joe and Mark. I am curious to know what there equipment is, what the providor name is, and their location for comparison. I am using a Scientific Atlanta Explorer 4200 from Cablevision/Optimum Cable in Morristown, NJ, 07960

    I have a few questions. Like, why I get a segfault from your patched lircd when I tried out irsend using one of the remote configs from sourceforge site. I just appended the 2 for Scientific Atlanta to the end of the lircd.conf file that you supplied and restarted lircd. All your stuff still works but the new configs cause a segfault of the lircd. Any idea why? I don’t know enough about this stuff to guess at it.

  36. 36
    Administrator Says:

    They don’t register until I approve them — sorry I don’t get around to it quite as fast as I’d like sometimes.

    You can’t use anything other than the appropriate configuration files. All my stuff has is a list of codeset/key press numbers, so if you send something else to it it can’t do anything. Other sorts of receiver/transmitter have frequencies and pulse timings, etc — these kind of configuration files simply won’t work. I’m not sure why lircd segfaults though — it ought not do that, so I’ll try and reproduce this and fix it — all that should happen is that you get some kind of error message.

    I have done a capture and created some updated firmware with all of the cable box data as well as the satellite data, but I’ve yet to test it. Unfortunately I won’t have time to do this today as I’m now off to celebrate regaining the ashes 🙂

  37. 37
    Joe Says:

    If you have the firmware file ready but not tested, would you mind posting it or e-mailing it to me so that I can test it tonight? I’ll let you know if it works for me. Thanks!

  38. 38
    Joe Says:

    I tried the new firmware and lircd.conf. It loaded 575 codesets, which was a good sign. Unfortunately, it didn’t work. Here’s what happened:

    irsend: command failed: SEND_ONCE a 1_0_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_1_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_2_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_4_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_5_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 0_6_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_6_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 0_7_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_7_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 0_8_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_8_KEY_POWER
    irsend: transmission failed

    Even the old “blaster” codesets also failed. Thanks for your help, and let me know if I can help you with anything to finish this up.

  39. 39
    Administrator Says:

    I wasn’t that surprised, as I said I hadn’t tested it at all! I’ve tested it properly now and fixed the issue that was preventing transmission from working. It still works for me with the old list of codesets that my device responds on, so apart from additional codesets it should be as it was.

    Please download haup-ir-blaster.bin, lircd.conf, and send_power_new again and let me know how you get on with those. You’ll need to unload & reload the lirc_pvr150 module in order to get it to pick up the updated “firmware”.

    Codesets are named DEVICE_CODESET_KEY, e.g. 0_41_KEY_POWER for cable box, codeset 41, power button or 1_41_KEY_POWER for satellite box, codeset 41, power button, etc.

    Good luck!

    Mark

  40. 40
    Joe Says:

    What did you need to fix? Just curious.

  41. 41
    Administrator Says:

    The key/codeset pair form a 32-bit number that lircd sends to the driver, the upper 16 bits are the codeset & the lower 16 bits are the key. To accomodate having two variants of each codeset I elected to set bit 31 (top most bit, previously unused) to indicate which device the codeset was for. Effectively this just renumbers the codesets (so the base driver doesn’t need to change).

    After some long winded process involving poking the windows driver and capturing the results, I run some perl scripts to post process this data and generate the ‘firmware’ – a codeset/key database. In that database each codeset has a header including the ID; this clearly ought to be a 16-bit number but in the version I knocked up before heading out to the pub I’d shifted left the device ID by 31 rather than 16 bits. That was the first issue.

    The other problem was that the codeset database is ordered by codeset id, and searched using a binary chop algorithm, thus it needs to be sorted by codeset id. The database generation script also needed to be updated to take account of setting the top bit so that the codesets end up correctly sorted in the database.

    Nothing I wouldn’t have caught during normal testing, but you did ask for it early!

  42. 42
    Clark Says:

    Mark,

    Write a book and send us your paypal, your information is as good as gold. I am up and running 100% after following your posts. I run a General Instruments Cable box that uses the standard DCT2000 Motorola remote codes. I can’t thank you enough and my wife will be glad to get the media center back in a much mre functional state.

    Best regards,
    Clark

  43. 43
    Joe Says:

    Success! Thanks so much. Amazing turnaround time on the driver fixing. I’m going to finalize my setup now. 🙂

  44. 44
    J. Longman Says:

    Hi there,

    I’m trying to use your code to control my cable box, and I’ve gotten stuck. I started with Knoppmyth, but have taken the ivtv 0.3.9 drivers (I haven’t tested if sound works yet, but video does) and your lircd patch together and am having a few problems.

    Now I should mention that I also have a kworld bttv card in the machine, as well as a non-MCE PVR-150.

    Earlier I was seeing what looked like a connection to a bt878 right where it should have said something about establishing a connection, and I could never get lircd and irw to connet to each other.

    But since then I noticed that I didn’t have lirc_i2c modprobe’d. So I modprobe’d lirc_i2c, lirc_dev and then when I modprobe lirc_pvr150 I get in my dmesg:

    kobject_register failed for i2c ir driver (-17)
    [] kobject_register+0x3b/0x40
    [] bus_add_driver+0x40/0xa0
    [] driver_register+0x3b/0x40
    [] i2c_add_driver+0x3e/0xc0 [i2c_core]
    [] init_module+0x5a/0x60 [lirc_pvr150]
    [] sys_init_module+0x172/0x230
    [] syscall_call+0x7/0xb

    but lircd and irw do seem to connect, but nothing is printed, and if I run the send_etc it says the device has no TX capability.

    Finally, if I try to rmmod lirc_pvr150 I get a segmentation fault. (previously to modprobe’ing lirc_i2c I could do this).

    So, is lirc_i2c required?
    I noticed that there is an adapt_struct or somesuch passed into the driver, is it possible to the wrong one is passed in? and is it possible to control which one is passed in?
    Any further suggestions?

    I leave you with my boot dmesg (sorry and thanks!):

    bttv0: using: Jetway TV/Capture JW-TV878-FBK, Kworld KW-TV878RF [card=78,insmod option]
    bttv0: gpio: en=00000000, out=00000000 in=003fffff [init]
    tuner 1-0060: chip found @ 0xc0 (bt878 #0 [sw])
    bttv0: using tuner=2
    tuner 1-0060: type set to 2 (Philips NTSC (FI1236,FM1236 and compatibles))
    bttv0: i2c: checking for TDA9875 @ 0xb0… not found
    bttv0: i2c: checking for TDA7432 @ 0x8a… not found
    bttv0: i2c: checking for TDA9887 @ 0x86… not found
    bttv0: registered device video0
    bttv0: registered device vbi0
    bttv0: registered device radio0
    bttv0: PLL: 28636363 => 35468950 .. ok
    ivtv: ==================== START INIT IVTV ====================
    ivtv: version 0.3.9 (development svn snapshot revision ) loading
    ivtv: Linux version: 2.6.11.9-chw-2 SMP preempt 586 gcc-3.3
    ieee1394: Host added: ID:BUS[0-00:1023] GUID[00e01800001fccb3]
    ivtv: In case of problems please include the debug info
    ivtv: between the START INIT IVTV and END INIT IVTV lines when
    ivtv: mailing the ivtv-devel mailinglist.
    ivtv: Autodetected WinTV PVR 150 card (iTVC16 based)
    ACPI: PCI interrupt 0000:02:09.0[A] -> GSI 21 (level, low) -> IRQ 21
    ivtv: i2c attach to card #0 ok [client=tveeprom, addr=50]
    ivtv: i2c attach to card #0 ok [client=(tuner unset), addr=61]
    tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    tveeprom: Hauppauge: model = 26032, rev = C199, serial# = 8003342
    tveeprom: tuner = (idx = 99, type = -605520296)
    tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x00001000)
    tveeprom: audio_processor = TDA9850 (type = 3)
    cx25840: loading /lib/modules/HcwMakoA.ROM
    cx25840: unable to open firmware
    ivtv: i2c attach to card #0 ok [client=cx25840[50], addr=44]
    ivtv: i2c attach to card #0 ok [client=wm8775, addr=1b]
    ivtv: loading /lib/modules/ivtv-fw-enc.bin
    ivtv: Encoder revision: 0x02040011
    ivtv: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    ivtv: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    ivtv: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    ivtv: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    ivtv: Create encoder radio stream
    tuner 2-0061: type set to 47 (LG NTSC (TAPE series))
    ivtv: Initialized WinTV PVR 150, card #0
    ivtv: ==================== END INIT IVTV ====================
    cx2388x v4l2 driver version 0.0.4 loaded
    lirc_i2c: chip found @ 0x71 (Hauppauge IR (PVR150))
    ivtv: i2c attach to card #0 ok [client=Hauppauge IR (PVR150), addr=71]
    lirc_dev: lirc_register_plugin: sample_rate: 10
    ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 17

  45. 45
    Administrator Says:

    You don’t need lirc_i2c and loading as well as lirc_pvr150 it is indeed likely to cause issues as they will try and claim the same device. Please send me the dmesg output from modprobe lirc_pvr150 after a fresh boot and we’ll see where it is going wrong from there.

  46. 46
    J. Longman Says:

    Well, that’s a relief! I’ll have to try it again when I get home. Thanks for your help. I wish I had captured the output before as I suspect its something really simple. e.g. I noticed that the lirc_pvr150 module had a “minor” option – but it didn’t seem to make a difference.

    Would /dev/lirc* need to be chmod’d 666? I think I noticed that in the Lirc docs – but since I was running as root I didn’t think about it too much.

    Thanks!

  47. 47
    Administrator Says:

    “minor” just sets the preferred minor device number, not really relevant unless you are loading multiple lirc drivers and want to be sure which /dev/lircX will be created (hotplug) or used (static).

    Setting the permissions on /dev/lircX is only relevant if you aren’t running lircd as root. /dev/lircdX is a socket created rw to all by default (see man lircd to change the permission set). The usual case is running lircd as root & not really caring which users have access to the device so unless you are particularly security conscious or are encountering a specific issue there’s no reason to manipulate the permissions.

  48. 48
    J. Longman Says:

    Looking at your initial instructions, and thinking back to yesterday, what was missing was a line similar to

    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
    (my bold, er, if it works – bold around the udev line)

    Will a (static) equivalent to this line appear if I’m not using udev (as I don’t believe Knoppmyth does)? I did an apt-get install hotplug, so I believe I do have hotplug – had to in order to make the firmware happy.

    I’m looking at the patch and I see where I have to pay attention next time — in the ir_probe method.

  49. 49
    Giff Says:

    Mark,

    I believe I may be having the same problems as the gentleman above. lirc_i2c is loading upon boot. How would I disable this permanently? lirc_pvr150 successfully loads, but I’m still having the remote lockup problem, and I’m assuming this is because lirc_i2c is still in control of the IR device. I also believe this may be the reason I am unable to load the firmware, even though hotplug is installed and running, and the firmware is in the correct location.

    Thanks.

  50. 50
    Administrator Says:

    J. Longman: no ‘static’ equivalent would appear. ‘static’ means that you have to create everything in /dev yourself with mknod. If you can send me the output from “modprobe lirc_pvr150 debug=1” then I should be able to figure out where to go from there.

    Giff: not sure, depends on what you have that is loading it automagically — have a look in /etc/modules, for example.

    That shouldn’t affect firmware loading, however. Are you sure you’ve got hotplug installed? Do things like /sbin/hotplug & /etc/hotplug/firmware.agent exist? If you really can’t get it going and you are willing to let me prod around with an SSH session then I can see if I can spot anything.

    Mark

  51. 51
    Giff Says:

    Mark,

    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.

  52. 52
    Administrator Says:

    It’s mark@npsl.co.uk. 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.

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

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

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

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

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

  58. 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 (mark@npsl.co.uk).

    Thanks,

    Mark

  59. 59
    J. Longman Says:

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

    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

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

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

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

  63. 63
    Lee Says:

    Mark,
    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)

    Thanks,
    Lee

  64. 64
    Giff Says:

    Mark,

    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.

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

    Thanks,

    Mark

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

  67. 67
    Lee Says:

    Mark,
    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,
    Lee

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

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

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

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

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

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

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

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

    #!/usr/bin/perl
    ####################################################
    # 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;
    while()
    {
    $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/raw.codes/)
    {
    print (OUTLIRC “\t\t$phrase”);
    $copyit = 0;
    }
    last if ($phrase =~ m/raw.codes/) ;
    }
    while()
    {
    print(OUTLIRC $_);
    }

    close IN;
    close OUTLIRC;

  76. 76
    joelones Says:

    hi,
    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

    thanks

  77. 77
    joelones Says:

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

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

    Christian

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

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

    HTH,

    Mark

  81. 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)?

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

    http://www.blushingpenguin.com/mark/lmilk/change_channel

    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.

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

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

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

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

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

    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

  87. 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 mark@npsl.co.uk.

    HTH,

    Mark

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

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

  90. 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/lircd1.pid. 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.

    HTH,

    Mark

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

  92. 92
    scott Says:

    im now using this as a channel change script

    #!/bin/sh
    REMOTE_NAME=blaster
    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
    done

    seems to work fine…

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

    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

  94. 94
    scott Says:

    k fixed the ir by
    rmmod lirc_pvr150
    and
    modprobe lirc_pvr150

    and im back to working…

  95. 95
    scott Says:

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

    /sbin/modprobe lirc_pvr150
    /usr/local/sbin/lircd

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

  96. 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/bootmisc.sh
    and add at the bottom

    modprobe lirc_pvr150
    lircd

    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.

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

  98. 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/lircd1.pid
    irsend -d /dev/lircd1 SEND_ONCE blaster xxx

  99. 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 ( http://lirc.sourceforge.net/remotes/free/Freebox ).

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

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

    http://mysettopbox.tv/phpBB2/viewtopic.php?p=35697#35697

  101. 101
    scott Says:

    again jumped the gun, that worked except when i rebooted, it killed it. comes back with a
    irsend: could not connect to socket
    irsend: Connection refused

    error. im going to look in to it when i get home from work.

  102. 102
    mark Says:

    I think you just need to add the line that runs lircd to your boot script (and possible the mknod if /dev/lirc1 is not present on reboot).

    The donate link is at the top right — under pages (or here).

    Thanks!

    Mark

  103. 103
    mark Says:

    Pascal: I don’t know what outputs the device is capable of generating. You certainly can’t send SPACE_ENC to it as though it was a homebrew device — I don’t have enough information about the hardware/software to make it work like that (although I’m hoping to get this information from Hauppauge at some point).

    The only thing I can do with it is what the windows software does — which is to replay outputs that Hauppauge have captured (and then I captured from their software). If your device is relatively common, there’s a good chance that one of their captured codesets works with it. If it’s rare, a good chance not. In any case, it’s probably worth running the procedure above to see if it responds to any of their captured codesets. If not, unless you can figure out the format of the 99 byte data blocks they send to the device, I don’t think you’ll be able to do what you want with it.

    HTH,

    Mark

  104. 104
    Scott Says:

    Mark, Got it working b4 i went to work, man im on a high now – cant wait to leave and get the rest working – im moving in 3 days to my new place, and this one was for my parents so i definetly had to finish it. Now my only concern is to make some kind of restore disk for them, if they mess it up, Does anyone out there know if there is a program that i can make a bootable restore cd (or dvd) for linux? like a norton ghost or something? that will boot, and give them the option to restore?

    here is what i did to my boot

    i added
    lircd –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lircd1.pid
    to the bottom of the file, so now my /etc/init.d/bootmisc.sh file looks like

    modprobe lirc_pvr150
    lircd
    lircd –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lircd1.pid

    Im going to donate you the amount of a case of Canadian Beer, this is well worth the efforts. Thank You again!

  105. 105
    Pascal Says:

    Mark, thanks for the clarifications. I ran send_power_new a few more times and eventually it worked.

    In case anyone cares, the PVR150 codeset for the Freebox V4 is 462.

  106. 106
    AkJohn Says:

    Ok, this might sound incredibly stupid, but I’ve spend 3 days on it already so here goes. Where does one find the ivtv driver files (ie ivtv-driver.c) on Fedora Core 4 in order to patch them as discussed in step 3? I installed ivtv via rpm so I’m not sure if I even have this code. I tried installing an ivtv.blah.src.rpm but still no joy.

    Any suggestions?

  107. 107
    AkJohn Says:

    Ok, disregard my previous message… I’ve gotten past that stupidity (kind of). I’ve managed to add the patch (manually) and make && make install seems to run successfully. I then configured and did make && make install on the lirc patch. I seem to be having the same problem as the guy in the first post:
    /sbin/modprobe lirc_pvr150 debug=1
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.12-1.1456_FC4/misc/lirc_pvr150.ko): Unknown symbol in module, or unknown parameter (see dmesg)

    I know I’ve added the symbol export to ivtv-driver.c (quadruple checked)… Is it possible my install quietly barfed and I’m loading the old ivtv module? I’m running FC4, if that helps…

    dmesg output is as follows:
    ivtv: ==================== START INIT IVTV ====================
    ivtv: version 0.3.8 (tagged release) loading
    ivtv: Linux version: 2.6.12-1.1456_FC4 686 REGPARM 4KSTACKS gcc-4.0
    ivtv: In case of problems please include the debug info
    ivtv: between the START INIT IVTV and END INIT IVTV lines when
    ivtv: mailing the ivtv-devel mailinglist.
    ivtv: Autodetected WinTV PVR 150 card (iTVC16 based)
    ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [LNK2] -> GSI 5 (level, low) -> IRQ 5
    tveeprom: Hauppauge: model = 26032, rev = C199, serial# = 8239201
    tveeprom: tuner = TCL 2002N 5H (idx = 99, type = 50)
    tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x00001000)
    tveeprom: audio processor = CX25841 (type = 23)
    tveeprom: decoder processor = CX25841 (type = 1c)
    ivtv: i2c attach to card #0 ok [client=tveeprom[50], addr=50]
    tuner: chip found at addr 0xc2 i2c-bus ivtv i2c driver #0
    ivtv: i2c attach to card #0 ok [client=(tuner unset), addr=61]
    cx25840: loading /lib/modules/HcwMakoA.ROM
    ivtv: i2c attach to card #0 ok [client=cx25840[50], addr=44]
    ivtv: i2c attach to card #0 ok [client=wm8775[50], addr=1b]
    ivtv: loading /lib/modules/ivtv-fw-enc.bin
    ivtv: Encoder revision: 0x02040024
    ivtv warning: Encoder Firmware can be buggy, use version 0x02040011!!!!
    ivtv: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    ivtv: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    ivtv: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    ivtv: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    tuner: type set to 50 (TCL 2002N) by ivtv i2c driver #0
    ivtv: Initialized WinTV PVR 150, card #0
    ivtv: ==================== END INIT IVTV ====================
    lirc_pvr150: Unknown symbol ivtv_reset_ir_gpio

    notice that it says it’s loading 0.3.8 (tagged release)… How do I know which module I’m actually loading???

  108. 108
    Scott Says:

    Hey Mark,

    Quick one for you, i have everything installed and the remote stops responding for about 2 minutes at a time, an output of dmesg reveals the following.

    lirc_pvr150: i2c_master_send failed with -121
    lirc_pvr150: polling the IR receiver chip failed, trying reset
    lirc_pvr150: i2c_master_send failed with -121
    lirc_pvr150: polling the IR receiver chip failed, trying reset
    lirc_pvr150: i2c_master_send failed with -121
    lirc_pvr150: polling the IR receiver chip failed, trying reset
    i2c_adapter i2c-2: sendbytes: error – bailout.
    lirc_pvr150: i2c_master_send failed with -14
    lirc_pvr150: polling the IR receiver chip failed, trying reset
    lirc_pvr150: i2c_master_send failed with -121
    lirc_pvr150: polling the IR receiver chip failed, trying reset
    lirc_pvr150: i2c_master_send failed with -121
    lirc_pvr150: polling the IR receiver chip failed, trying reset
    i2c_adapter i2c-2: sendbytes: error – bailout.
    lirc_pvr150: i2c_master_send failed with -14
    lirc_pvr150: polling the IR receiver chip failed, trying reset
    lirc_pvr150: i2c_master_send failed with -121
    lirc_pvr150: polling the IR receiver chip failed, trying reset

    any ideas? seems its doing what it should be, (restarting the IR chip if it freezes up) but not right when it dies.

  109. 109
    mark Says:

    Hi Scott,

    Thanks very much for your generous donation. Sorry to hear that you’re having troubles — I haven’t seen this problem with my set up. Some questions:

    – Can you send me the dmesg output with modprobe i2c-algo-bit i2c_debug=3, keeping the log times as well?
    – Are you doing anything else with the card at the same time? Basically, listing any steps that you take to cause the problem would help me to try and get it to happen for myself.

    I see the remote drop out occasionally for a few seconds (max about 10) corresponding with the reset log entries, but it doesn’t reset the chip that often for me.

    Thanks,

    Mark

  110. 110
    mark Says:

    akjohn: sorry this is out of order. It seems that either you are loading the old module, or you didn’t do depmod -a after installing the new one. depmod -a should report any unresolved symbols.

    modinfo ivtv will tell you which module it wants to load. You can check md5sums to see if it is the same as your built version, and objdump -t |grep ksymtab to see if it exports the symbol properly.

    This has got to be one of:

    – depmod not re-run
    – wrong module
    – patch not applied correctly

    with the likelihood that it’s one of the first two.

    HTH,

    Mark

  111. 111
    scott Says:

    Mark, im sorry man, im still learning alot about linux, can you explain to me exactly what you want me to do, ie:

    #modprobe i2c-algo-bit i2c_debug=3
    #dmesg

    is this right?

  112. 112
    akjohn Says:

    Mark,

    Thanks for your reply. It turned out that I was loading the wrong module. Apparently fedora keeps it’s modules in a strange directory so make install didn’t put them in the “right” place. I just replaced the old modules with the new and everything is working wonderfully now! Thanks a ton for putting this info together! Now all I have to do is get stubborn mythtv to actually call my changechannel script and I’ll be set (it’s always something isn’t it?)…

    Again, thanks for the help and info.

    John

  113. 113
    CyberCSK Says:

    Hi!
    I can’t compile lirc. I downloaded lirc-0.7.2pvr150 and configured it. But when I type make I get the following warnings and errrors.

    Can anyone help me?

    lirc_pvr150.c: In Funktion »add_to_buf«: lirc_pvr150.c:200: Warnung: implicit declaration of function `i2c_get_adapdata’ lirc_pvr150.c:200: Warnung: Verarbeiten des Argumentes 1 von »ivtv_reset_ir_gpio« erzeugt Zeiger von Ganzzahl ohne Typkonvertierung lirc_pvr150.c: In Funktion »lirc_thread«: lirc_pvr150.c:259: Warnung: implicit declaration of function `lock_kernel’ lirc_pvr150.c:259: Warnung: implicit declaration of function `unlock_kernel’ lirc_pvr150.c: In Funktion »fw_load«: lirc_pvr150.c:580: error: structure has no member named `dev’ lirc_pvr150.c: In Funktion »write«: lirc_pvr150.c:971: Warnung: Verarbeiten des Argumentes 1 von »ivtv_reset_ir_gpio« erzeugt Zeiger von Ganzzahl ohne Typkonvertierung lirc_pvr150.c: In Funktion »i2c_attach«: lirc_pvr150.c:1178: error: Fehler beim Parsen before “do” make[6]: *** [lirc_pvr150.o] Fehler 1 make[6]: Leaving directory `/var/lib/video.00/driver/lirc-0.7.2pvr150/drivers/lirc_pvr150′ make[5]: *** [_mod_/var/lib/video.00/driver/lirc-0.7.2pvr150/drivers/lirc_pvr150] Fehler 2 make[5]: Leaving directory `/usr/src/kernel-source-2.4.27′ make[4]: *** [lirc_pvr150.o] Fehler 2 make[4]: Leaving directory `/var/lib/video.00/driver/lirc-0.7.2pvr150/drivers/lirc_pvr150′ make[3]: *** [all] Fehler 2 make[3]: Leaving directory `/var/lib/video.00/driver/lirc-0.7.2pvr150/drivers/lirc_pvr150′ make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/var/lib/video.00/driver/lirc-0.7.2pvr150/drivers’ make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/var/lib/video.00/driver/lirc-0.7.2pvr150′ make: *** [all] Fehler 2

  114. 114
    mark Says:

    scott: I sent you a mail that hopefully should explain what I meant in more detail. I’m going to look at disassembling the hauppauge driver to see if I can figure anything out from it tomorrow (although that will take some time to complete).

    akjohn: Great, I’m glad you got it working!

  115. 115
    mark Says:

    CyberCSK: I think this will only compile against a 2.6 kernel. If possible, can you try upgrading your kernel?

    If not, I might be able to look at getting it to compile with a 2.4 series sometime next week.

  116. 116
    Pascal Says:

    A few days ago I reported my set-top-box responds to codeset 462. Unfortunately there are only 15 keys for codeset 462 in lircd.conf, whereas my remote has 35 buttons.

    Mark, is this because the Windows software from Hauppauge only supports those 15 keys ? Or is this related to the way you extracted the codes ?

    I had a look at the 99-byte blocks for this codeset and found some correlations with the IR pulse bits, but I can’t make sense of all the data. Has anyone succeeded in generating blocks, maybe for other codesets ? Any hints ?

  117. 117
    mark Says:

    This is because the windows software only supports those 15 keys. I’m curious as to why this is an issue? The only use I can think of for remote controlling your cable/sat box is to change channel so that you can record the right program with myth, or equivalent. Thus the only keys you need are going to be numbers 0-9, with maybe the two digit button and power (if you want to turn it on/off before/after recording).

    In terms of generating new codesets, as previously stated, I have no idea how to do this. All I’ve got is the data I captured from the windows software. I’d be interested to know what correlations you found though.

    It is possible that some understanding could be gained by disassembling the hauppauge driver. It’s not that simple though as there aren’t really very many starting points (sure, I can see the top level function that gets the data, but after that it’s a lot of bit twiddling and tables so I would reckon on a few days work before I knew what was happening with it).

  118. 118
    Mark’s Braindump » PVR-150 IR stops responding (maybe fixed!) Says:

    I’ve posted some details about a potential fix for the root cause of the remote dropping out – although it resets it, there are still a few seconds of unavailability, which is annoying. Some people have reported that this is minutes though, so I’ve looked into it more deeply and come up with what I believe is a fix. See the post for the full details, but basically this is working well for me so far (no IR chip resets in about 16 hours so far).

  119. 119
    Pascal Says:

    > The only use I can think of for remote controlling your cable/sat box is to change channel

    The set-top-box sits in a closet with all the other rack-mounted
    hardware, so I’d rather not use the original remote at all, even
    for the other functions.

    Another issue: In order to trigger some functions, I need to keep a button depressed for ~1 second. It seems that lirc_pvr150 can’t repeat codes
    fast enough to simulate this. I patched your driver to download the data block only once, and also tried to insert delays between the I2C sends, with no result. Any ideas ?

  120. 120
    mark Says:

    Hmm, interesting. What exactly did you try? Repeating the W 00, load of NAKS, r 80 bit? The ‘load of NAKs’ take a while (up to 100ms), so that might be slower than the repeat rate of your remote, hence the box thinks that the key has been released. Alternatively your remote might use a repeat bit which isn’t being set in the transmitted code (I think most of them use a toggle bit and a timer though).

    In any case, it seems that what you want to do requires a greater understanding of the data block than we currently have. I had a look over your analysis of the data blocks, but I don’t see anything much in them from a quick glance. I’ll try and have a more detailed look at the weekend. It might be worth just twiddling the bits and seeing whether you can get a different remote button to be output. I expect it would be pretty helpful to have a parallel/serial port receiver or the like and record the output from the device with the lirc_xxx driver so you can see exactly what effect your having.

    As far as repeat rate goes, what exactly did you change in the driver?

  121. 121
    Pascal Says:

    OK, the repeat issue is fixed. I was incorrectly assuming that lircd would send multiple keypresses to the driver in a single write, but actually the repeat period is configured with the “gap” field in lircd.conf, and the default value was simply too high.

    Please consider this patch, though.

    – for (i = 0; i

  122. 122
    Pascal Says:

    HTML filter ate my patch…

    – for (i = 0; i < n; )
    + for (i = 0; i+sizeof(lirc_t) <= n; )
    {
    int ret = 0;
    lirc_t command;

    printk(“sending %d %d\n”, i, n);
    – if (copy_from_user(&command, buf + i, n)) {
    + if (copy_from_user(&command, buf + i, sizeof(lirc_t))) {

  123. 123
    mark Says:

    Oh nice! I’m surprised that hasn’t blown up in my face before — I guess the way I use it lirc is only sending one command at a time. I shall fix it forthwith!

    Thanks,

    Mark

  124. 124
    mark Says:

    OK, should be fixed (package/patch updated). I removed the “i+sizeof(lirc_t) <= n;" check as it already ensures that n % sizeof(lirc_t) == 0.

  125. 125
    CyberCSK Says:

    Hi!

    [QUOTE]
    If not, I might be able to look at getting it to compile with a 2.4 series sometime next week.
    [/QUOTE]

    I don’t think that its a good idea for me to upgrade the kernel, because it took me quite long to set my system up.

    I would be very happy if you made the kernel compatible with 2.4.27.

    I hope it’s not too much work…

    thx
    CyberCSK

    btw: the reason why I want to try your lirc version is, that my PVR 150 doesn’t recognize the remote under linux (with newest ivtv driver and lirc with pvr patch), unless I previously booted XP and then rebooted to linux.
    Have you any idea what i can do?

    I discribed my problem here: http://www.gossamer-threads.com/lists/ivtv/devel/21952?search_string=remote%20150;#21952

  126. 126
    mark Says:

    Hi,

    Unfortunately I’m not sure that my driver will help — basically if lirc_i2c does not work it’s a pretty sure bet that this driver won’t either. The IR polling works in exactly the same way — all my stuff does is to add support for the IR blaster (plus some code to try to recover the chip if it stops responding, although I seem to have fixed this with a new i2c implementation anyway).

    I would seriously recommend upgrading both the kernel and the ivtv driver (0.3.4 is very old, and is really much more of a development snapshot than a stable release). I can try to help with this if you like. With debian (I think it is debian you are using?) it should be a simple matter of apt-get install kernel-image-2.6-arch to upgrade.

    Like I said, it’s not that I’m unhappy to try to make it work with 2.4.27 (although that is a bit of a pain :), it’s more that I honestly don’t think that it will solve your problem.

  127. 127
    Mike B Says:

    Chalk me up as another successful user. I’d advocate getting these patches merged into the main branches of ivtv and lirc. This is a fantastic hack! Thanks for your hard work.

  128. 128
    CyberCSK Says:

    Hi!
    As you suggested I updated my kernel to 2.6 and ivtv to the latest 0.4.0, but my problem still exists. Here I post the dmesg output with full debug.

    Do you have any other suggestion, that might help me?

    thx
    CyberCSK

    ivtv: ==================== START INIT IVTV ==================== ivtv: version 0.4.0 (tagged release) loading ivtv: Linux version: 2.6.12 preempt 586 gcc-3.3 ivtv: In case of problems please include the debug info ivtv: between the START INIT IVTV and END INIT IVTV lines when ivtv: mailing the ivtv-devel mailinglist. ivtv0: Autodetected WinTV PVR 150 card (iTVC16 based) ivtv0 info: base addr: 0xe4000000 ivtv0 info: Enabling pci device PCI: Found IRQ 3 for device 0000:00:0b.0 ivtv0 info: Attempting to enable Bus Mastering ivtv0 info: Bus Mastering Enabled. ivtv0 info: 22 (rev 1) at 00:0b.0, irq: 3, latency: 64, memory: 0xe4000000 ivtv0 info: attempting ioremap at 0xe4000000 len 0x00800000 ivtv0 info: attempting ioremap at 0xe5000000 len 0x00800000 ivtv0 info: attempting ioremap at 0xe6000000 len 0x00010000 ivtv0 info: activating i2c… ivtv0 i2c: i2c init ivtv0 i2c: setting scl and sda to 1 tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0 ivtv0 i2c: i2c client attach ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61] wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0) ivtv0 i2c: i2c client attach ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b] tveeprom: ivtv version tveeprom: Hauppauge: model = 26034, rev = C197, serial# = 7703309 tveeprom: tuner = TCL 2002MB_3H (idx = 97, type = 55) tveeprom: tuner fmt = PAL(B/G) PAL(D/K) (eeprom = 0x44, v4l2 = 0x00000e07) tveeprom: audio processor = CX25842 (type = 24) tveeprom: decoder processor = CX25842 (type = 1d) ivtv0 i2c: i2c client attach ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50] cx25840 0-0044: cx25842-23 found @ 0x88 (ivtv i2c driver #0) cx25840 0-0044: loaded /lib/modules/HcwMakoA.ROM firmware (14264 bytes) ivtv0 i2c: i2c client attach ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44] ivtv0 info: Active card count: 1. ivtv0 info: Loaded module tveeprom ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: using client 2, addr 0x50 ivtv0 info: PAL tuner detected ivtv0 info: Loaded module tuner ivtv0 info: Loaded module cx25840 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 info: Loaded module wm8775 ivtv0 info: Loaded module tda9887 ivtv0 info: Stopping VDM ivtv0 info: Stopping AO ivtv0 info: pinging (?) APU ivtv0 info: Stopping VPU ivtv0 info: Resetting Hw Blocks ivtv0 info: Stopping SPU ivtv0 info: Sleeping for 10ms ivtv0 info: init Encoder SDRAM pre-charge ivtv0 info: init Encoder SDRAM refresh to 1us ivtv0 info: init Decoder SDRAM pre-charge ivtv0 info: init Decoder SDRAM refresh to 1us ivtv0 info: Sleeping for 600ms (600 recommended) ivtv0 info: Card ready for firmware! ivtv0 info: Loading encoder image ivtv0: loading /lib/modules/ivtv-fw-enc.bin ivtv0 info: Sleeping for 100 ms ivtv0 info: Sleeping for 100 ms ivtv0 info: GPIO INIT ivtv0 info: About to search for mailboxes ivtv0 info: Searching for encoder mailbox ivtv0 info: match: 0x34567812 at 0xd5280104. match: 1 ivtv0 info: match: 0x56781234 at 0xd5280108. match: 2 ivtv0 info: match: 0x78123456 at 0xd528010c. match: 3 ivtv0 info: found encoder mailbox! ivtv0 info: Searching for decoder mailbox ivtv0 info: match: 0x34567812 at 0xd5c80104. match: 1 ivtv0 info: match: 0x56781234 at 0xd5c80108. match: 2 ivtv0 info: match: 0x78123456 at 0xd5c8010c. match: 3 ivtv0 info: found decoder mailbox! ivtv0 info: Getting firmware version.. ivtv0 info: Getting encoder firmware rev. ivtv0 api: API Call: 0x000000c4 (IVTV_API_ENC_GETVER) ivtv0 api: Releasing mailbox (before 0x00000007, after 0x00000000) ivtv0: Encoder revision: 0x02040011 ivtv0 info: v4l2 streams setup ivtv0 info: Configuring WinTV PVR 150 card with 4 streams ivtv0 info: Registered v4l2 device for encoder MPEG minor 0 ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total) ivtv0 info: Registered v4l2 device for encoder YUV minor 32 ivtv0: Allocate DMA encoder YUV stream: 161 x 12960 buffers (2048KB total) ivtv0 info: Registered v4l2 device for encoder VBI minor 224 ivtv0: Allocate DMA encoder VBI stream: 80 x 26208 buffers (2048KB total) ivtv0 info: Registered v4l2 device for encoder PCM audio minor 24 ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total) ivtv0 info: Starting Threads ivtv0 irq: Masking interrupts ivtv0 i2c: call_i2c_client ivtv0 i2c: using client 0, addr 0x61 tuner: type set to 55 (TCL 2002MB) by ivtv i2c driver #0 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 info: ivtv_enc_thread: pid = 5485, itv = 0xd35a0000 ivtv0 info: encoder thread sleeping 5485 ivtv0 info: ivtv_enc_vbi_thread: pid = 5486, itv = 0xd35a0000 ivtv0 info: encoder thread sleeping 5486 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: using client 1, addr 0x1b ivtv0 info: Setting audio to input 0 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 ioctl: VIDIOC_S_STD ivtv0 info: Switching standard to PAL. ivtv0 i2c: call_i2c_client ivtv0 i2c: using client 0, addr 0x61 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 ioctl: VIDIOC_S_FREQUENCY ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 api: API Call: 0x000000d2 (IVTV_API_PAUSE_ENCODER) ivtv0 api: Releasing mailbox (before 0x00000007, after 0x00000000) ivtv0 info: Disabling digitizer ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 info: v4l2 ioctl: set frequency 6400 ivtv0 i2c: call_i2c_client ivtv0 i2c: using client 0, addr 0x61 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: using client 1, addr 0x1b ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 api: API Call: 0x000000d3 (IVTV_API_REFRESH_INPUT) ivtv0 info: Enabling digitizer ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 api: API Call: 0x000000d2 (IVTV_API_PAUSE_ENCODER) ivtv0 api: Releasing mailbox (before 0x00000007, after 0x00000000) ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 info: Finished with Mute ivtv0: Initialized WinTV PVR 150, card #0 ivtv: ==================== END INIT IVTV ==================== 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

  129. 129
    Jim Says:

    I’ve been playing around with getting this working, unfortunatly i’m plagued with lirc_pvr150: firmware haup-ir-blaster.bin not available (-2)
    and i’ve placed the haup-ir-blaster.bin in every location i’ve found that had anything to do with firmware, and it just isn’t working. I’m using gentoo, i have hotplug installed, and the coldplug starting on bootup, i tried rmmoding lirc_pvr150 and remodprobing it, and it still has the same result. I can’t seem to find out where it’s looking for the firmware. Hotplug is set to load firmware from /lib/firmware, and it has a copy there. I’m stumped. I’ve read thru this and i haven’t seen any real answers on where this file _should_ be or how to find out whats causing this problem. Any suggestions would be great 😉

    thanks,
    jim

  130. 130
    Jim Says:

    Update: i managed to get it working (i think) it spits alot of stuff in the logs, but it isn’t complaining any more and the LED lights up but unfortunatly none of the codes worked for my philips tv.. is there anywhere else i can find whats needed to turn the tv on?

  131. 131
    olav Says:

    Hi,
    I have installed your driver and it seems to work well.
    I have one problem thougn. I can’t change channels on my STB, except for the first 9 (those with a single digit).
    I’ve tried repeating the irsend command at different intervals, but no luck so far.
    Sending 1_600_KEY_1 twice always results in setting the STB to channel 1, not 11 as I wanted it to.

    The STB is a Force satellite/terrestrial box.

    I’ve tried to analyze the signal from the Force remote using the mode2 command, and this e.g. display 1200 or 1A00 for the ‘0’ key.
    It seems that it is alternating a bit each time the button is pressed.
    Could it be that the driver doesn’t do this? I.e. that the driver always send the same code to the STB?
    I haven’t been able to verify this as the irsend fails when I am running the mode2 application. It says something about that it timed out.

    I guess the alternating bit is used to see if the button is pressed twice or just not released. If I hold down a button, the same code is just repeated.
    If I release and then press again, the bit is flipped.

    Three different codesets seems to “work”, 1_600, 0_308 and1_498. I.e. the power button works and setting channel 1 through 9.
    Haven’t tried other buttons so far.

    Any ideas?

  132. 132
    mark Says:

    Hi everybody, sorry for the delay. I’ve been working non-stop for the past few weeks, including weekends and I just haven’t found the time to do anything else besides eat, drink and sleep!

    Here we go with the out of order replies again:

    Mike — great! I have got the export symbol part merged into the 0.4.0 ivtv release (about to update the howto), so just lirc to go.

    CyberCSK — it looks as though you don’t have any IR hardware. As a quick one, you might want to try powering off the box completely (by removing the power cord from it), then pressing the power button (to drain the last bit of juice), waiting a few seconds, then plugging it in and starting it up again. From the ivtv-devel list, this seems to be the normal way to debug missing hardware. If it’s still not found after that then can you modprobe i2c-dev & then run i2cdetect on the ivtv bus and post the output? If it can’t talk to the hardware at all then, it’s either fried or not present.

    Jim: I guess hotplug wasn’t set up properly? This seems to come up a lot, I’d be grateful if you would post the steps that you took to resolve this problem so that people can see how to do this in future. Regarding your tv, is it an STB? I think pretty much all of the codes are for STBs. At any rate, if it doesn’t respond, either there isn’t a codeset for it, or it’s just not picking it up. The transmitter is quite short range, you might want to check how it is positioned (exactly on top of the receiver is good, a torch can help with those bits of tinted plastic that they like to put on top of everything).

    olav: I’m pretty sure it always sends the same code, as it’s just replaying the same block of data for each number. You might try hacking around the driver and fiddling with the data it sends to see if you can get it to flip the bit — although nobody has any clue as to the format of the data block at present (have a look at the XML file in the same directory as all the rest of the gubbins (here), that’s got the straight data blocks for each code/key combination as big hex strings. Unfortunately I can’t think of anything else to try — all I do is replay gubbins to the chip from a capture of what the Windows software does. There is definitely structure to it, somebody just needs to figure it out! Sorry I can’t be of more help.

  133. 133
    tk Says:

    Today is Tuesday October 25

    Mark
    I sent you an EMAIL this morning (before I found this at the bottom of the list) with a fair amount of debugging information on (at that time) my non-working) pvr150.
    I finally got ALL the pieces together from this forum and my pvr150 blinks like crazy with send_power_new. Don’t know if it will drive my Motorola DCT-2224 but my hopes are high. After many failures, the keys for me were…. using Fedora FC4

    1. I replaced all references to lirc_i2c with lirc_pvr150 in my /etc/modprobe.conf file.

    2. I copied haup-ir-blaster.bin to /lib/firmware. It is the only entry there.

    My dmesg output now looks like it is supposed to >>>

    I would be interested to hear from anyone who has had success driving a DCT-2224.

    Thanks for a bunch of help……. and remember

    “Never give up !!!” Elliot Ness to Al Capone in the Untouchables

  134. 134
    george Says:

    Hi, I have a mythbox amd64 pvr-150 running with lirc_pvr150 and the patched for the ivtv provided in this post. My remote still dies.. here are the messages in my log file:

    i2c_adapter i2c-0: sendbytes: error – bailout.
    lirc_pvr150: i2c_master_send failed with -14
    lirc_pvr150: polling the IR receiver chip failed, trying reset
    i2c_adapter i2c-0: sendbytes: error – bailout.
    lirc_pvr150: i2c_master_send failed with -14
    lirc_pvr150: polling the IR receiver chip failed, trying reset
    lirc_pvr150: i2c_master_send failed with -121
    lirc_pvr150: polling the IR receiver chip failed, trying reset
    i2c_adapter i2c-0: sendbytes: error – bailout.
    lirc_pvr150: i2c_master_send failed with -14
    lirc_pvr150: polling the IR receiver chip failed, trying reset

  135. 135
    Eric Says:

    I have the same problem as CyberCSK – my PVR150 card is working fine under IVTV for watching TV, but isn’t recognized at all by LIRC.

    Taking what Mark said above, I ran i2cdetect and got:
    Installed I2C busses:
    i2c-1 unknown ivtv i2c driver #0 Algorithm unavailable
    i2c-0 unknown SMBus I801 adapter at 0400 Algorithm unavailable

    Which leads me to believe that LIRC needs to talk to card1, not card0 – any idea what parameter I need to put in to get lirc_pvr150 to do that? Thanks!

  136. 136
    Ted in Atlanta Says:

    Today is Thursday October 27th

    Mark
    Wanted to let you know that I compiled your pre-patched module with
    Fedora FC4 kernel 2.6.13-1.1532_FC4 and after reading and applying the
    advice here, my PVR150 is blinking away merrily. It does turn off my DCT 2224 Motorola STB running your send_power_new… is there an easy way to determine which set controls my STB. I’m testing with an OTA antenna for the
    present. One strange thing is I don’t get ANY sound on WTBS channel 17
    here in Atlanta… all the others are fine. Not to worry… channel 17
    sound doesn’t work under Windows either. I’ll look into that anomoly
    later… once I figure out how to use MYTHTV. Thanks for your great
    module and reams of advice.

    Cheers

  137. 137
    mark Says:

    Latest batch of replies!

    tk/ted — looks like you are basically there. The way to find the codeset is to just kill the script when your box turns off and see where it got to. Adding -x to the first line might help (#/bin/bash -x) as it will print out what just executed. You can then try a few manual irsends around the point at which it did turn off. I realise it’s not terribly elegant, but I’ve not found the time to code up a more elegant script yet (i.e. one that lets you stop/go back/forward). If it turns the box off, it will probably work. Regarding your lack of sound, I suggest that you post to the ivtv-devel list as the other people there have much more knowledge about that kind of thing than I do. They are generally very helpful too.

    Eric: Can you run i2cdetect (i2cdetect 1) on the ivtv bus and post the output of that? The LIRC driver is capable of detecting which bus(es) belong to ivtv cards. It then scans those buses for the IR chip (TX or RX). (In this respect, my driver is no different from lirc-i2c from which it is derived). What I am interested in here is that the chip doesn’t seem to be present — which is weird. You might want to run ivtvctl –reset-ir after and trying it again to see if the outputs differ.

    HTH,

    Mark

  138. 138
    mark Says:

    George: sorry I missed you on the first pass!

    A few other people have had this issue (it seems that some do, some don’t — even though the software/hardware should be the same). Go figure. Anyway, I believe I have fixed it with this, which you might like to give a whirl. If you have any success with it, please let me know, I’m keen to get that patch tested more widely. Note that it has a little fuzz applying to ivtv-0.4 (there will be a few rejects in ivtv-driver.c), but they are nothing to worry about.

    Thanks,

    Mark

  139. 139
    Eric Says:

    Running ‘i2cdetect 1′ results in:
    Error: Could not open file `/dev/i2c-1′ or `/dev/i2c/1’: No such file or directory

    And indeed, there are no i2c entries in /dev

    Running ivtvctl -reset-ir gives me:
    ioctl VIDIOC_S_FREQUENCY ok
    Frequency set to 0

    Help?

  140. 140
    Eric Says:

    Oh, and the results of i2cdetect do not differ before or after the ivtvctl -reset-ir command.

  141. 141
    Eric Says:

    Followup:

    Creation of /dev/i2c-1 with:
    mknod /dev/i2c-1 c 89 1

    and then i2cdetect 1 results in:

    0 1 2 3 4 5 6 7 8 9 a b c d e f
    00: XX XX XX XX XX XX XX XX XX XX XX XX XX
    10: XX XX XX XX XX XX XX XX XX XX XX UU XX XX XX XX
    20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    40: XX XX XX XX UU XX XX XX XX XX XX XX XX XX XX XX
    50: UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    60: XX UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    70: XX XX XX XX XX XX XX XX

    Which I can’t decipher….

  142. 142
    mark Says:

    It means that it can’t find the IR chip at all, which is somewhat of a disaster for the driver! There should be a chip appearing at 0x70 (TX) and 0x71 (RX). Can you post the full dmesg output for the ivtv module load (the bit between IVTV START & IVTV END or whatever it says)?

    You might also try a proper cold boot (as described earlier on this page), and if possible, physically inspecting the card to see if it has a Z8F0811 chip on it (should be a small chip in the bottom left corner of the card). If you can do that, it would be worth reading the model number/revision off the card at the same time. It may be that something has changed in the card design (hauppauge do this frequently).

  143. 143
    Eric Says:

    Here’s my dmesg dump:

    ivtv: ==================== START INIT IVTV ====================
    ivtv: version 0.4.0 (tagged release) loading
    ivtv: Linux version: 2.6.13.2-chw-3 SMP preempt 586 gcc-3.3
    ivtv: In case of problems please include the debug info
    ivtv: between the START INIT IVTV and END INIT IVTV lines when
    ivtv: mailing the ivtv-devel mailinglist.
    ivtv0: Autodetected WinTV PVR 150 card (iTVC16 based)
    ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 21 (level, low) -> IRQ 21
    tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0
    ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61]
    tveeprom: ivtv version
    tveeprom: Hauppauge: model = 26032, rev = C199, serial# = 8209030
    tveeprom: tuner = TCL 2002N 5H (idx = 99, type = 50)
    tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x00001000)
    tveeprom: audio processor = CX25841 (type = 23)
    tveeprom: decoder processor = CX25841 (type = 1c)
    ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50]
    cx25840 1-0044: cx25841-23 found @ 0x88 (ivtv i2c driver #0)
    cx25840 1-0044: loaded /lib/modules/HcwMakoA.ROM firmware (14264 bytes)
    ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44]
    wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
    ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b]
    ivtv0: loading /lib/modules/ivtv-fw-enc.bin
    ivtv0: Encoder revision: 0x02040011
    ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    tuner: type set to 50 (TCL 2002N) by ivtv i2c driver #0
    ivtv0: Initialized WinTV PVR 150, card #0
    ivtv: ==================== END INIT IVTV ====================

    I’ll try the cold boot and the visual inspection and keep you posted.

  144. 144
    Tomer Says:

    Hi Mark,

    I tried your driver on Fedora Core 4 most of the way was very smooth (I use the ivtv 0.4)… there are two issues I bumbed into:
    1. When trying to start it /dev/lircd –device=/dev/lirc0
    I get Permission denied…
    2. When trying to send signal, I get:
    irsend: command failed: SEND_ONCE blaster 1_14_KEY_POWER
    irsend: hardware does not support sending
    checking the remote with the irw works perfectly.

    Any ideas ?

    Thanks,
    Tomer.

  145. 145
    Ted in Atlanta Says:

    Comment for Eric…

    My dmesg looked like yours until I added the following to /etc/modprobe.conf
    in my Fedora FC4 system.

    alias char-major-61 lirc_i2c # for lirc
    alias char-major-61 lirc_pvr150 # for lirc_pvr150

  146. 146
    Ted in Atlanta Says:

    OOPS

    Eric … my suggestion has a typo… The first line should start with a # sound thusly:
    or you can delete it completly

    # alias char-major-61 lirc_i2c # for lirc

  147. 147
    Paul Sutherby Says:

    Hi Mark – I have today installed Fedora Core 4 and Mythtv using the tutorial on Wilsonet.com.

    I have a PVR-150 for video capture, and the ir blaster and receiver.

    My PVR 150 is setup and I can view video, and Myth is setup so that I can view the current channel and any music or movies. The hauppage remote is working great with Myth

    What I have been unable to do is to get the blaster to control my stb so that Myth will change to the channel that I want it to.

    I tried to follow your patch and instructions, but got some errors at the first steps. As my remote works ok in Myth and it’s just the blaster that I am having problems with can you advise what I might be able to do to get this working?

    Thanks

    Paul

  148. 148
    mark Says:

    Have been at my parents for the weekend, sorry for the delay. Replies:

    Eric: any further progress? I hope things are going well for you.

    Tomer: I think Ted sounds on the mark here and that the issue is probably that you have lirc_i2c loaded. This conflicts with lirc_pvr150 as they try to control the same piece of hardware. The belt and braces fix would be to remove the package completely and make sure that lirc_i2c, lircd, etc are gone and rebuild them from source. The litmus test is of course lsmod |grep lirc_i2c which will tell you if the driver is loaded — if it is, you need to killall lircd && rmod lirc_i2c lirc_pvr150, disable/remove it, and then make sure that lirc_pvr150 gets loaded (modprobe lirc_pvr150, run lircd as per instructions above).

    Paul: Can you please post some more details — exactly which step are you having trouble with and what error messages do you get? You should also remove your existing lirc install before starting to prevent any conflicts with the lirc_i2c module.

    HTH,

    Mark

  149. 149
    Paul Sutherby Says:

    Mark – thanks for getting back to me… Not sure what else I can provide.

    I am falling down at the very first step… have gone to /usr/src and extracted the tar.bz2 file. When I run ./configure I get the following error:

    which: no dialog in (/usr/kerberos/sbin:/usr/kerberos.bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin)
    dialog not found!
    Please read the documentation!!!

    I assume that this is because the guide was written for a different linux build and not fedora core4? Is there anything that I can do to get this working? IR Blaster from the PVR-150 would get my setup 100% ok if I can just get it working…

    Thanks

    Paul

  150. 150
    mark Says:

    Just a missing dependency — you need to install the dialog package first, e.g. a random RedHat ES 3 box says:

    [root@clap root]# rpm -q –whatprovides dialog
    dialog-0.9b-20020814.6

  151. 151
    Paul Sutherby Says:

    Mark – thanks, tried that and got further – on ./configure I now get the install menu – selected the PVR card and hit save and run configuration, a load of dependencies were checked but it had a configure error – c++ preprocessor “/lib/cpp” fails sanity check.

    Any ideas?

  152. 152
    mark Says:

    Can you post or email me the output of confiig.log? I’d guess something like you haven’t got gcc installed, but I can’t really say without more information (gcc -v to test).

  153. 153
    Paul Sutherby Says:

    Thanks again Mark:

    I think I do have gcc installed – gvv -v gives:

    Using built-in specs.
    Target: i386-redhat-linux
    Configured with: ../configure –prefix=/usr –mandir=/usr/share/man –infodir=/usr/share/info –enable-shared –enable-threads=posix –enable-checking=release –with-system-zlib –enable-__cxa_atexit –disable-libunwind-exceptions –enable-libgcj-multifile –enable-languages=c,c++,objc,java,f95,ada –enable-java-awt=gtk –with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre –host=i386-redhat-linux
    Thread model: posix
    gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)

    Here is my config.log output:

    cpp: installation problem, cannot exec ‘cc1plus’: No such file or directory

  154. 154
    mark Says:

    Chopped the relevant bit out of config.log. You are missing some of the gcc toolchain. Try installing gcc-c++, or probably better is to use redhat-config-packages or whatever the FC4 general package selection tool is. If you can find the GUI package selection tool you should pick the development tools group that includes gcc, this should install all the needed dependencies.

  155. 155
    Paul Sutherby Says:

    Thanks Mark – that got it working – have completed the make and make install steps.

    Going to call it a day at that for today, but will see if I can get the rest to complete tomorrow night – will let you know how I get on!

    Thanks again

    Paul

  156. 156
    Paul Sutherby Says:

    hmm – couldnt resist a late look at it – and got another error…

    when running modprobe lirc_dev && modprobe lirc_pvr150 debug=1
    no error comes out in the shell, but syslog reads… any ideas?

    Oct 31 23:35:09 localhost nmbd[2446]:
    Oct 31 23:35:09 localhost nmbd[2446]: *****
    Oct 31 23:35:09 localhost kernel: Device not ready. Make sure there is a disc in the drive.
    Oct 31 23:35:40 localhost last message repeated 70 times

  157. 157
    mark Says:

    Try looking in /var/log/[dmesg, messages, etc]. I guess redhat isn’t putting klog output in syslog.

  158. 158
    Ted in Atlanta Says:

    Monday Oct 31
    Hi guys
    My Fedora FC4/Mark/PVR150 is working well… recorded a 1 hour show with no mishaps. My remote is working fine in MYTHTV and wondering if it is possible to get more than 1 action to happen per a single key press. For instance. I would like to display the EPG with 1 (one) key press. At the moment I press GUIDE which brings up the guide menu…. I would like this one button to also press the OK button (enter) to display the guide. I would use a different button to bring up the guife menu for further action.

    Cheers

  159. 159
    mark Says:

    For this case, simply map the appropriate button press in your .lircrc to S (probably set to I at present). For all of the possible mythtv key bindings, look in the keybindings table in the mythconverg database. You can also change the keylist column in this table to whatever key you want to map the remote button to.

    I don’t think it is possible to get multiple button presses, but there are quite a lot of actions and it is likely that they cover most of the cases you want.

  160. 160
    Paul Sutherby Says:

    Mark – it is working! Thanks ever so much for your help.

    If I run the following 3 lines, then I can receive my hauppage remote codes in irw, and if I run the send_power_new script then I can see the blaster happily flashing away

    modprobe lirc_dev
    modprobe lirc_pvr150 debug=1
    lircd –device=/dev/lirc0

    Over the coming weekend I will move my box back to my pc and have another bash at getting the correct codes in the lircd.conf to see if that gets it working – should be on the home straight now!

    Thanks Mark

    Paul

  161. 161
    Brian Says:

    Hi,

    I have everything installed and my IR blaster is blinking. However, my Expressvu receiver is not responding to any of the code. I have tried move the LED as close to the IR receiver in my set-top box as possible.

    I have attached the output from my kernel log and would appreciate any pointer you can give.

    Thanks,
    Brian

    Nov 1 21:20:52 vernon lirc_dev: IR Remote Control driver registered, at major 61
    Nov 1 21:20:53 vernon lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes
    Nov 1 21:20:53 vernon lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes
    Nov 1 21:20:53 vernon lirc_pvr150: chip found with RX and TX
    Nov 1 21:20:53 vernon ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    Nov 1 21:20:53 vernon ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    Nov 1 21:20:53 vernon lirc_dev: lirc_register_plugin: sample_rate: 0
    Nov 1 21:20:53 vernon lirc_dev: plugin lirc_pvr150 registered at minor number = 0
    Nov 1 21:20:53 vernon lirc_pvr150: poll thread started
    Nov 1 21:20:56 vernon lirc_pvr150: firmware of size 209327 loaded
    Nov 1 21:20:56 vernon lirc_pvr150: 575 codesets loaded
    Nov 1 21:20:56 vernon 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

    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): open called
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): ioctl called (0x80046900)
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): ioctl called (0x40046911)
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): ioctl called (0x40046912)
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): ioctl called (0x8004690f)
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll result = 0
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll result = 0
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): write called
    Nov 1 21:22:49 vernon lirc_pvr150: 01 60 a3 ee ablirc_pvr150: 05 4d 0d 67 a6lirc_pvr150: 09 72 0d 0f eelirc_pvr150: 0d 68 fa 47 falirc_pvr150: 11 36 0b dc 8elirc_pvr150: 15 75 f9 8e 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 1a 8c 2e 2flirc_pvr150: 2d 73 81 6e 39lirc_pvr150: 31 16 f5 17 75lirc_pvr150: 35 8b 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 64 b3lirc_pvr150: 61 00 00 00 b3lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 1)
    Nov 1 21:22:49 vernon lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 2)
    Nov 1 21:22:49 vernon lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 3)
    Nov 1 21:22:49 vernon lirc_pvr150: sent code 32811, key 10
    Nov 1 21:22:49 vernon lirc_pvr150: key (0x00/0x00)
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll result = 0
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): close called
    Nov 1 21:22:49 vernon lirc_pvr150: key (0x00/0x00)

  162. 162
    Paul Sutherby Says:

    Mark – 1 last problem – got this working, and the IR Blaster flashing away when running the send_power_new script, but the box does not seem to turn off.

    I also tried the command irrecord to create a lirc.conf file but after being asked to press enter and then hold a key on the remote control, it then said that no gap was found and nothing was recorded – it seems that lirc does not work with my stb remote control – any ideas what I might be doing wrong?

    thanks again

    Paul

  163. 163
    Paul Sutherby Says:

    Hmm – strange – irrecord works for a different remote control, but not the one for my stb – does this mean that I can not use lirc to control my stb??

  164. 164
    mark Says:

    If it doesn’t turn it off, there’s nothing I can do. The driver is limited to replaying the same data to the chip that the windows software provides. irrecord will not work. If possible, you might want to check if the hauppauge windows software is capable of turning the box off. If not, then it definitely won’t work. If it does, please tell me what settings turn the box off in Windows and I can update the captures.

  165. 165
    mark Says:

    Brian: the answer to your question is unfortunately the same as above! If it works in Windows, I’ve missed something, and it’s reasonably trivial to get the extra data. If not, then there’s not much that I can do about it unfortunately.

  166. 166
    Paul Sutherby Says:

    ok, thanks for letting me know Mark – will see if I can get this on a windows install and try it out.

    Is this specific to the hauppage blaster then – would a different lirc blaster (like the serial ones you can get) be able to work with a wider range of stbs?

    thanks again

    Paul

  167. 167
    Brian Says:

    Thanks for the replay Mark. After some further investigation it was working (the Expressvu 4100 is code 1_28), I just have the orientation of the IR Blaster wrong. It appears that the ir comes from the top (opposite the cable), but I though it was coming out the front. Thanks for your great work on this project.

    Brian

  168. 168
    Kris Says:

    Well I can’t even get the darn driver to compile… here’s where I start seeing problems when I do a make:
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c: In function `poll’:
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c:997: warning: ISO C90 forbids mixed declarations and code
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c: In function `ioctl’:
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1020: warning: ISO C90 forbids mixed declarations and code
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c: In function `ir_probe’:
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1366: error: `I2C_ALGO_BIT’ undeclared (first use in this function)
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1366: error: (Each undeclared identifier is reported only once
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1366: error: for each function it appears in.)
    make[5]: *** [/root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.o] Error 1
    make[4]: *** [_module_/root/lirc-0.7.2pvr150/drivers/lirc_pvr150] Error 2

    Previous to me finding this site on making the TX work for the card, I had to patch the plain ole lirc-0.7.2 source to get it to compile, however this patch doesn’t work with your already patched source. I believe that this has to do with me running a 2.6.14 kernel. I don’t know if I should post the patch I found or what. Any ideas?

  169. 169
    mark Says:

    Yes, it’s your kernel. Try this patch — apply to drivers/kcompat.h.

  170. 170
    bob Says:

    Went back to 0.3.8 as 0.4.0 was causing problems. Got this in /var/log/messages:

    Nov 3 23:23:59 tuse lirc_dev: IR Remote Control driver registered, at major 61
    Nov 3 23:23:59 tuse lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    Nov 3 23:23:59 tuse lirc_pvr150: ivtv i2c driver #0: no devices found
    and …..
    Nov 3 23:20:17 tuse lircd-0.7.2[7796]: lircd(hauppauge_pvr150) ready
    Nov 3 23:20:20 tuse lircd-0.7.2[7796]: accepted new client on /dev/lircd
    Nov 3 23:20:20 tuse lircd-0.7.2[7796]: could not open /dev/lirc0
    Nov 3 23:20:20 tuse lircd-0.7.2[7796]: default_init(): No such device
    Nov 3 23:20:20 tuse lircd-0.7.2[7796]: caught signal

    i2cdetect gave:
    i2c-1 unknown SMBus Via Pro adapter at 5000 Algorithm unavailable
    i2c-0 unknown ivtv i2c driver #0 Algorithm unavailable

    The i2c.patch did not apply cleanly to 0.4.0 as two hunks failed. Any others with the same problem? Running Linux 2.6.12-gentoo-r9.

    Have others got 0.4.0 to work?

  171. 171
    Kris Says:

    YEA! Thanks Mark, that patch fixed the make problem for the 2.6.14 kernel. 🙂

  172. 172
    Ryan Says:

    Hi Mark,

    I’ve run into a problem that I haven’t seen mentioned here yet.

    I am running Gentoo AMD64, and I modified the current ebuilds for ivtv-0.4.0 with your patches, and your pre-patched version of lirc-0.7.2. Going through all of these replies, I got almost all of the problems ironed out, but now I’ve hit a road block.

    The lirc_pvr150 module appears to load fine, and the firmware appears to be loaded properly. However, an error gets logged when I start lircd. I am using the lircd.conf file you provided at http://www.blushingpenguin.com/mark/lmilk/lircd.conf. It doesn’t seem to like some of the codes.

    Here is the part of my syslog that shows the lirc_pvr150 driver loading successfully:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: chip found with RX and TX
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    ivtv0: 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

    …and here is what appears in my syslog when I start lircd:

    lircd-0.7.2pvr150[5952]: caught signal
    lircd-0.7.2pvr150[7034]: error in configfile line 58:
    lircd-0.7.2pvr150[7034]: “2147483648”: must be a valid (lirc_t) number
    lircd-0.7.2pvr150[7034]: reading of config file failed
    lircd-0.7.2pvr150[7035]: lircd(hauppauge_pvr150) ready

    At this point, irw doesn’t show anything, and irsend LIST “” “” “” doesn’t list any remotes.

    If I use another lircd.conf file with the grayHauppauge remote in it, I don’t get any errors and I am able to see codes from the Hauppauge remote with irw. I still can’t send commands with irsend though.

    Any ideas?

  173. 173
    Tyler Bartel Says:

    Mark

    I thought i would bring this off the lirc list as it seems to be getting more and more specific to my troubles. I have updated my ivtv to 0.4.0 installed your patched lirc and continued with instructions and hit another stumbling block when I modprobe lirc_pvr_150 debug=1 the output of my dmesg is as follows:

    ivtv0: Initialized WinTV PVR 150, card #0
    ivtv: ==================== END INIT IVTV ====================
    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
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    lirc_pvr150: poll thread started
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_dev: plugin lirc_pvr150 registered at minor number = 0
    lirc_pvr150: firmware haup-ir-blaster.bin not available (-2)
    lirc_pvr150: poll thread ended
    lirc_dev: plugin lirc_pvr150 unregistered from minor number = 0
    lirc_dev (lirc_pvr150[0]): cleaning up

    seems to me the module cant find the haup-ir-blaster.bin firmware file which i downloaded and verified was in /lib/modules (I’m tunning FC4)

    something else of note is that I was unable to run lircd as it was not put to my /usr/local/bin directory during the install which I thought strange. as apps like irw and irrecord were there (though they may have been there from a previous lirc install) so I copied lircd manually from the source directory.

    Thanks again for your time

    TYler

  174. 174
    Tyler Bartel Says:

    I have found the answer within the comments here. turns out I had to copy the haup-ir-blaster.bin file to /lib/firmware that is now the only file in there so thats probably what threw me for a loop so that seems to be the answer for FC4.

    I added the following to /etc/rc.d/rc.local:

    /sbin/modprobe lirc_dev
    /sbin/modprobe lirc_pvr150
    /sbin/lircd –device=/dev/lirc0 –output=/dev/lircd
    /usr/local/bin/irexec

    (the output is bucause of a problem i had with irexec not liking the default device, it seems it’s default socket is /dev/lirc0 on my machine anyway)

    My output of dmesg is now as follows:

    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
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    lirc_pvr150: poll thread started
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_dev: plugin lirc_pvr150 registered at minor number = 0
    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

    I still have to get the sending tested but I wated to report my success before anyone has to start helping me troubleshoot

    Happy Lirc-ing (fingers crossed)

    Tyler

  175. 175
    Tyler Bartel Says:

    Mark

    Sorry to continue being such a bother but I now have the irblaster working, I can tell because when i run your send_power_new script I can see the light blinks. Unfortunately after several tries, it seems that my reciever must not be supported by the driver. It is a STB that was created specifically by ASE for the Cable Company I subscribe to and is not one that I have ever seen with any other company (I actually work for that cable company).

    I have gone as far as creating a lircd.conf file from the findings of irrecord (irw understands the output of the remote) but it will not cause the light to blink on the blaster. The output of the ASE remote for the numbers actually uses the same codes as the grey hauppauge remote does strangely enough.

    My question is if there is any way I can help get this codeset supported by the driver?

    Thanks

    Tyler

  176. 176
    mark Says:

    bob: Can you send me the output from the ivtv module when you load it? What problems was 0.4.0 causing? The stable release ought to be fine.

    Ryan: it’s a bug in lirc to do with 64-bit support. Try asking the lirc list for help. Somebody had a fix for this and I asked them for it so I could forward it to you, but so far they haven’t responded. It’s just something trivial to do with the lirc file parser.

    Tyler: You might like to find out what remote standard they are using (since you work there!). Also check that the transmitter really is correctly placed over the receiver (usually holding a torch up to the plastic allows you to find it, also note that if you have an LED on the STB that lights up when you press a button on the remote, that is _not_ the receiver and they are often in different locations). Other than that, try it in Windows and if it doesn’t work there you’d have to bug Hauppauge about it. I don’t have any way of generating extra codes unfortunately.

  177. 177
    Ryan Says:

    Hi Mark,

    Thanks for pointing me in the right direction. Not being much of a programmer, I just went into the code and removed the if-then block that validates lirc_t numbers. After recompiling, I don’t receive the error message any more, and my IR blaster blinks when I run the send_power_new script!

    I know, that’s hardly a fix, but it got me going. Hopefully I’ll be able to get that fix someone else came up with, or see the fix in a new version.

    I haven’t had a chance to check if those codes actually work with my satellite receiver, and don’t have time at the moment…but soon enough, I will. 🙂

    Thanks for your excellent work!

  178. 178
    Bob Says:

    I’ve recently upgraded my system to use udev and my blaster seems to have stopped working. Everything loads and looks like it is working, but I cannot see the ir blaster blinking anymore and isn’t sending a signal. I tried to reinstall the lircd package from your site, but it would not install. It had an error:

    Making install in drivers
    make[1]: Entering directory `/tmp/lirc-0.7.2pvr150/drivers’
    Making install in lirc_dev
    make[2]: Entering directory `/tmp/lirc-0.7.2pvr150/drivers/lirc_dev’
    make[3]: Entering directory `/tmp/lirc-0.7.2pvr150/drivers/lirc_dev’
    test -c /dev/lirc || (/tmp/lirc-0.7.2pvr150/install-sh -d /dev && /usr/bin/mknod /dev/lirc c 61 0)
    /usr/bin/mknod: `/dev/lirc’: File exists
    make[3]: *** [mkdev] Error 1
    make[3]: Leaving directory `/tmp/lirc-0.7.2pvr150/drivers/lirc_dev’
    make[2]: *** [install-am] Error 2
    make[2]: Leaving directory `/tmp/lirc-0.7.2pvr150/drivers/lirc_dev’
    make[1]: *** [install-recursive] Error 1
    make[1]: Leaving directory `/tmp/lirc-0.7.2pvr150/drivers’
    make: *** [install-recursive] Error 1

    I have manually copied the drivers over to the kernel directory and modprobed them. My dmesg after loading the modules:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: chip found with RX and TX
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    ivtv0: 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

    I have configured my lircd to use the device that my udev rules create (/dev/lircd/0) and I can recieve commands just fine from the remote. If you have any ideas, please let me know.

    Cheers,

    Bob

  179. 179
    mark Says:

    How are you running lircd? And how are you trying to send?

  180. 180
    bob Says:

    Mark,
    Thanks for your response. I seem to have solved my problem but a new issue has creeped up. I change tv provided and the cable unit that i have received is a Scientific Atlanta Explorer 2000. The send_power_new script does not seem capable of controlling this STB. Any suggestions?

  181. 181
    Bob Says:

    Mark,

    I hope you were responding to me. I’ve been running lircd from my startup script, and I’ve started it by hand. I’ve been using a change_channel script that I found for mythtv, but for all my testing I use “irsend SEND_ONCE blaster power” and have not seen any response.

    Cheers,

    The other Bob

  182. 182
    mark Says:

    Hmm, ok. I’m somewhat confused here.

    To Bob with the Scientific Atlanta Explorer 2000: Firstly make sure that the IR transmitter is very close to the receiver — it only has a range of a few cm. This is generally _not_ where the LED that lights up when you press the button on the remote is located. I usually find that a torch is helpful in locating the receiver under the coloured plastic covers that are common. If that doesn’t help, then try it under windows if possible. If it doesn’t work under windows then then there’s nothing I can do with it (see other questions and responses). If it works under windows but not with lirc_pvr150 then it should be simple to fix.

    To the second bob: try wiggling the cable and make sure it is seated properly, looks like the driver is loaded ok. If that doesn’t help load lirc_pvr150 with modprobe lirc_pvr150 debug=1 and send me the output after an irsend or two.

    Thanks,

    Mark

  183. 183
    Ryan Says:

    Hi Mark,

    I have success! Once I had that AMD64 file parsing bug out of the way, everything else fell into place.

    A important note about the IR blaster… It appears to only have one LED inside it, and it is a plain red one — not an IR one. That would explain why the range is so short. I believe IR receivers are capable of picking up wavelengths creeping up into the red spectrum.

    The flat backside of my blaster had a white layer on it. Peel it off, and beneath it is one side of clear 2-sided sticky tape. With this you stick it right onto the IR window of your STB. If anyone is wondering what those two IR blaster-shaped white scraps are that came in the same bag — those are spare sticky tapes. 🙂

    Cheers!

  184. 184
    bob (first bob) Says:

    Mark,

    Thanks for the reply. That was it exactly. I hadn’t realized how weak the IR Blaster was. Someone in another forum suggested a certain code for the SA 2000 and I literally taped the IR blaster to the window on the STB and it worked.

    Another thing I noticed is the remote for the PVR 150 is not that responsive, just wondering if others noticed this. I will try to lower the repeat in the .lircrc file. Any other suggestions?

    Thanks for all the good work.

  185. 185
    mark Says:

    Great! I’m glad that sorted you out. The remote isn’t very responsive, but this is the same situation as with the old lirc_i2c driver and is the same on . all the PVR-X50 cards I haven’t got around to addressing it yet but it is on my TODO list. I’ll let you know when I get somewhere with it.

  186. 186
    ktraglin Says:

    after compiling and loading the modules, this is all I got on Ubuntu 5.10

    Nov 14 11:20:48 mediaserv kernel: [4297203.757000] lirc_dev: IR Remote Control driver registered, at major 61
    Nov 14 11:20:48 mediaserv kernel: [4297203.767000] lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    Nov 14 11:20:48 mediaserv kernel: [4297203.821000] lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: no
    Nov 14 11:20:48 mediaserv kernel: [4297203.823000] lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: no
    Nov 14 11:20:48 mediaserv kernel: [4297203.823000] lirc_pvr150: ivtv i2c driver #0: no devices found

  187. 187
    mark Says:

    It can’t find the IR chip. First off I’d try:

    – Making sure that lirc_i2c isn’t present/doesn’t get loaded (this driver would cause a conflict)
    – Testing again from a cold boot. To do this, turn off the PC, remove the power cord, press the on button a few times with the power cord removed, wait 30s and then plug it back in again (it’s really necessary for a proper reset as the PVR-150 stays powered from the motherboard trickle power)

    If that doesn’t help, can you confirm that you have a PVR-150 with an IR blaster and that it has a Zilog Z8F0811 CPU on it if possible? To do the latter, you need to look at the card, the chip should be near the bottom left of the device.

    Also, can you send me the output of running i2cdetect? You need to modprobe i2c-dev, then run i2c-detect to find the ivtv bus. When you’ve found it run i2c-detect -a [bus number] and post or email me the output.

    Thanks,

    Mark

  188. 188
    Chris Wray Says:

    Hi Mark,

    Firstly, thanks for the excellent guide. Im almost there now…
    Ive got the driver installed and it seems to be running fine, I can transmit certain codes and receive from the hauppauge remote.
    Howeve, I have a echostar (bell expressvu 3100) set top box and I cant pick up or receive the signals for that remote.
    If I select TV on the remote and go into mode 2 it will pick up the signals fine but ‘Sat’ doesnt receive anythinig. The remote definitely works.

    I used this as the lircd.conf to test irsend and it works fine (just not with my box)

    begin remote
    name blaster
    bits 32
    flags RAW_CODES
    eps 0
    aeps 0
    plead 0
    gap 333333
    repeat_bit 0

    begin raw_codes
    name 0
    2149253120
    name 1
    2149253121
    name 2
    2149253122
    name 3
    2149253123
    name 4
    2149253124
    name 5
    2149253125
    name 6
    2149253126
    name 7
    2149253127
    name 8
    2149253128
    name 9
    2149253129
    name POWER
    2149253130
    name CH_UP
    2149253135
    name CH_DOWN
    2149253136
    name CH_PREVIOUS
    2149253139
    name GUIDE
    2149253147
    name AV
    2149253161
    name ENTER
    2149253163
    end raw_codes

    end remote

    However, the echostar codes look different,

    begin remote

    name 3100
    bits 16
    flags SPACE_ENC
    eps 30
    aeps 100

    header 400 6100
    one 400 1700
    zero 400 2800
    ptrail 400
    gap 6200
    min_repeat 4
    toggle_bit 0

    frequency 56000

    begin codes
    power 0x0000000000000800
    0 0x0000000000004400
    1 0x0000000000001000
    2 0x0000000000001400
    3 0x0000000000001800
    4 0x0000000000002000
    5 0x0000000000002400
    6 0x0000000000002800
    7 0x0000000000003000
    8 0x0000000000003400
    9 0x0000000000003800
    up 0x0000000000006800
    cancel 0x0000000000004800
    end codes

    end remote

    When I do ‘irsend SEND_ONCE 3100 1’ I get:
    irsend: command failed: SEND_ONCE 3100 1
    irsend: transmission failed

    and the system log says :
    Nov 29 10:54:32 mythtv kernel: lirc_pvr150: failed to get data for code 0, key 400 — check lircd.conf entries

    I am really stuck as to what is going on and am wondering if its a firmware issue. The hauppauge website mentions that the new drivers for the IR blaster support my set-top-box but how do I go about generating the firmware file from them.

    Any advice you can give me will be a great help.

    Also, I just recompiled my kernel with the HZ defined as 1024 to try to get mode2 or irrecord to pick up the echostar remote, how can I verify that this is now in effect

    Kindest Regards

    Chris Wray

  189. 189
    mark Says:

    You are misunderstanding how it works — the driver is only capable of sending the codes listed in the giant configuration file linked to above. Other lirc configuration files won’t work You have to run the send_power_new script having carefully positioned the blaster over the receiver on your STB and wait until it turns off — see step #10 above for more details. You might want to add a -x to /bin/bash at the top of the script so that you can see what it is doing (alternatively load the module with debug=1 and check the log output).

  190. 190
    Chris Wray Says:

    Thanks for the quick reply Mark. Ill try this tonight.
    Just for the sake of my sanity, does this mean that mode2 will never be able to pick up the signals from my satellite remote?

  191. 191
    mark Says:

    Correct — see the mode2 man page:

    “Of course this program won’t work with hardware that decodes the signals itself like e.g. TV cards or the Irman.”

  192. 192
    Frank Says:

    has anyone had any luck getting the pvr150 remote (with or without ir blaster) working in gentoo linux.

    nexus@localhost ~ $ uname -a
    Linux localhost 2.6.14-gentoo-r3 #2 SMP Tue Nov 29 00:04:31 CST 2005 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux

    i’ve tried using your patched lirc with the kcompat.h.patch but no sucess

    see dmesg out put below i’m getting the same output as

    ktraglin said,
    November 14, 2005 at 5:24 pm

    and i tried i2c-detect but it’s not present yes i did modprobe i2c-dev
    first

    any help would be great
    thanks

    localhost nexus # dmesg | grep ivtv ivtv: ==================== START INIT IVTV ====================
    ivtv: version 0.4.0 (tagged release) loading
    ivtv: Linux version: 2.6.14-gentoo-r3 SMP gcc-3.4
    ivtv: In case of problems please include the debug info
    ivtv: between the START INIT IVTV and END INIT IVTV lines when
    ivtv: mailing the ivtv-devel mailinglist.
    ivtv0: Autodetected WinTV PVR 150 card (iTVC16 based)
    ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
    tveeprom: ivtv version
    ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50]
    tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0
    ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61]
    cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0)
    ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44]
    wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0)
    ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b]
    ivtv0: loading /lib/modules/ivtv-fw-enc.bin
    ivtv0: Encoder revision: 0x02050032
    ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    tuner: type set to 50 (TCL 2002N) by ivtv i2c driver #0
    ivtv0: Initialized WinTV PVR 150, card #0
    ivtv: ==================== END INIT IVTV ====================
    lirc_pvr150: ivtv i2c driver #0: no devices found

  193. 193
    Chris Wray Says:

    Just a follow up Mark. I finally got my blaster working, thanks for the help.
    I do have a suggestion though, perhaps the send_power_new script could echo the current code to stout so its a bit easier to determine which code powers the box off.

  194. 194
    Jim Says:

    Mark,

    Thanks for the great work! After following your explicit instructions, the remote seemed to work fine. However, with the fix applied I started getting random video glitches during mythtv. This seemed related to the card and/or IR chip somehow as it would only clear after a cold boot (much like the original IR symptoms). Has anybody else encountered this?

    Thanks again,
    Jim

  195. 195
    Jim Says:

    Thanks for the great patches and help! After getting everything related to the remote to work w/o locking up, I seem to get random video glitches in mythtv with all the patches applied. I banged my head over the configs for a while and finally, after restoring unpatched driver code, could get normal video only after a cold boot of the machine (of course, resetting all the state info on the pvr card). Anybody else have this problem?

    -Jim

  196. 196
    Jim Says:

    Ugh, sorry, didn’t mean to duplicate remarks there. Please remove duplicates as you wish.

  197. 197
    mark Says:

    Frank — that’s a bit weird. You could try a proper cold reboot, that seems to help in some cases. Otherwise, you might want to try the i2c patch and see if that helps. I don’t really know what else to suggest: if the driver can’t find the chip on the card then there’s not much it can do. I guess the standard lirc_i2c doesn’t find it either?

    Chris: it’s a fair point, I’ll update the script when I get chance. I think I used the debug log output to see what it was doing, but it’s a one off process so I haven’t thought about it since!

    Jim: I’ve not seen this. If you don’t load lirc_pvr150 or lircd, does it still happen? It seems pretty odd as i2c is only used during setup and polling the device. I’d like to know it’s definitely related to polling the device (if it happens without the module loaded, then I would guess that something else is going on).

    p.s. sorry for the slow responses, work gets in the way sometimes!

    Thanks,

    Mark

  198. 198
    Fergal Daly Says:

    Hi Mark,

    I downloaded your patch but had some trouble applying it to the FC4 source rpm. The versions of automake/autoconf that you ran are much newer than the ones that are used for lirc and they caused lots of diffs in the autogenerated files. So I stripped all of the autogenerated files from the original patch, applied that and ran autoconf-2.13 and automake-1.5 and the result is ~90k instead of 2M. It still doesn’t compile for the latest FC4 kernel (as you point out above) and gcc is a bit picky about mixing code with variable declarations, this second patch handles that.

    For anyone running FC4 they can get a condensed version of what’s necessary here. I hope this helps any fellow FC4 sufferers!

    Any idea when this is going into the mainline version or lirc?

    Fergal

  199. 199
    Chad Davis Says:

    I too can not get it to find the remote…Here is my dmesg after:

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

    [17183023.452000] ivtv: ==================== START INIT IVTV ====================
    [17183023.452000] ivtv: version 0.5.1 (tagged release) loading
    [17183023.452000] ivtv: Linux version: 2.6.15-8-386 preempt 486 gcc-4.0
    [17183023.452000] ivtv: In case of problems please include the debug info between
    [17183023.452000] ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    [17183023.452000] ivtv: any module options, when mailing the ivtv-users mailinglist.
    [17183023.452000] ivtv0: Autodetected WinTV PVR 150 card (cx23416 based)
    [17183023.452000] ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 209
    [17183023.452000] ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50]
    [17183023.460000] tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    [17183023.460000] ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61]
    [17183023.484000] cx25840 1-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0)
    [17183024.760000] cx25840 1-0044: loaded v4l-cx25840.fw firmware (14264 bytes)
    [17183024.844000] ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44]
    [17183024.844000] wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
    [17183024.856000] ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b]
    [17183024.928000] tveeprom 1-0050: Hauppauge model 26582, rev C299, serial# 8442800
    [17183024.928000] tveeprom 1-0050: tuner model is TCL 2002N 5H (idx 99, type 50)
    [17183024.928000] tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
    [17183024.928000] tveeprom 1-0050: audio processor is CX25843 (idx 37)
    [17183024.932000] tveeprom 1-0050: decoder processor is CX25843 (idx 30)
    [17183024.932000] tveeprom 1-0050: has no radio, has no IR remote
    [17183025.604000] ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
    [17183025.812000] ivtv0: Encoder revision: 0x02040011
    [17183025.812000] ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    [17183025.812000] ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    [17183025.812000] ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    [17183025.812000] ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    [17183025.812000] tuner 1-0061: type set to 50 (TCL 2002N)
    [17183026.044000] ivtv0: Initialized WinTV PVR 150, card #0
    [17183026.044000] ivtv: ==================== END INIT IVTV ====================
    [17183026.076000] lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: no
    [17183026.080000] lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: no
    [17183026.080000] lirc_pvr150: ivtv i2c driver #0: no devices found

  200. 200
    mark Says:

    Sorry once again for the late replies — yet more work!

    fergal: it’s basically a case of me getting in gear and doing it. Unfortunately I’ve not found the time at the moment. I don’t know what changes the lirc guys will need from me. If you’ve got the free time then I’m happy for someone else to submit it for me!

    chad: If it can’t find the chip, there’s not really much I can do. (lirc_i2c won’t work either). Any chance that I can have a prod via SSH? It would be nice to have a play and find out what’s going on.

  201. 201
    mark Says:

    chad: Just found something out — it looks like this might well be fixed by the new i2c implementation (the patch that sorts out remote issues). Can you please test again against the 0.4.2 ivtv release You will find instructions for getting this here. Do report back if it helps because it is probably going to help everybody else who’s been having the same issue.

    Thanks,

    Mark

  202. 202
    Fergal Daly Says:

    Since I’m on xmas hols right now I can give it a shot. I’ll have a look at lirc’s setup tomorrow (hopefully) and see if your patch applies to their head version.

  203. 203
    Dave Zysk Says:

    OK I’m trying to get this to work on my setup and I’m having some trouble with the IR blaster. I can get irw to work just fine with the remote but when I try the irsend commands to find out which power send effects my device that’s where things go wrong.

    Here’s all the relevant information I can think of.

    syslog after modprobing lirc_dev and lirc_pvr150:
    Jan 4 21:12:40 localhost kernel: lirc_dev: no version magic, tainting kernel.
    Jan 4 21:12:40 localhost kernel: lirc_dev: IR Remote Control driver registered, at major 61 Jan 4 21:12:53 localhost kernel: lirc_pvr150: no version magic, tainting kernel. Jan 4 21:12:53 localhost kernel: lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes Jan 4 21:12:53 localhost kernel: lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes Jan 4 21:12:53 localhost kernel: lirc_pvr150: chip found with RX and TX Jan 4 21:12:53 localhost kernel: ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71] Jan 4 21:12:53 localhost kernel: lirc_pvr150: poll thread started Jan 4 21:12:53 localhost kernel: ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70] Jan 4 21:12:53 localhost kernel: lirc_dev: lirc_register_plugin: sample_rate: 0Jan 4 21:12:53 localhost kernel: lirc_dev: plugin lirc_pvr150 registered at minor number = 0 Jan 4 21:12:53 localhost kernel: lirc_pvr150: firmware of size 229018 loaded Jan 4 21:12:53 localhost kernel: lirc_pvr150: 608 codesets loaded
    Jan 4 21:12:53 localhost kernel: lirc_pvr150: 01 60 00 01 81lirc_pvr150: 05 02 04 5b 0flirc_pvr150: 09 91 2f 45 0flirc_pvr150: 0d 34 f5 79 fblirc_pvr150: 11 53 b4 66 02lirc_pvr150: 15 2e d9 17 7clirc_pvr150: 19 20 cc 63 26lirc_pvr150: 1d 33 6b 26 12lirc_pvr150: 21 61 6b 0a 66lirc_pvr150: 25 7e 95 1e 17lirc_pvr150: 29 25 12 0a 8dlirc_pvr150: 2d 28 06 00 50lirc_pvr150: 31 4f 02 55 2clirc_pvr150: 35 4b 1c 6d 72lirc_pvr150: 39 6b ad 2f 3dlirc_pvr150: 3d 22 fb 55 e4lirc_pvr150: 41 7c 6a 54 06lirc_pvr150: 45 71 dd 59 c7lirc_pvr150: 49 2a 6c 7f 40lirc_pvr150: 4d 2e a9 52 c6lirc_pvr150: 51 c4 c7 b7 31lirc_pvr150: 55 56 dc 5e cdlirc_pvr150: 59 0c 56 53 fblirc_pvr150: 5d 97 b9 62 6blirc_pvr150: 61 00 00 00 6blirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
    Jan 4 21:12:54 localhost kernel: lirc_pvr150: poll thread ended

    Now to get these to work I have to run ‘modprobe -f’ otherwise I get the following:
    # modprobe lirc_dev
    FATAL: Error inserting lirc_dev (/lib/modules/2.6.8.1-12mdk/misc/lirc_dev.ko): Invalid module format
    # modprobe lirc_pvr150
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.8.1-12mdk/misc/lirc_pvr150.ko): Invalid module format

    I’ve heard this might be because I’m not using gcc 4.0 or higher. Is that a requirment?

    I’m running:
    Mandrake 10.1 2.6.8.1-12mdk
    gcc 3.4.1
    ivtv 0.4.0

    Anyway when I try the irsend commands here’s what I get:
    $ irsend SEND_ONCE blaster 0_0_KEY_POWER
    $ irsend SEND_ONCE blaster 1_0_KEY_POWER
    irsend: could not connect to socket
    irsend: Connection refused

    The first command will cause the led to blink in the blaster. However, I can never get a second command to run.

    Any help would be appreciated. Thanks.

  204. 204
    Dave Zysk Says:

    Figured it out. Somehow when I upgraded to xorg 7.0 it uninstalled my kernel source and then urpmi kernel installed the wrong kernel level. Once I got the right source on here it worked fine.

    Thanks for all your hard work on this project!!

  205. 205
    Brett Says:

    Looks great, and I’m thrilled to find this … but does it work with lirc-0.8*, which seems to be the current lirc module?

  206. 206
    Mark Maz Says:

    Mark,

    Is support for the pvr 150 going to part of the 8.0 lirc release or will you release a patch for it when the time comes? Thanks,

    Mark Maz

  207. 207
    Mark’s Braindump » LIRC PVR-150 IR blaster support, version 3 Says:

    […] Here’s the HOWTO straight away. There is a quick changelog from the previous version at the end. […]

  208. 208
    mark Says:

    Hi, Dave Zysk. It sounds like lircd is crashing after the first command — I guess this could be a segfault from the module blowing up in the kernel. You certainly shouldn’t have to modprobe -f it to get it to load, and indeed, this is quite likely to lead to bad results.

    You definitely don’t need to use gcc-4.0 to get this to work (I don’t, I’m using gcc-3.3.5), but you should use the same compiler that you used to compile the kernel, and compile it against the same set of sources. I’m not quite clear on what you are doing: I would guess the best bet would be to post some more details on how you are compiling the driver.

    To everybody who wanted lirc 0.8 support, I have now forwarded ported the driver to the current CVS snapshot (lirc-0.8.0pre4). I will be submitting it to lirc shortly as ivtv-0.4.2 (the current stable release) now has the i2c fixes and all of the required support for my driver. You can get the details of this from here.

    Thanks,

    Mark

  209. 209
    Kevin Gray Says:

    Thanks for this invaluable resource, Mark! I was running FC4-kernel-2.6.11, but I recently upgraded to kernel 2.6.14 since that is what the ivtv drivers seem to support.

    Anyways, following your instructions, my PVR-150 is now successfully blasting IR signals to my STB ok; however, I cannot get the remote to work for the life of me. When I run ‘irw’, I don’t see any sort of output on the screen. I’ve done a lot of research, but haven’t found a solution yet. I know this is kind of a vague description of the error, but I was wondering if you might have a good starting point… BTW, I checked the batteries in the remote 😉

    Thanks,
    kg

  210. 210
    mark Says:

    Kevin: sounds like an old bug. Please check with the v3 driver and let me know if it still happens.

  211. 211
    Kevin Gray Says:

    Sorry to consume your time with that question, I just realized that I had not inserted the mini-plug for IR RX/TX firmly into the jack :). It is very new, and the jack was very tight. Everything is now working fine with respect to the IR Blaster and Remote.

    The only issue that remains is that my linux system no longer has sound. I was running 2.6.11-1.1369_FC4, but to install the ivtv drivers I need to upgrade my kernel to 2.6.14-1.1656_FC4. After upgrading the kernel, I ran ‘yum upgrade’ to make sure all my packages were up-to-date. Now, I can no longer get sound to work on my system. The soundcard is detected correctly by alsaconf correctly; however, I don’t get any sound output.

    It doesn’t work when logged in as ‘root’ or as a regular user. The only thing I notice every now and then are permission issues when using a regular user to play a video from Myth:

    “alsa-init: playback open error: Permission denied”

    however, this does not occur all the time.

    I am using a simple A-Open soundcard (C-Media PCI CMI8738)

    If anyone has encountered this, any help would be great. By the way, for this issue the plug IS inserted fully into the jack 😉

    Thanks,
    kg

  212. 212
    Scott Petler Says:

    Not much activity on this thread lately. I recently purchased a
    150 and mine came with a usb sensor and blaster attached to
    that. So it doesn’t appear that the i2c driver will be of much use
    with this. I’m looking for another solution, possibly a
    blaster/sensor combo that will plug into the serial port. Any ideas??

    Thanks,
    Scott

  213. 213
    mark Says:

    Scott,

    It has moved on a version — see the home page. Regardless, the driver you are looking for is probably lirc_mceusb (part of the standard lirc distribution).

    Mark

  214. 214
    Scott Petler Says:

    Mark,

    How would I select that driver? Would this be selected within the
    lirc configuration utility?

    Thanks,
    Scott

  215. 215
    Erik Says:

    Mark,
    I have been reading your site regarding using a Scientific Atlanta 4200 box with the IR Blaster and downloaded the files. I am not sure how to go about installing the files and having the ir blast the required codes. if you can help me with this i would greatly appreciate it!

    Thanks,
    Erik

  216. 216
    Douglas Pearless Says:

    Hi,

    I have been looking how to add IR Blaster support to my PVR150 usign KnpooMyth (R5C7 from memory).

    I have the receive working but the transmit does not, (the IR Blaster is connected via the plug in jack on the card and not USB) and I have assumed from the mythtv.org mailing lists that the support for this has not made it into lirc and the thread pointed to this page.

    I assume I still need to apply the patches listed above, or is support going to be / is now in lirc?

  217. 217
    sybell Says:

    The following information is intended to supplement

  218. 218
    nathaniel Says:

    Thenks, good works

  219. 219
    vlad Says:

    my wintv 2000 keeps giving me error that it cannot locate the capture filter

  220. 220
    Steve Says:

    I’ve spent a lot of time, with much hair pulling trying to get my PVR-150MCE IR blaster working. Now I discover after reading the replies that there’s an issue with this card. I really hate to ask this but has this this issue ever been fixed or are those of us with MCE cards basically SOL?

  221. 221
    mark Says:

    You are using the wrong driver, use plain lirc for an MCE card.

  222. 222
    Joe Says:

    I got the driver installed, the remote works, but the ir blaster fails when sending commands to the cable box, but works when sending to satellite box’s.

    Heres the error message:
    irsend: command failed: SEND_ONCE blaster 0_80_KEY_5
    irsend: transmission failed

    My cable box is the Motorola 2224. If I send the 1_80_KEY_5 command, the LED on the blaster blinks (which is what I am assuming means its working), yet when sending to 0_80_KEY_5 it fails with the above message.

    Anyone have tips for me to solve this? I’ve spent hours searching online and this page is the best source for information yet I still cant get over that final hump to get it working!

  223. 223
    mark Says:

    Joe: this page is obsolete, like it says at the top.

    But anyway, 0_80 and 1_80 are two different codesets, presumably the 0_80 codeset simply does not exist. If your box responds on 1_80, then why not just use that?

  224. 224
    Joe Says:

    Yea, sorry it wasn’t clear, but the 1_80 codeset, while triggering the LED on the blaster, does not get the STB to respond. The 0_80 codeset does exist in the lircd.conf (same one linked to in this article).

    In more testing, I notice that none of the 0_## codesets work and all give the above error. Only the 1_## codesets run and trigger the LED to flash. It seems other people have PVR-150 MCE’s and Motorola 2224 working together so I assumed I missed something along the way.

    I know you mentioned this guide is obsolete, but really its the best documentation on this situation on the net. I can’t even find a remotely useful article elsewhere so this was my only hope 🙂

  225. 225
    mark Says:

    When I say obsolete, I merely mean that the post is out of date — there is a separate post covering “v3” (and all subsequent updates of the driver), which is linked at the very top, so you may be looking at old code and are certainly looking at old instructions!

    The MCE IR blaster is a completely different device from the one included with the non-MCE edition PVR-150, and the voodoo required to get them to work is totally different unfortunately :/

    I am pretty sure that the 0_ codesets work, could you check that you haven’t picked up an old version of the code? I had to go back and rejig things because originally I hadn’t picked them up, so possibly you are just running into that.

    HTH

  226. 226
    Fredi Says:

    Awesome items!! Give us the full lowdown along with loads of pictures when you get back.

Leave a Reply