Category | tuners

After a rather large bug hunt, I've finally submitted the HVR-950q patches upstream. In the end, we created 24 patches addressing a ton of longstanding bugs: au8522: fix intermittent lockup of analog video decoder au8522: Fix off-by-one in SNR table for QAM256 au8522: properly recover from the au8522 delivering misaligned TS streams au0828: Make the s_reg and g_reg advanced debug calls work against the bridge xc5000: properly show quality register values xc5000: add support for showing the SNR and gain in the debug output xc5000: properly report i2c write failures au0828:...

---

Continued debugging has produced another dozen fixes for the HVR-950q. Most of these are low-probability failure conditions (race conditions, etc). However take a bunch of 1/1000 chance items together and you're likely to hit one of them once in a while... A couple of noteworthy changes: Firmware load time has been sped up to 2.9 seconds (down from 8-10 seconds). This should eliminate the need for MythTV users to specify the "no_poweoff" xc5000 modprobe since it will now load fast enough to avoid a mythfrontend timeout. Fix a case where the xc5000 tuner enters a failure state and all subsequent...

---

I finally spent the day and gathered up all the various patches I had kicking around for the HVR-950q. They can be found here: http://git.kernellabs.com/?p=dheitmueller/cx23885_fixes.git;a=shortlog;h=refs/heads/950q_fixes This includes the longstanding bug at startup that would cause the xc5000 to not properly bind on the digital side, a rather nasty case that hangs the analog video decoder in adverse signal conditions, and a case where sometimes digital tuning succeeds but doesn't ever return a transport stream to userland. It also resolves the confusion users see when the run tools like...

---

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

---

I've applied a few patches to the tda18271 driver that may improve tuning in certain channel ranges. tda18271: fix calculation bug in tda18271_rf_tracking_filters_init There was a misplaced parenthesis in the tda18271_rf_tracking_filters_init function, causing improper calibration. This has potential to improve tuning on some channels, and possibly reduce the time it takes for the RF tracking filter calibration to take place. tda18271: prog_cal and prog_tab variables should be s32, not u8 Changeset name speaks for itself tda18271: fix bad calculation of main post divider byte There...

---

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

---

If you are an HVR-1600 user who has noticed the ClearQAM tuning performance under Linux was worse than under Windows, this should make you happy. As a result of the work described in the previous post, there is now a tree that contains the various fixes: http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-perf-2 The goal is to submit this upstream, but before that we want to get some people to try it out first and submit feedback on their experience. Thanks go out to ONELAN Limited for sponsoring this work! Feedback (good or bad) on the blog or the linux-media mailing list would...

---

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!

---

There are some TDA18271 bug-fix patches awaiting merge that improve tuning performance significantly. Here's a run-down: fix overflow in FM radio frequency calculation Multiplication by 62500 causes an overflow in the 32 bit freq variable, which is later divided by 1000 when using FM radio. Prevent the overflow by scaling the frequency value correctly upfront. fix signedness issue in tda18271_rf_tracking_filters_init Fix a signedness issue in the function, "tda18271_rf_tracking_filters_init" which caused the RF tracking filter calibration values to be entirely bogus under some...

---