marko.ristola at kolumbus.fi
Fri Dec 1 17:02:26 CET 2006
I meant 10s only for debugging:
It's better to wait until there is a lock.
Because his frontend seemed to be in single shot mode,
I thought that 10s might be enough to enable
the single shot mode to work.
So because he has reported a scan success,
we have advanced a bit.
Manu Abraham kirjoitti:
> Hello Marko,
> Marko Ristola wrote:
>> Hi Elmar and Manu
>> Maybe the smallest improvement might be to just
>> adjust the wait from 50ms into 10 seconds:
>> if FE_TUNE_MODE_ONESHOT is in use, dvb_frontend.c
>> must just wait a very long time.
> 10s sounds like quite a long time. 50mS works fine if you don't use
> _ONESHOT ?
>> Here are other thoughts, that might be helpful for you to get MB86A16
>> I know that the values that I gave for dvb_frontend_tune_settings
>> might be the best values for DVB-C.
>> With DVB-C with me, max_drift and step_size must(?) be zero.
>> So no heuristics to figure out the optimal frequency.
>> With dvb_frontend.c frequencies are tested with steps.
>> One frequency step is defined with step_size.
>> max_drift gives an upper limit to the maximal frequency
>> drift based on the given original frequency. The max_drift is reached
>> by stepping long enough.
>> In dvb_frontend.c in function dvb_frontend_swzigzag_autotune() there is
>> heuristics for this optimal frequency selection.
>> That function needs nonzero max drift and step size.
>> Maybe the unit is HZ on both of them.
>> dvb_frontend_swzigzag_autotune() function assumes that
>> fe->ops.set_frontend() is a simple function:
>> Inversion selection and small frequency tuning are done in dvb_frontend.c.
>> That's what I found with cu1216.c with frequency setting function:
>> by simplifying cu1216.c I managed to make cu1216.c to work.
>> dvb_frontend.c assumes, that cu1216.c has a simple frequency
>> setting with no inversion heuristics and with no frequency drift
>> heuristics of it's own.
>> cu1216_set_parameters() has also a very short maximum delay on my
>> That made dvb_frontend.c to do correct and successful
>> LOCK heuristics for me.
>> cu1216.c still figures out best gain setting for the given frequency and
>> That is not done in dvb_frontend.c.
>> So you could do further testing by simplfying mb86a16.c and testing
>> with different values on step_size and max_drift.
>> The problems seem to be mostly on software side, so it is this heuristics
>> and mb86a16_set_frontend() and mb86a16_mb86a16_read_status() function
>> that are critical for lock acquirance.
> For the mb86a16 read_status just reads back the resultant status of the
> _set_fe. All the operations are handled in set_fe.
> in the case of the MB86A16, one doesn't get a LOCK unless viterbi is
> synchronous. So at that point of time there is no need to have a delay
> any further.
> I just updated the tree, which gave quite impressive results for me with
> the MB86A16, in terms of locking time, when the Carrier recovery
> frequency search width was changed from 5Mhz to 3Mhz. It looked quite
> stable also with a width of 3Mhz.
> Locking is also faster, as a result of this.
> Will require some amount of testing though to verify this.
More information about the linux-dvb