I have off from work today, so I came out to Philadelphia a day early. In the coffeehouse now getting caught up on some email while Victoria is at the gym.

I managed to kill a PC last night. Plugged it in and sparks and smoke started to pour out of the power supply. Fortunately, it was just the crappy Windows PC I use for reverse engineer Windows drivers, but it will still set me back since I now have to get Windows installed on a different PC and setup the debug environment again. I guess this is also now an excuse to try out the OSX version of the Saleae logic analyzer application I also use the PC for.

My new soldering iron arrived yesterday, but again won't be of much use until I get the Windows PC back online (since the whole point of getting the iron was to be able to hook onto the PCTV 340e's i2c bus).

Going to New Jersey tomorrow to see the family and celebrate a couple of birthdays.

I wanted to take a few minutes and respond to some ideas put forth by Andrej Falout, who was also kind enough to make a donation toward my LinuxTV efforts. Let's take his comments point-by-point.

1) When working on devices where no signal is available, how about using SSH to log in remotely to the box where device is connected and signal such as DVB-T is present?

I actually have done this before (in fact, two weeks ago the Terratec Cinergy T XS USB lock problems were resolved this way thanks to Simon Kenyon providing SSH access to his environment). Sometimes this approach is viable, sometimes it is not. There are significant advantages to having physical access to the hardware, including the ability to use tools like an oscilloscope and logic analyzer. Also, the software environment, antenna configuration, and list of accessible frequencies are known in my environment. To look at another example, I have been working with a different user on the mt352 version of the Terratec Cinergy T XS USB, and I don't know if it doesn't work because of a driver problem of mine, or whether it's user error, poor access to a signal, bad antenna, etc.

For simple things like a new board profile for existing supported chipsets, it can work. For cases where new drivers need to be written or the existing chipset drivers have bugs (which is more often then I like to admit), it is extremely difficult.

2) The key to getting vendors to pay, is to show number of users/devices sold because they work on Linux. Add a message to driver load, such as "Register and rate your device at http://devinjh.livejournal.com", as well on the V4L wiki for that device(s). Then when you can show 50 or 100 users registered, contact the vendor(s) and offer to continue supporting device, and maybe even future devices for a reasonable fee...?

There has been considerable discussion of ideas like this between myself and the KernelLabs developers. There are two basic problems: once the driver works, the vast majority of users never even notice (so they have no incentive to seek out the person who did the work), and things like surveys on the v4l wiki only have the opposite effect. They tell the vendor, "there are only ten people who actually care about Linux support for my device, so why should I spent $1000 in consulting for Linux support"

3) http://en.wikipedia.org/wiki/Smolt_(Linux) may be of interest in determining numbers of devices in use

Again, smolt only hurts the community in this case. Look at those stats. If I were a vendor and I actually took those stats into consideration, they would tell me there might be a few thousand users across the entire industry. I realize that it's a small sample of total users out there, but vendors are not likely to see those finer points.

4) Create few wiki pages on V4L site, for devices you are offering to work on for a fee/donation. Make it clear how much is needed to be contributed for work to start, and provide a easy mechanism for users to donate AND see how many donations are made so far.

Certainly we have been discussing various approaches such as this (surveys, contribution pools, etc). I hope to see some of this come to life in the next few months.

5) Approaching chip makers may be a better choice then talking to the device marketers/assemblers ?

I have worked with a number of chipset vendors, and even getting them to provide datasheets so I can write a Linux driver is usually like pulling teeth (and in reality has only ever happened when I found a product vendor to pressure them to do it). Getting them to go one step further and actually pay for Linux support is even further off.

Some classes of hardware tend to have vendors who are happy to make technical information available (think CPUs). However, the tuner and demodulator vendors are extraordinarily protective when it comes to IP concerns and trade secrets.

Anyway, I continue to look for economic models that are viable. Thanks for helping further the discussion.

Yeah, so Verizon has returned to meeting my expectations (they absolutely suck). They scheduled my repair for 5:30 to 9:00pm, and then I called and found out there is no such repair window. Now I'm scheduled for 8am to 12pm tomorrow (and since they cut off my DSL service I will have to miss work). Apparently the support representative was baffled, not knowing how they other person managed to schedule me for that time in the computer.

Got home from work at 7pm. Watched Jeopardy while eating salad for dinner. Spent about an hour with an oscilloscope working on the PCTV 340e, and isolated the i2c problems preventing the bridge from talking to the xc4000 tuner.

http://kernellabs.com/hg/~dheitmueller/pctv-340e

I found out that both Subtle Tea and Keiko Cafe both close early. I thought this was supposed to be the city that never sleeps...

I'm at Bryant Park now, taking advantage of the free wireless with the outdoor movie in the background. It's funny, since years ago I would leave work early in New Jersey, drive to Bridgewater Station, catch a train to New York City, and come to the park to see the movie with Carter. Now I just walk six blocks up the street from my apartment.

So, I spoke to soon: I came home last night from the weekend in Philadelphia and found my FIOS was down. Called to put in a support ticket, and they scheduled me for 5:30pm to 9:00pm tonight.

I got a phone call at 9:25 this morning by a tech asking if I was home. Unfortunately, I came into work early so I could be home at 5:30. If I had known they were going to show up at 9:30, I would have just gone in late. However, since their window during the day is 8am to 5pm, I couldn't afford to take the risk that they would show up at 4:30pm and miss a whole day of work.

And for once Verizon did something right and shut off my DSL within 72 hour of my asking them to. Unfortunately, that means I now don't have any Internet access at all from home.

Here's a quick read that I found entertaining:

13 Year Old Uses Walkman for a Week. Result: Embarrassment
http://www.wired.com/gadgetlab/2009/06/13-year-old-uses-walkman-for-a-week-result-embarrassment/

Been a few days since I've posted. I'm having trouble now that I have three different blogs - this one, http://www.facebook.com/devin.heitmueller, and http://www.kernellabs.com/blog. Trying to figure out which one to post to, and how to handle cases where the content overlaps. Annoying.

Here's another fine case where AT&T cannot figure out that there is a difference between 0.015 dollars and 0.015 cents (here's a hint: one is a little over one penny, and one is about 1/100 of one penny). This time though, it was MythBuster's Adam Savage who resulted in an $11,000 bill, and with 60,000 users following his Twitter account AT&T seems to have bent over backwards to resolve the issue pretty quickly.

MythBuster Adam Savage Leads Twitter Revolt Against AT&T

In a Philly coffeehouse this afternoon while Victoria is at trapeze. A couple of her friends are coming over tonight, and then her cousin moves in tomorrow. Going to try to look a little closer at a couple of the bug reports that came up this week with 950q analog.

Well, as someone who does quite a bit of hiring in the tech sector, I couldn't agree more with this headline.

Indian CEO Says Most US Tech Grads "Unemployable"
http://news.slashdot.org/story/09/06/22/0019233/Indian-CEO-Says-Most-US-Tech-Grads-Unemployable?art_pos=7

So depressing, but *so* true.

Victoria and I had a nice quiet weekend. On Saturday night she went out with her friends for dinner, and I got the Terratec Cinergy T XS working (the version with the zl10353). Also wrapped up the EVGA inDtube work which got merged today into the mainline (more details can be found on http://www.kernellabs.com).

Also, because of all the people complaining about the analog bug for the HVR-1250 and HVR-1800, I broke out my boards to debug the issue and discovered that the HVR-1250 has a bad eeprom and the HVR-1800 didn't even register in lspci. Since this is the first time I've tried to use the PCIe port on my Dell 530n, I'm not sure if I just had bad luck and both cards are actually bad or whether there's something wrong with my PC.

I've also been debating what to work on next. After upgrading to the alpha release of Ubuntu Karmic Koala, I discovered that they are now bundling Kaffeine 1.0pre2 instead of the older 0.8.x codebase, which means I should do some work there to make ATSC work well or else people will see a regression. I've also responded to a few different emails over the weekend about em28xx audio, em28xx remote control support, and the em28xx power problem, which suggests perhaps I should give them some attention. On top of that, I would like to get the xc4000 project started, but without a generator the best approach would probably be to get analog working first - except the dib0700 driver doesn't have analog support so I would have to do that work first. The upside of that approach would be though that the Pinnacle PCTV 801e would finally get analog support, something many users have asked for.

Ok, enough rambling for now on things I could be working on...

Took a break from LinuxTV stuff tonight. Cleaned my apartment. Did laundry. Watched episodes from the first season of 30 Rock on Netflix. Made a big hole in my wall over the bathroom so I could see about converting it to storage space.

I did do some more debugging on the EVGA inDtube based on the logs Alan sent, and I think I might have uncovered the same race condition that I saw on cx88, where hald connects to the analog side of the board while the DVB driver is still initializing. I've seen it before on other bridges (I hit it on both cx88 and au0828), but I had never noticed it before in em28xx.

Ok, so I guess I didn't actually take a break from LinuxTV stuff. I only worked on it for an hour compared to most days where I do it all evening.

Here are the pics from our New Hampshire trip last week.



(Click on the picture above to see the full gallery)

For the eighteen months or so, I've been actively contributing to the LinuxTV project. It all started with a personal need - I wanted the Hauppauge HVR-950 to work under the default Linux kernel so I could watch TV. This prompted me to learn the intricacies of the DVB subsystem, how devices such as this are designed, how ATSC worked, the relationships between demodulators, tuners, bridges, i2c, etc. I got the device working, and then wanted to leverage the time and knowledge gained to see if I could make other devices work. So I bought another device... And another... And the next thing you know I have a rather sizable collection of devices that now all work under Linux.

Hundreds of dollars spent. Hundreds of hours spent. Lots of devices working, even though I only needed one of them myself. I've convinced myself to buy devices that I failed to successfully debug in the field with users, since I didn't want to admit that all the time was wasted for nothing. To this day, I have never received a single dollar for any of this work.

Now, I'm more than happy to help the community with my time and energy. But the situation with the money has gotten out of control. More recently a couple of vendors have been kind enough to provide free sample hardware under the presumption that I would improve the driver support, which helps alot. However, I'm getting requests from people abroad now to help them with devices that use European broadcast protocols such as DVB-T (even sending me the hardware in some cases). I've reluctantly agreed to help, under the presumption that the devices would be relatively easy to get working (given a number of them were variants of pre-existing designs I've worked with).

This was a mistake.

I was able to bootstrap the driver support relatively quickly, but without a legitimate signal source to test with, debugging is a nightmare. I'm forced to have users in those countries test the support. Case in point: I've now exchanged 35 emails on the Terratec Cinergy T XS that a user sent me, and I still haven't gotten it to work. I don't know if there is a driver problem, user error, a lack of a reliable signal source, etc. If I had a DVB generator, I could probably get it to work in a couple of nights, iteratively debugging the various components. However, doing this over email with relatively inexperienced users in an unknown software environment is just not practical.

Now I am faced with a decision: do I continue to email back and forth with the users to continue trying to isolate the problem? Do I go out and spend $2000 to buy a DVB signal generator? Or do I just admit failure and send the hardware back to the users?

I cannot keep doing this while personally spending money buying stuff I don't personally have any user for. I'm not trying to be greedy. I am willing to donate my time, but my volunteering to make these devices work should not be *costing* me actual money.

There needs to be a new model.

If a user plugs in his tuner under Linux and it "just works", he never gives it a second though. Just like I never give a second thought to who wrote the Ethernet driver for my PC. The user has no incentive to pay after-the-fact for all the work that was done to make it work. Likewise, the manufacturers who make the tuners have no way of determining how many people are actually using them under Linux, so they have no incentive to pay for consulting services, even if it's just to cover the cost of test equipment.

The last time I needed a soldering iron, I had to take a subway 90 blocks uptown to City College to use the iron a very nice Electical Engineering student was nice enough to make available. I couldn't bring myself to spend eighty bucks to buy an iron to fix some random user's device.

Another fine example: When I was doing the HVR-950q analog support, and I spent a week debugging what ended up being a bug in the chip's i2c implementation. The only way I ultimately figured out the problem was when I spent $150 and bought a logic analyzer to look at the i2c bus waveform.

I was fine spending the 100 hours of my time to make analog support work on the 950q, even though I had no personal interest in analog support. But the fact that I spent $150 of my own money is something that just rubs me the wrong way.

Suggestions certainly welcome regarding how this problem can be dealt with.

Anyway, Devin's LinuxTV tip jar sits here, in case any of those people who have benefited from my work feel like contributing to future development...