[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  
> modules

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

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

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

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.

Mike


More information about the mythtv-users mailing list