On Monday 25 July 2005 23:23, Hartmut Hackmann wrote:
> Hi, Andrew
>
> > Actually I reverted my change because it made things worse on a different
> > machine. I've been getting no errors at all now, so I don't have anything
> > else to change.
> >
> > What problems have you been getting?
>
> It looks like there is quite a number of uncorrected errors in the
> transport stream (but not constantly). The reception conditions here are
> poor: not much energy and short echoes in the signal (what i remember from
> analog days) So at most channels, i have a quite high raw ber which is not
> really surprising.
> But i see that my settop box, which also has the tda10046 channel decoder,
> does a significantly better job. This convinces me that there is room
> for improvement.
Ah right. I seem to have a good signal here - good for me, but not for
debugging this sort of thing. Hmm, I wonder if I could rig up something to
reduce the signal quality a bit.
> You might know that i already spent some effort on the driver for this
> chip. But there i concentrated on the initialization and on supporting
> more tuners. I hardly looked at the tuning algorithm yet and i suspect
> this is not perfect.
> I guess that you might have played with the parameter for the IF frequency.
> Best working for me so far is the Medion card with the FMD1216 tuner.
> While i tried to optimize it a bit, i found that i get the lowest raw
> ber when i set the IF frequency to 36.125MHz. This cannot be correct
> since the tuner is not even able to provide this IF frequency. What I
> suspect is that the crystal of the channel decoder is quite far off.
> The chip seems to be able to lock with a high frequency offset but does
> this with some performance degradation.
> I don't know what is precisely in this IC, but this is what i observed so
> far. If you find something similar, this gives a good starting point
> for optimization.
I reckon you should try playing with the frequency offset correction registers
in the tda10046.. if the crystal is quite far off, you may be able to correct
for it by varying those. The chip seems to have an auto-find-offset mode and
also a set static offset mode.
I'm talking about the AUTOOFFSET stuff in reg 0x01-0x05, and maybe also
registers 0x4d, 0x4e, 0x3e.
I've been implementing something like this in the DVBS drivers I write
recently... e.g. in the s5h1420, I have:
state->config->pll_set(fe, p, &tmp);
s5h1420_setfreqoffset(state, p->frequency - tmp);
So first of all, I set the PLL to the frequency the user asked for. It returns
the tuned frequency into tmp. Then I set the the s5h1420's frequency
compensator to take into account any difference between the desired
frequency, and what the tuner is actually locked to.
