Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Tuning problems with the refactored drivers



On Sunday 17 Oct 2004 22:29, lamikr wrote:
> Andrew de Quincey wrote:
> >On Sunday 17 Oct 2004 22:01, lamikr wrote:
> >>Andrew de Quincey wrote:
> >>>On Friday 15 Oct 2004 03:40, Andrew de Quincey wrote:
> >>>>On Thursday 14 Oct 2004 19:57, lamikr wrote:
> >>>>>Hi
> >>>>>
> >>>>>I am using 2.6.8.1 kernel (mandrake patched).
> >>>>>I tested the refactored drivers with the TT DVB-C 2.1 Premium.
> >>>>>Drivers build ok and I was also able to load them succesfully.
> >>>>>(I build and loaded drivers separately from the build-2.6 directory.)
> >>>>>
> >>>>>But when I started tuning channels with dvbscan (took head version of
> >>>>>dvb-apps from the cvs)
> >>>>>new drivers were pretty bad for finding channels.
> >>>>>I tested multible times and depending from the attempt results varied
> >>>>>
> >>>>>
> >>>>>from 0 found channel to maximum in 35 channels.
> >>>>
> >>>>Could you try adding the line
> >>>>       mdelay(50);
> >>>>
> >>>>to the end of ves1820_set_parameters() in the refactored drivers and
> >>>> let me know if it helps?
> >>>
> >>>Forget that - just try the latest FE_REFACTORING CVS and let me know how
> >>>it goes.
> >>>
> >>>Thanks for testing + reporting the problem BTW!
> >>
> >>No problem, I just wish I could also be able to help in coding...
> >>Anyway, it took me a couple of days to test because I was away for the
> >>weekend.
> >>Tuning in FE_REFACTORING branch has now improved a little but it is
> >>still not as good as compared to the
> >>drivers in the HEAD. Now 44-59 channels were found. (Head founds always
> >> 77)
> >>
> >>Is there any simple timeout parameter I could try to change from the
> >>drivers for testing?
> >>Log from the last attempt is below.
> >
> >Yeah - set "dvb_override_tune_delay" on dvb-core - its the delay between
> >successive tuning retries in milliseconds - ves1820 is set to 50ms right
> > now - maybe increasing it will help.
> >
> >I'll have a look through the code later. ves1820 was one of the trickier
> > ones to refactor, so I'm not surprised its caused problems.
>
> Yes, increase of it helped. I first increased it to 100 ms and drivers
> found 77 channels.
> Then I increased delay even more to 200 ms and in the first run drivers
> were able found 92 channels!
> In the second and third run with 200 ms delay, the amount of found
> channels dropped to 77.
>
> Below is my log with the 92 channels found. Even then the tuning is not
> able to found channels
> from the 162000000 hz, but anyway now it atleast seems to try... Is
> there any other method I could try
> for getting channels from 162000000 hz to be found? Would it help to
> change the inversion value somehow from auto to off?
>
> (If I remember correctly, I needed to put inversion off in the windows
> side in order to tune channels)

Urgh! I've just noticed that theres a software auto-inversion hack in ves1820 
which will be interfering with the general dvb support for doing that. I've 
removed it from FE_REFACTORING now.

> Can long cable effect more to channels available in the low frequency
> than for the channels available in the higher frequenzies?

Hmmm - not sure - not used DVB-C at all.




Home | Main Index | Thread Index