[linux-dvb] LG Innotek TDVS-H062F / TDVS-H061F

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mac Michaels wrote:

>This metal box has 3 different i2c addresses inside it. I am 
>trying to properly structure the driver for it.The 
>FusionHDTV 5 card uses an TDVS-H062F. I have a hack that 
>works, but I must clean it up. Yes, I have a version of the 
>FusionHDTV 5 driver that works and has been tested with 
>8-VSB signals. QAM should work, but is not tested. I will 
>release a patch after I get the code cleaned up.
>  
>
Good work!  I await the patch for testing...

>The LG Innotek TDVS-H062F NIM tuner is a more sensitive 
>version of the TDVS-H061F. The main differences between 
>them is power consumption and noise specifications. They 
>both program the same way. These are designed for USA and 
>South Korea in that they handle NTSC and 8-VSB ATSC. They 
>also support cable with QAM-64 and QAM256. There are three 
>different parts inside that use three different i2c 
>addresses.
>
>TUA6034 Tuner at i2c address 0xC2 (0x61)
>
>NTSC IF Demodulator at i2c address 0x86 (0x43)
>
>LGDT3303 VSB/QAM Demodulator at address 0x1C (0x0e)
>  
>
Best for these three devices to have separate drivers... Currently, 
v4l/tuner-simple code is working for TUA6034 in analog mode, and I 
suspect that the DVB_PLL_DESC is sufficient for basical functionality of 
this tuner.  Patrick Boettcher has spoken of writing a special driver 
for this tuner, but I think analog drivers can survive using 
tuner-simple.  (it works for me, and other users that have tested analog 
capability with TDVS-H062F)  Once Patrick has something to test, we can 
make a final decision on how to handle TUA6034.... I still am not sure 
why he suggests a separate driver for this tuner... Perhaps Patrick can 
add to this discussion........

Analog video4linux drivers are (incorrectly) recognizing the NTSC IF 
Demodulator as a tda9887... This is because they share the same i2c 
address.  Analog drivers are currently working without a driver for the 
NTSC IF Demodulator, but once we implement ATSC on this, the NTSC IF 
Demolulator will certainly be of necessity.  I suggest writing a 
*separate* driver for the NTSC IF Demodulator, and that it be included 
within video4linux cvs.  It will need to be called by both tuner-core, 
and cx88-dvb / bt8xx-dvb.

I will need some code to insert into tuner-core, to initialize the tuner 
to analog state. This seems to be the only thing missing in analog 
implementation of TDVS-H062F right now... It is working without it, but 
it would be better to include it.  I can show you an example of what I 
am looking for, if necessary... If you look at video4linux viewcvs, I am 
looking for something similar to what hhackman did in revision 1.16:
    - support for Philips FMD12ME hybrid tuner
    - allow to initialize with another tuner

We do need a separate driver for NTSC IF Demodulator, and tuner-core 
should call NTSC IF Demod to reset to analog state, and [cx88-dvb / 
dvb-bt8xx] should call NTSC IF Demod to reset to digital state.

>TUA6034 is a 3 band tuner that is controlled by a 4 byte i2c 
>message. There is a small wart in that an additional 
>setting can be made by setting a constant pattern into byte 
>3 to affect the meaning of byte 4. This was cleanly handled 
>by testing the tuner type to see if it has this capability.
>
>NTSC IF Demodulator needs some help. I did some bad things 
>to make this work. I grabbed the i2c-adapter from the 
>TUA6034 and used a different i2c message address to twiddle 
>the bits of the NTSC IF Demodulator. It is a hack that 
>works but... 
>  
>
maybe this works, but it is not the right way...

>NTSC IF Demodulator gets programmed differently from the 
>TUA6034 tuner. It is on a different i2c address. It uses 
>pairs of bytes in an address, value combination to set the 
>program. It must be in one state for digital TV and another 
>state for analog TV. It does not change when channel 
>frequencies are changed. Should I create a new device for 
>the NTSC IF Demodulator?
>  
>
yes (see above)

>LGDT3303 is a complex chip that has its own driver. The 
>driver also supports  LGDT3302. The chips are pin 
>compatible, but many of the i2c addresses and data vary. 
>Basic operation is very similar. This works well as a 
>single driver for both chips.
>
If you have new patches ready for lgdt330x, please send them my way, 
separately from the other changes mentioned above, if possible... (show 
them to me here on the list)  If your new version of lgdt330x doesnt 
depend on the other changes, I would like to put it into cvs.  The 
reason for this is, the current lgdt330x in cvs probably has some 
incorrect configuration for lgdt3303, and if you have corrected that 
already, it makes sense to apply it.

Keep up the good work!

-- 
Michael Krufky





[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux