[linux-dvb] Re: High BER's & Glitching with 2.6 kernel, betterwith 2.4 and 1.0.0-pre2 (Nova-T)

[Dave Smith <dave@nobodynet.net>]

Having used this driver for a few days now, I still don't think that 
things are quite right.

It's harder to gauge now, since the numbers for signal level / bit error 
rate are now pretty comparible between the 1.0.0-pre2 driver and the 
1.1.0 version (and 2.6 kernel version) of the driver with the buf[3] fix.

Although the numbers are comparable, watching recordings from one of the 
weaker 64QAM mux's, made with the new drivers, do show a lot more glitches 
in the mpeg stream.  Going back to the old drivers does seam to reduce the 
occurences of glitches.

As I say, this time, without numbers to back up my suspicions, it's hard 
to be sure, but it does seem to be a difference between a glitch every 
couple of minutes, and a couple of glitches per half hour.

Any more suggestions?

Cheers,

--Dave




On Fri, 20 Feb 2004, Johannes Stezenbach wrote:

> Dave Smith wrote:
> > 
> > Using release 1.0.1 and a 2.4.20 kernel, I have modified the 
> > tsa5060_set_tv_freq function in the  grundig_29504-401 frontend to match 
> > 1.0.0.-pre2.
> > 
> > Changing the frequency offset from the -pre2 value of 36000000 to the 1.0.1 
> > value of 36125000 made no apparent difference.
> > 
> > In the -pre2 code, there are no values for cpump or band_select, meaning that 
> > buf[3] in that function is always set to 0xc0.  If I change this to 0x43 
> > (which I think would be the value when the frequency of the BBC mux from 
> > Crystal Palace is given) leads to the higher BER rates and many UNConcealed 
> > errors when tuned to a channel in the BBC mux.
> > 
> > I must admit that my understanding of C is pretty weak, and so I may have 
> > evaluated the cpump and band_select errors incorrectly.  However it does 
> > appear that the setting of buf[3] (whatever that does) is causing the errors 
> > on my card.
> > 
> > I hope this helps.
> 
> Hm, I had a look at the code and the tsa5060 data sheet.
> 
> The band_select stuff is beyond me, as it just sets a few
> general purpose output pins. I'm not sure if it does
> anything at all, and the only way to find out is to
> look at a grundig_29504-401 data sheet or poke around in
> the metal box.
> 
> The charge pump stuff is also not clear to me. What is
> the logic behind that formula?
> 
> I would think that either
> - the charge pump current depends on the voltage used to drive
>   the VCO, so: high freq -> low capacitance -> high voltage
>   at the varactor diode (or is it the other way round?)
>   -> high cpump
> - or one uses a high cpump to change the frequency, and
>   sets the cpump to a low value afterwards (less noise)
> 
> Does anyone know for sure?
> 
> Anyway, the current cpump formula look bogus to me:
> 
>         cpump = freq < 175000000 ? 2 : freq < 390000000 ? 1 :
> 	        freq < 470000000 ? 2 : freq < 750000000 ? 1 : 3;
> 
> 
> Comments?
> 
> Johannes
> 
> 
> 


-- 
Dave Smith
dave@nobodynet.net



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