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

[lamikr <lamikr@cc.jyu.fi>]

Andrew de Quincey wrote:

> 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.
>  
Hi

First it tuned pretty badly. (Only 30 channels or so found) but after 
that I added the mdelay(200)
command to line 116 of ves1820.c method ves1820_setup_reg0 and it 
started to tune channels very well.
Now it can even find channels from out national tv channel! So maybe the 
mdelay-line should also be added in the
CVS? (mdelay(50) got removed when you removed that hack)

   ves1820_writereg(state, 0x00, reg0 & 0xfe);
   ves1820_writereg(state, 0x00, reg0 | 0x01);
   mdelay(200);                                                      // 
this is the new line!

Is this ms line btw. CPU speed dependent. (Would slow PC's require 
longer delay and faster one shorter?)
I am myself using AMD athlon 1800.

Mika




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