By Date: <-- -->
By Thread: <-- -->

Pinnacle PCTV40i analogue noise with recent kernel versions

Hi, Karsten

Karsten Suehring wrote: 
Well, the eeprom dump has an unusual structure, but what i see is as
expected.
Tuner is regular TDA8275A, analog only with FM radio, right?



Yes. Analog only with FM radio.


And if you problem occurs with the composite input, the tuner is out of the
game anyway...
The funny thing is that you have problems with the I2C bus. Are your
mainboards
the same type? I somehow suspect the power supply. There also might be some
special - GPIO controlled power save mode i don't know about. On the
board with
eeprom read failure: Does the problem still exist after you rebooted the
machine
without power cycle?



One of the cards which reported the dump was running in a different
mainboard, but also on SuSE 10.0. The other cards were in identical
machines running on Debian. One of these also reported the dump. This
machine had a different kernel build (2.6.15-1-686-smp-2.6.15-3) than
the others (2.6.14 and 2.6.15-1-686-smp-2.6.15-4). After upgrading to
the newer build, this machine also stopped reporting. But downgrading
again didn't restore the old behavior, so I tried power cycling. This
worked on the first try, but wasn't reproducable again. I tried a card
in a Debian machine similar to the SuSE box and also didn't get a
report. I think "works sometimes" is not what you wanted to hear... ;-)

Maybe it's something related with the debian kernel.

Not sure whether we already had this:
Please ensure that you are using the new drivers from linuxtv.org.
The code supporting your version of the tuner is quite new and using
the old version causes an i2c failure. The only way out of this is to
power cycle the machine. This also means that you *must* ensure that
the system does not load old modules in between.


Lets get back to the noise. It is always reproducable that the noise
exists in 2.6.15, while I don't have a noise with 2.6.12 (same machine
with both kernels not dumping the eeprom content). So we should try to
concentrate on the software change that caused the difference.

I finally managed to set up the kernel sources properly for compiling
the Mercurial v4l tree. So do you have any ideas where I could start?

Not sure what you mean. To my experience, you should  *not* merge the
mercurial tre into the kernel source. just unpack it and do a make and
- optionally - a make install.

I uploaded two example grabs for noise and clear picture to my web site.
The files contain 50 frames 720x576 in plain 4:2:0 YUV format packed
with zip.

http://iphome.hhi.de/suehring/tmp/out_dist.zip (20MB)
http://iphome.hhi.de/suehring/tmp/out_clear.zip (15MB)

A player for this format can be found at the following url:
http://www.tnt.uni-hannover.de/~vatis/yuvplayer.html

Aha. You mean the small dots? This is "cross luma" distortion. It occurs
when the decoder expects s-video but receives CVBS at the Y input. This
also occurs with not properly shielded s-video cables due to cross talk.
This is more common than you might expect.

If you are interested in the technical background:
The small dots in the coloured areas are the modulated colour carrier. At
PAL, this is a quadrature modulated 4.43MHZ carrier. In CVBS mode, a notch
filter suppresses this at the cost of some bandwidth. This filter is off
in S-video mode since there are separate inputs for the Y and C signals.


Best regards,
Karsten

Best regards
   Hartmut

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list