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!
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?
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).
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
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.
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
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
Try looking in /var/log/[dmesg, messages, etc]. I guess redhat isn’t putting klog output in syslog.
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
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.
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
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)
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
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??
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.
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.
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
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
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?
Yes, it’s your kernel. Try this patch — apply to drivers/kcompat.h.
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?
YEA! Thanks Mark, that patch fixed the make problem for the 2.6.14 kernel. 🙂
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?
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
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
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
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.
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!
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
How are you running lircd? And how are you trying to send?
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?
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
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
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!
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.
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.
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
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
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
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).
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?
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.”
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
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.
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
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
Ugh, sorry, didn’t mean to duplicate remarks there. Please remove duplicates as you wish.
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
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
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
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.