Mark’s Braindump

Goodbye, Microsoft…

Filed under: Random — mark @ 7:37 pm

(…well, sort of, I still have to write code that runs on Windows as a day job — I’m looking to correct that in the medium term though!)

I finally got around to installing linux on my laptop. I’m a debian person generally (for various reasons, but I don’t want to provide any more distribution war fodder), but debian are a bit slow to change. I want to mess around with shiny new applications, so I plumped for ubuntu feisty. I’m right at home with it having used debian on servers for years. And I love it. Been going for about a month, and haven’t looked back (apart from the vmware image of Windows needed for work). I am amazed how far linux has come on the desktop. I’ve had not particularly technical people use my laptop, and _not even notice_ that it wasn’t running an OS that they know. Next task is to get stuck into fixing bugs, I’ve run into a few but then that’s why I picked an unstable release
Oh, and if you want to know, the combination of circumstances that got me to get off my arse and help with ubuntu bug #1 were:

- New hard disk for the laptop (=> spare to put OS on to play with
- The arrival of Windows Vista with all of its great new features

Hurrah for me, I did something good for a change!

Comments Off

ARC-1160 SATA RAID updated

Filed under: Random — mark @ 7:25 pm

Figured I might as well use this piece of software since I have to maintain it.

Basically to summarise my experiences with SATA RAID controllers (see here for the full details) under a basic stress load:

1. Adaptec 21610SA. Junk, very slow, locks up after about 4 hours.
2. 3ware 9550. Kicks drives out after about 10 minutes.

Then I got an Areca 1160. This works, kind of. It corrupts data, this is directly correlated with a ‘media error count’ that is visible only on the individual, detailed status page for each drive available through the card’s HTTP interface. After getting in touch with Areca they advised me that this was either power (I tried it with a pair of PSUs with the load split roughly evenly, so I don’t think that this is really the case), or it’s an issue with the firmware of the drives (16xWD320RE SATA disks).

However, entirely turning off the write cache makes the thing work OK, and it has done this for about a year. The write speed is absolutely pitiful though (and writes also kill reads). I get ~15Mb/s in moderately seek bound workloads, and ~30Mb/s for sequential writes. Hurrah, slower than some of my really old single IDE disks! Oh well, it’s good enough for a backup/TV server at any rate. Overall SATA RAID is still totally pants though!

Comments (0)

SATA RAID is rubbish

Filed under: Random — mark @ 1:00 am

For the last 4 months, I’ve had a 4TB storage array (=16×320Gb WD RE SATA hard disks) sitting in my front room.

Doing nothing. Nothing at all.

The reason? SATA RAID cards are _unfeasibly_ bad. Here’s what I’ve tried so far, under linux (various kernel versions and distributions):

- an Adaptec 21610SA. This lasts about 4 hours before it does the classic aacraid: scsi hang? (google for it, lots of references). Adaptec sent me a “heat sync” (sic.) for some reason, in a russian doll style series of packaging.
- a 3ware 9550. This lasts about 10 minutes before it powers down a random drive (physically: you can hear it), then claims that the drive has been reset (well, duh). 3ware deny everything (the last thing they told me was that it was “noise on the PCI bus”. The 3ware card has been tried in a couple of different motherboards, same thing in both of them).

Is this isolated? From friends I know of:

- At least two other machines containing Adaptec AAC series cards with the scsi hang? issue;
- At least two other machines containing 3ware 9xxx cards that pop drives;
- At least one other machine containing a 3ware 9xxx card that pops drives under a different OS

Good news? I got to play with an Areca-1160. Managed 24 hours without an issue, so that’s the best so far. If I can find someone who distributes them in the UK, I’ll get one!

Random technical details:

- I break the cards with dd if=/dev/sdX of=/dev/null (x10); dd if=/dev/zero of=fooX (x10); bonnie++ (x10); and cp -a on a kernel tree (x10). IoW, just a bit of IO.
- The cards were tried in a P8SCi motherboard, 3Ghz xeon, plenty of power supply (including 1100W worth for some experiments)
- The P8SCi is on 3ware’s compatibility list
- 3ware card also tried in an Athlon64+H8SSL motherboard setup with a 760W power supply

I can’t believe these companies get away with peddling such crap. But then I suppose so do Highpoint and Promise to name a few I’ve seen shite (ATA-100/ATA-66) hardware off in the past.

Is SCSI any better?!

Comments (8)

ClamAV Windows Port updated to 0.88.1

Filed under: Random — mark @ 12:47 am

Updated to latest version (0.88.1). I’ve updated in the interm; will try to post other updates in a timely fashion. Do let me know if you are using this, that will be an incentive to do so.

Other fixes are:

- Updated to build with VC8 (VS2005)
- Fix a number of extraneous close() calls that VC8 doesn’t like
- Fix service stub so that it works with w2k3

You can get the MSI installer & patch here.

Full source code can be downloaded here.

Comments (1)

LIRC PVR-150 IR blaster support, version 3

Filed under: Random — mark @ 10:11 pm

News

Latest: added a version that compiles with 2.6.27 kernels.
Latest: if you are packaging this, see the note at the bottom as to why I don’t provide a simple patch.
Latest: added an updated version that compiles with 2.6.24 kernels, tested against 2.6.23.12
Latest: updated `firmware` to a later revision from hauppauge (743 codesets)

HOWTO

This is not for the MCE version of the PVR-150. This includes a USB unit which does not work the same way as the normal PVR-150, use standard lirc (and lirc_mceusb) for that.
Use a recent kernel (note: the ivtv drivers have been part of the mainline kernel for a good number of revisions so no external drivers are required — sorry, I don’t know off hand which revision they were merged in), or for older kernels install ivtv-0.4.2+ (from this page). Earlier versions of ivtv _are not supported_.
Get the pre-patched lirc 0.8.5-CVS-pvr150 tarball. There are also earlier versions that can be found here, should you want them. The previous revision may be required for kernels < 2.6.27 (as it is untested on lower revisions -- in theory it should work)
You need the dialog package installed to use the lirc configuration GUI, so install that (apt-get install dialog, yum install dialog, whatever is appropriate for your distribution).
Unpack the patched lirc:
cd /usr/src tar xfj lirc-0.8.3-CVS-pvr150-2.tar.bz2 cd lirc-0.8.3-CVS-pvr150-2 ./setup.sh

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

then:

make && make install.
IR blaster only: Now you need the ‘firmware’. This is a set of data blocks that correspond to those generated by the windows software. This goes in /usr/lib/hotplug/firmware on my debian system. Depending on your system this might also be /usr/local/lib/firmware, /lib/firmware or /lib/modules.
Note that the entire firmware is kept in memory (currently 300K) so this makes the driver quite large. (I have no plans to sort this out, memory is cheap).
Check everything is working so far:
modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1

Check the syslog output. This should report something like:

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

This means that the driver has detected and initialised the IR blaster hardware — if you don’t see that then let me know.
You need to configure lircd, and find out which codeset you are going to be using. The easiest way is to start with this configuration file which contains key definitions for everything in the database. Do not use other lirc configuration files for specific STBs — these simply will not work. The IR chip is only capable of sending those codes which are in the database.
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
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.
Next, for the ir blaster you need to work out which codeset to use, this is the tricky bit. For this I have send_power_new, a script that just sends the power command in every single codeset. You may find your codeset number listed here if you are lucky.
Firstly, check that you are seeing the IR blaster blink. If you don’t have blinking lights at this stage, your cable probably isn’t in the card properly (try wiggling it around), or it may be broken.

Next you need to stick the IR blaster on the IR receiver of box that you intend to control, being quite careful to position it correctly — it has a very short range (a few cm) and took me a couple of goes to get right. The best way to do this is to find the IR demodulator on the box — easiest with a torch. Note that this is _not_ the light that comes on when you press a button on the remote, they tend to look like this.

If you can’t get this to work, please try and check it against the Windows driver if possible. If your device will work with the windows driver but not my driver, then it’s a driver bug that I should be able to fix. If it does not work with the Windows driver either then your only options are to use a different IR blaster or bug hauppauge until they add support for the box you are trying to control. At that point, I can update my
database too.
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).
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.
If you’re happy, you can always send me beer money. If not, add comments at the bottom

That’s it, good luck!

Packaging

The lirc distribution tarball is generated using `make dist-bzip2` which uses the gnu autotools to generate a configure script, and Makefile.in, etc. The contents of these generated files depends very much on the version of autotools that is installed; this varies from distribution to distribution. I don’t have the same auto* as the lirc maintainers, so producing a patch file against a distribution tarball makes a patch bigger than the original source archive. Hence I don’t bother; I just make a new dist bzip2 and drop it here.

I maintain the code by importing a current lirc CVS into a subversion repository hosted on this server. I tag each lirc import, generate a diff from the previous lirc import and apply it to my source tree, then port any fixes from lirc_i2c.c to lirc_pvr150.c, test, and generate a new .tar.bz2. To get the source tree you can do:

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

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

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

Comments (360)

PVR-150 IR stops responding (fixed!)

Filed under: Random — mark @ 7:42 am

Update
This patch, with some fixes, has gone into the 0.4.2 release of ivtv. Please use ivtv 0.4.2+ rather than following the instructions here. You can get this from the ivtv site.

History
This is related to my IR blaster driver, in case that’s what you are looking for. Do read on though, it might be informative! If you are just looking for patch instructions, dive right to the end to skip all this detail.

A while ago I looked around to see if the hauppauge windows driver for the remote control had any issues. I found quite a few people who claimed that it stopped responding, and that they had to reset the hauppauge software, etc and one or two pointers to a new (beta) driver on the hauppauge site. This was fairly intriguing as among the release notes it lists “i2c (IR blaster) fixes”. I managed to find time this weekend to take the driver apart, and see exactly what they did. Basically they rewrote the i2c support.

Some background, in case you aren’t familar: i2c is a low speed (varies, say ~100-400KHz) 2 wire serial bus for interconnecting various random chips. Because it’s so useful, it actually gets used all over the place to ‘glue’ various chips together on a board and then let the OS driver control them. For example, on your typical PVR-150 card you’ll find at least tuner, video encoder, IR chip and eeprom (configuration data). These are all i2c connected, and the driver talks i2c to them to program them (as well as other memory mapped registers, but let’s stick to the issue).

In some cases, the i2c protocol is implemented by special hardware on one of the chips (e.g. the bt878a chip has an i2c controller in it). This is the nice case, since the CPU doesn’t have to do much in the way of work. In the cheap case, you get to control the clock & data lines yourself from the OS (a kind of winmodem approach!). The hauppauge stuff takes the latter approach — indeed so does a bunch of other hardware. It’s so common that there is a module in the linux i2c subsystem specifically for doing this — it’s called i2c-algo-bit, and the approach is known as ‘bit-banging’. As a side issue, bit-banging takes up some constant fraction of CPU, because it has to use busy delays (it’s not possible to get microsecond accurate sleeps in the kernel, so we must run the CPU in a loop). Since these loops are constant _time_ you’ll find that whatever the CPU the IR polling (for example) takes a constant amount of time. For lirc_i2c, this works out at about 1%, and for my lirc_pvr150 module (that sends a ‘poll’ command to the receiver as well to see if it is borked or not), it’s about 2%. This is why I think the hardware approach is better, but whatever, we are stuck with it.

From the looks of the hauppauge driver changes it appears that the classical bit banging algorithm causes problems with the IR chip that the PVR-150 uses. I disassembled both the new and old drivers, and the older driver uses something very similar to the approach of i2c-algo-bit — it uses KeStallExecutionProcessor, or a busy loop, to implement delays. The newer driver dispenses with this, and instead polls the lines to see when they have become high/low and uses memory mapped register reads for stalling. I’m guessing that those reads are (roughly) constant time because they have to go across the PCI bus. I implemented the newer method, and low and behold this seems to solve my problems. I’ve not seen an IR chip reset by my lirc_pvr150 driver in 16 hours now (update: now 28), whereas I was getting them _much_ more frequently beforehand (dozens a day). This stops the remote dropping out if the chip has to reset, which it did do a few times a day for seconds at a time. So I’m happier. Anyway, if anyone else would like to try it, here’s the HOWTO part…

The HOWTO part

This patch is against the latest SVN version of ivtv. Things are changing rapidly with ivtv, and there is currently no really stable release (as you’ve probably realised). It might apply against the 0.3.8 release, if you try that and it fails let me know and I’ll post a patch against that version. It should go into the driver, eventually, if it really does sort out the IR chip issues.

Get the ivtv code from svn (you will need to apt-get install svn or whatever first!). See this page for detailed instructions.

svn co http://ivtvdriver.org/svn/ivtv/trunk ivtv

Download the i2c patch from the trac ticket for this issue (I will keep this up to date), or from from here. Apply the patch:

cd ivtv/driver patch -p0 < i2c.patch make && make install cd ../utils make && make install

Then reboot. Please _do not_ just rmmod ivtv & insmod ivtv — this won’t work. If you don’t want to reboot, rmmod _all_ of the ivtv modules first, especially cx25840. If you don’t do that, you’ll get an oops (then reboot, no biggie).
Note that this patch also covers section #3 of the IR blaster HOWTO, so you don’t need to try and apply both patches (if you do that, it will certainly fail to apply cleanly).

That’s it. You should stop seeing log messages related to resetting the IR chip, and the remote shouldn’t drop out at all. That’s the idea anyway. Any feedback would be appreciated!

HTH,

Mark

Comments (20)

Nebula Digi-TV IR driver

Filed under: Random — mark @ 7:12 am

I bought one of these a while ago, and discovered that the remote control didn’t work. After lots of looking at the board, and the help of an accomplished friend with a multimeter we were able to discover roughly what it does. In essence, it’s really dumb hardware There’s an IR demodulator on the end of a wire in a nice box that you put somewhere. That goes back eventually to a flip-flop. Curiously, the output from the demodulator is connected to the clock signal of the flip-flop. This causes the output to be passed through back to GPIO pin 5 of the bt878a chip, which then triggers an interrupt. I’m not clear on how it triggers an interrupt from the datasheet (it’s not GPINT, and in fact it doesn’t seem to set any status bits in INT_MASK). You then prod GPIO pin 4 which is connected to the reset line of the flip-flop. That in fact clears the interrupt, and off you go again. So basically the interrupts give you the edges of the IR pulse train.

With that information, you then have a driver time the interrupts. The supplied remote is RC5, and the edge transition bit pattern can be converted directly back to an RC5 code. Actually works quite nicely, and with a bit of tuning I have it feeling nice and smooth. Obviously the driver isn’t limited to just that remote, all you need to do is cook your own keymap. Since, weirdly, the remote seems to have the RC5 address set to TV, it interferes with my TV. So I cooked myself a keymap for another remote that I have (a Hauppauge grey remote, which is RC5 as well), and I use that instead. This nasty interrupt method seems to feel much smoother than polling the on-board IR thing on the PVR cards, although I will be working on fixing that.

I posted a linux driver to the video4linux list (one that uses the input layer, like ir-kbd-gpio or ir-kbd-i2c). You can probably find the patch in list archives (or if you are interested and can’t find it — ask and I’ll send it to you).

Anyway, it was a bit of fun and that’s my second remote control driver. I think I quite like playing with hardware.

Comments (0)

LIRC PVR-150 IR blaster support, version 2

Filed under: Random — mark @ 2:43 am

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!

Comments (226)

LIRC PVR-150 IR blaster support updated

Filed under: Random — mark @ 2:13 am

I have updated the patch with the following changes:

- Use schedule_timeout not mdelay as mdelay is a busy loop. This fixes high CPU usage during IR sending.
- Drop out of the polling loop when the chip is ready rather than after 1s (can’t believe I didn’t notice this one!). This greatly speeds sending.

As a consequence of the second point, I recommend that you fiddle with the ‘gap’ parameter in lircd.conf. The gap parameter is in microseconds. For my particular cable box, I’ve found that 1/3s (~333,333us) works well. The minimum time is until the chip is ready to send, this works out roughly at about 50-200ms. The minimum delay is fixed at 50ms (avoids wasting CPU; go hack the code if you want to change this), and the maximum wait is 1s.

Comments (1)

LIRC PVR-150 IR blaster support

Filed under: Random — mark @ 12:46 am

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

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

Here’s a basic HOWTO:

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

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

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

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

5. Check everything is working so far:

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

Check the syslog output. This should report something like:

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

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

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

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

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

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

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

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

If you can’t get this to work:

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

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

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

That’s it, good luck!

Comments (40)

Mark’s Braindump

March 7, 2007

Goodbye, Microsoft…

ARC-1160 SATA RAID updated

April 14, 2006

SATA RAID is rubbish

ClamAV Windows Port updated to 0.88.1

January 15, 2006

LIRC PVR-150 IR blaster support, version 3

News

HOWTO

Packaging

October 4, 2005

PVR-150 IR stops responding (fixed!)

Nebula Digi-TV IR driver

August 28, 2005

LIRC PVR-150 IR blaster support, version 2

August 19, 2005

LIRC PVR-150 IR blaster support updated

August 8, 2005

LIRC PVR-150 IR blaster support