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
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
