Mailing List archive

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

[linux-dvb] Re: Couple of frontend questions



On Saturday 28 February 2004 14:27, Andrew de Quincey wrote:
> On Friday 27 February 2004 20:19, Oliver Endriss wrote:
> > On Friday 27 February 2004 19:37, Johannes Stezenbach wrote:
> > > Christian Schuld wrote:
> > > > So I vote for a way to disable zigzagging completely, may be via a
> > > > sysfs interface? It would be nice for tuning the zigzigging parameters,
> > > > too.
> > >
> > > sysfs stuff will have to wait until after we branch CVS to
> > > separate 2.6 and 2.4 stuff.
> >
> > Ack.
> >
> > > But it's a good idea to be able to disable zigzag and let
> > > applications do what they want.
> >
> > Ceterum censeo zig-zag scan and bending should be disabled completely. ;-)
> 
> OK, what about a new user-space IOCTL for controlling the frontend tuning 
> parameters on a specific frontend... say FE_SET_PARAMETERS. Currently I'd say 
> it would pass a struct something like the following:
> 
> struct fe_parameters {
>   int enable_bending;
>   int enable_zigzag_tuning;
>   int enable_zigzag_drift;
>   int enable_unlock_on_diseqc;
> }
> 
> The difference between enable_zigzag_tuning and enable_zigzag_drift is that 
> the former zigzag is when an initial lock is being sought, and the latter 
> when the lock is lost, and we're attempting to compensate for LNB drift.
> 
> The new frontend code also automatically "loses" the lock whenever a DISEQC 
> command is sent... I can see that would'nt be great for finetuning a 
> motorised dish controlled by DISEQC, so thats what enable_unlock_on_diseqc 
> controls.
> 
> By default, all of the above would be set on. 

In the past I did some tests and found that tuning is always faster if zig-zag
scan is disabled. So the first thing I do after a check-out is disabling this
cra^Wstuff. -> Never had any problems (QPSK BSRU6, Grundig 29504-451).

IMHO it should be completely removed from the driver, or at least turned-off
by default. If the tuner looses lock, the frontend thread should simply try to
re-tune to the frequency specified. It's not the responsibility of the driver
to find the transponder, if

(a) the user specifies an incorrect frequency
If really required, the application could implement a zig-zag scan and
_permanently_ store the result. No need to do this on every channel switch.

or

(b) the LNB is broken (high LNB drift)
Typically the drift is small and catched by AFC. If you are using several LNBs
(e.g. DiSEqC), every LNB has a different drift. Maybe the drift also varies
depending on the polarizatiion/band selected. If you switch between
different inputs, zig-zag will just slow down tuning. :-(

If someone really likes to use a broken LNB, the LOF settings of the
application (e.g. VDR) can be adjusted to compensate for a constant offset.
This can be done for each input of the DiSEqC switch / band of the LNB,
which should give optimal results.

Sorry, I see _no_ reason, why zig-zag scan should be done in the driver.

Just my 2 cents.

Oliver


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index