[linux-dvb] Re: Another issue: frontend timeout value and lowsymbol rates

[Holger Waechtler <holger@qanu.de>]

Johannes Stezenbach wrote:
> Holger Waechtler wrote:
>
> > Andrew de Quincey wrote:
> >
> > > If there _isn't_ a problem with breaking the Nokia API, I would be glad to 
> > > have a look.
> > > If there is, all I have to do to fix my stuff is ignore the FE_TIMEDOUT 
> > > bit.
> > ;) just remove it, it's bogus anyway.
> > (ough! I already feel the hits of the middleware and application 
> > developers again - for some strange reason they love these funny 
> > meaningless bits;)
>
> We never depended on FE_TIMEDOUT, it was introduced by you when you
> broke the FE event semantics and refused to fix them.
?!?


> > > > My thinking of what the code should do:
> > > >
> > > > - if someone does SEC/DiSEqC stuff, put the frontend thread to
> > > > sleep until the next FE_SET_FRONTEND (the order of FE ioctls
> > > > is undocumented, but this is the only order that makes sense)
> > > > - initial tuning: set frontend paramters, wait for things to settle
> > > > down before querying FE status (time depends on FE HW driver);
> > all the crap in dvb_frontend.[ch] is only to work around the flaws in 
> > ancient hardware, modern demodulators don't need any code from these 
> > files at all - don't spend too much energy there.
>
> "ancient hardware" means 99% of the existing hardware out there...
> I'd be happy to get rid of it, but IMHO we can't.
unfortunally.

I just said that the existing drivers work pretty good in most
environments, so this code is probably better left untouched (or only
carefully touched for bugfixes).

New drivers for well-designe hardware should better not rely on this code.


> > And keep in mind that there is no guaranteed lock time at all in 
> > unstable receiption environments, e.g. with weak DVB-T signals or 
> > signals disturbed by many reflections - the value choosen for a timeout 
> > is always arbitrary.
>
> Some FE data sheets have estimations of worst case signal acquisition
> time.
They are only valid for strong signals.


> But even if you have to determine the useful timeouts
> experimentally, they depend on frontend hardware, so the application
> cannot know them.
You can. The same formulas based on the symbolrate and modulation type
are valid for most frontends, the demodulator's control loop parameters
should not significantly affect the theoretical optimum lock times
unless the hardware is really broken by design.


> And just tell me, it you don't know useful timeout values, how are you
> going to implement zigzag scan at all?  Certainly you have to wait a
> *specific* amount of time before trying the next zigzag step.
like I said, it's a crappy workaround for crappy hardware. For the first
versions of the NEWSTRUCT code zigzagging was removed at all, but there
were at least one DVB-S demod and the finnish cable networks with their
frequency offsets that made it necessairy again.

After all zigzagging is just a desperate last try to make it work and
get a lock when the 'normal operation approach' for well-designed
hardware failed.


> The only sane thing to do is to ask the hw driver "for the values
> set by the last FE_SET_FRONTEND, how long should I wait before trying
> the next zigzag step?"
This would only work if two consecutive tuning approaches use the same
parameter sets, otherwise the theoretically achievable lock times will
differ.


> > > > if it fails, try zigzag, if that fails retry slower
> > > > zigzag, if that fails, report failure
>
> And that is IMHO a useful event to report to the application.
hmm, for what this information is useful? Do you want to display it in
the GUI?

Holger




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