[linux-dvb] Re[2]: DVB-C it got worse!

[Micael Beronius <micael.beronius@telia.com>]

Hello Holger,


>> But I do not really think that there is a need to reset the chip up to
>> two times each call to ves1820_setup_reg0(). I would like to take, at
>> least, the last reset calls out.

HW> It is. When you want to see if your changed parameter set causes a 
HW> frontend lock you have to apply this parameter set by toggling CLB.

I see. Even if this makes sense to me; where did you find this information,
in the datasheets?
My test revealed that it works for me even if i take both reset's away.
Maybe not as good though...

>> I also for now have made the function to use auto inversion only if so
>> specified, since I feel it may work a bit better, but I'll test things

HW> This is not possible. If the I/Q pins (and so the meaning of the 
HW> inversion bit) are reversed or not depends on the used hardware. The 
HW> ves1820 based cable version of the dbox2 has the PLL wired correctly, 
HW> and so the meaning of the inversion bit is different from the one of the 
HW> Hauppauge DVB-C cards.

I see your point. However, on my card, the inversion is also correct.
But I guess this just proves your point.. ;-)

>> a bit more, primarily I will use the last cvs with the above patch to
>> see if I feel it is good enough. My gut feeling says that it is not as
>> good as the manual inversion setting when the zig-zag tuning starts,
>> which by the way always happen to me if I stay at the "correct"
>> frequency ( 322000000 for example always zigzags down to something
>> like 321625000 ).

HW> This phenomenon should not be caused by the autoinversion code. In 
HW> Finland and here in Germany are some tronsponders offset'd by +-125kHz 
HW> or +-250kHz too.

OK, good to know. Of course I understand this is not the cause of the
autoinversion, but in my set-up, many times, once the zig-zag'ing
started, the "lock" gets missed on the first try. I felt this was a
tad better when no autoinversion where taking place.

>>                 reg0 ^= 0x20;
>>                 dprintk ("ves1820_setup_reg0: Setting Inversion bit to %d\n", (1 == (reg0 & 0x20)) );
>>                 ves1820_writereg (fe, 0x00, reg0 | 0x01 );

HW> don't we have to clear the CLB bit here before we set it again? I'll add 
HW> this to the driver...

Works for me, but I cannot backup why, with my recently updated
knowledge ;-)


HW> many thanks for your efforts, I'll apply the fixes to CVS, please test 
HW> and report if everything is working as expected,

Yes, cvs is fine now.


On another subject;

I have seen sometimes that even though I get a lock, I do not get a
picture (on the video out, have not tested the v4l i/f). A channel
change away and back resolves this issue.
Is this a known issue?

Also, I think reported already, on some occasions, after (1-2 seconds)
a lock and picture, the picture goes black to return again.
Is there an explanation for this? I have tried searching back, but I
cannot find the thread dealing with this.
(Yes, I _really_ like the zapping to be quick /zpeedmanic)

-- 
regards,
 Micael



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.