[mythtv-users] PVR-150 Tuner Quality Issues
Michael T. Dean
mtdean at thirdcontact.com
Sun Apr 16 20:24:20 UTC 2006
On 04/16/2006 02:42 PM, Brian Wood wrote:
> On Apr 16, 2006, at 11:19 AM, Michael T. Dean wrote:
>> Therefore, you must pass a "tuner=" module option to ivtv ("options ivtv tuner=xx") to select the closest match (at this point, there are only 75 to choose from--and you've already tried #4 ;)--but you can narrow that down by selecting only the NTSC or PAL tuners as appropriate). Your best bet for finding the right tuner is the IvyTV mailing lists. There, you would likely find the closest matches (and, whether that's a true match or whether you need to patch your tuner module for proper reception).
> I guess I can understand why there might be 100 or more tuner
(Where here module means a physical piece of hardware.)
> , even though it seems ridiculous, but why on earth are there
> that many control protocols, since they all seem to need something
> different to control them.
The control protocol is generally the same for all the tuner module
hardware in existence today, which is why Linux is able to control "any"
tuner with only one kernel tuner module (software). Linux just sends a
command to the tuner module hardware via the I2C bus.
However, each tuner has slightly different characteristics, which are
used to determine the exact command to send. Specifically, the tuner
module needs to know the thresholds for band switching from VHF (low) to
VHF (high) and from VHF (high) to UHF, band control bytes (for VHF
(low), VHF (high), and UHF), config bytes, and intermediate frequency
(picture carrier) offset. Once these characteristics are known, the
kernel tuner module can ask the tuner module hardware to tune to
specific frequencies as requested by the application.
> Can you imagine if there were 75 or more different control protocols
> for hard drives? or serial ports? Even with things like scanners and
> printers, where every maker seems to want to have their own protocol,
> there are not *that* many different ones.
> It seems like the video capture card manufacturers would revolt about
> having to have 75 - 100 different protocols, although if the
> characteristics are just loaded into an eeprom maybe they just don't
Actually, the eeprom usually just contains a
capture-card-vendor-proprietary identifier that can be used to look up
the hardware tuner module from a list maintained by the capture card
vendor. You've probably seen stuff like "idx = 112" (the OP is actually
seeing that specific index number) in the tveeprom output. It means
that this particular card is #112 in Hauppauge's list, so it's
components can be identified using the list. Fortunately, Hauppauge has
been happy to share their list with the IvyTV developers.
> Still it seems like an incredible waste of resources, I guess that's
> what happens when nobody can/will force some consistency.
It would definitely be easier to support all capture cards if every
hardware tuner module supported the same characteristics, but the
current approach works well--once we get the tuner characteristics.
Although Hauppauge is very supportive of open-source driver development
for their cards, they are bound by NDA's that prevent them from
providing datasheets for some of the hardware components they use.
However, they have--in some cases where IvyTV devs couldn't obtain the
information directly from component manufacturers--even been willing to
submit a request to the component manufacturer to get explicit approval
to share the needed information with IvyTV devs. However, this is
generally only used as a last resort when all other approaches fail
(because it's really not Hauppauge's job to do this--they just do it to
help out). (And, please don't go to Hauppauge with requests to do
this. Instead, these types of requests are "queued up" by the IvyTV
devs and submitted in batches when necessary. We definitely don't want
hundreds of IvyTV users going to Hauppauge with the same requests, so if
concerned, post to the IvyTV lists and see if you can convince the devs
to submit the request--or find out the information has already been
On the bright side, though, now with 75 definitions, there's a good
chance that one of the definitions is close (if not identical) to the
one needed for a new tuner. So, someone buying a new Hauppauge with a
new tuner module may try different definitions to find the best match
and post that information on the IvyTV mailing list. Eventually, the
drivers will be updated to reflect that the new card uses that tuner
(or, if the tuner is found to have slightly different characteristics, a
new definition will be created in the tuner module and the drivers will
be updated to make the new card use the new tuner definition).
Note, also, that when it comes to tuner characteristics, you can even
get very close by guessing/trial-and-error. I found the characteristics
for 47 (LG NTSC (TAPE)) this way because after I promised to build a
Myth box for a friend who uses analog cable, he ended up with 4
PVR-250's all having the same unsupported tuner module. After I had
gotten the tuner definition into the kernel's tuner module, we acquired
a datasheet, so I was able to determine that I got all the
characteristics right (at least according to the datasheet ;) with the
exception of 1 band-switch frequency (which I've since updated in the
kernel module to agree with the datasheet). With that freqency wrong,
two channels received less-than-perfect reception (but the cable lines I
was using for testing didn't receive those channels, so I couldn't even
I also did the definition for type 50 (TCL 2002N, which I have--but
didn't worry about because I use S-Video input), but it was
significantly easier because someone else obtained a datasheet for me to
use before trying to create the definition. :)
So, if you get a tuner module that's as-yet-unidentified, you can go
through the list of tuners trying each until you find the best match.
However, since someone else may have already done this, you should start
with the mailing list for development of the drivers for your capture
card... :) And, if all else fails, there's the "find the datasheet or
guess at the values" approach.
More information about the mythtv-users