Category | 340e

The PCTV 340e is one of those unfortunate situations that I (Devin Heitmueller) personally take alot of criticism over. About two years ago I bootstrapped the driver, got it working with the hardware, but then never got around to cleaning up the code enough to get it upstream. This has resulted in the HG tree I created to fall behind current kernels, as well as people being frustrated that the work isn't available in the upstream kernel where they wouldn't have to recompile my driver every time they do a kernel update. While I generally strive to get my changes upstream so that they help out the maximum...

---

Things continue to be busy here at KernelLabs. This week submitted a patch upstream which results in the IR receiver support starting to work on the HVR-1150 and HVR-1120 boards. This was something that several people had been mentioning to me as an issue over the last nine months. Thanks go out to Fernando Laudares Camargos for sponsoring the work that finally got this stuff fixed. Last week we also loaned out a couple of boards to Jarod Wilson to help him do some debugging on the IR support for the cx88 and saa7134 based products. For those of you who don't know Jarod (http://wilsonet.com/),...

---

In response to ongoing issues with the IR support for dib0700 and firmware 1.20, I spent most of yesterday refactoring the code. When firmware 1.20 was introduced, the dib0700 switched from a polling model using a USB control message, to the messages being delivered on a USB bulk pipe. The code I originally added would do a blocking read on the pipe with a 50ms timeout. Because the dvb-usb-remote code makes use of the global workqueue, this resulted in the global workqueue being blocked 50% of the time. Also, the synchronous urb_bulk_msg() call would burn excess CPU time (reflected as an abnormal...

---

We received a good bit of feedback in the last 24 hours from users trying out the PCTV 340e driver, and I am happy to say that 100% of it has been positive. There were a few issues with new users not familiar with compiling v4l-dvb from source code, but everybody who has tried it so far has reported success. That said, I want to take this opportunity to thank a few parties: Lars Forseth, for loaning me a PCTV 340e Solo board for initial testing. Our friends at Xceive for providing support on the xc4000, in addition to providing licensing to freely redistribute the firmware (we will be working...

---

I finally got the new DVB generator up and running, and spent the afternoon debugging the PCTV 340e. The digital support is now working! http://kernellabs.com/hg/~dheitmueller/pctv-340e-2/ As always, there are a bunch of caveats: The testing as of this point has been *very* limited. I have basically confirmed that tuning works with tzap/mplayer with 8MHz DVB-T. The code needs a bunch of cleanup before it could go into the mainline. It's also based off a version of the v4l-dvb tree that is several months old and needs to be rebased against the current tip. This means that if you have...

---

So I am now at the point where I am ready to start debugging signal lock. This is the phase in the project where all the code is written but has never actually been tested/debugged. My situation however is complicated by the fact that I do not actually have access to a DVB-T signal currently. While I will be soliciting testers in general once I have something that I think basically works, at this point, I need one experienced user with access to a DVB signal who can provide an environment for me to remotely debug the board. The ideal candidate: Owns a PCTV 340e Has used DVB devices...

---

This weekend I spent some cycles working on the xc4000 driver and the surrounding code required for the PCTV 340e. I think I now have the PLL properly programmed, and I worked around the i2c clock stretching deficiencies in the dib0700. We're quickly approaching the point where I'm ready to start testing for signal lock. Once we have signal lock, there will be a call for testers, so stay tuned!

---

Did some more work on the PCTV 340e. After talking to Rainer over at PCTV as well as Patrick Boettcher, it seems pretty clear that this is some sort of issue related to the dib0700 not properly handling the xc4000's clock stretching. Pretty annoying though, since the last dib0700 device I worked on required me to fix up the dib0700 i2c interface, and it seems like again the i2c master is going to need more fixes. Also continued investigation into the situation with VBI support for em28xx. After confirming that neither Hauppauge WinTV 7 nor Pinnacle TVCenter Pro supported closed captioning,...

---

Spent another evening working on the PCTV 340e. I refactored a bunch of the xc4000 code so the standard firmware and scode blobs now successfully load. For the moment the video standard is left at the default and the driver is hard-coded to 8Mhz DVB-T. Also started going through the dib7000p configuration, which is needed before a lock is possible. I'm through the AGC configuration and just have to do the PLL config. Once that is done I will ask David to make a tuning attempt on 8Mhz and see if he gets a lock.

---

Spent most of the afternoon working on my tool which generates the firmware images for the xc4000. Pulled in the code from the existing xc2028/3028 driver to load the scode/std firmware into the chip, but it seems to fail the i2c write with the DTV8 standard. Probably some issue with switching between direct/indirect mode. Once that is done, we should be in reasonably good shape for the xc4000 driver (aside from a bunch of cleanup work). Will then have to get the dib7000p config setup at which point we can attempt to tune. In other words, continuing to make forward progress...

---