[linux-dvb]%09Mantis%09VP-1027/VP-1033/VP-1034/VP-2033/VP-3033

Marko Ristola 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.

Regards,
Marko

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
>> working:
>>
>> 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
>> implementation.
>> 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
>> inversion.
>> 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.
>
> Regards,
> Manu
>
>   




More information about the linux-dvb mailing list