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
