Mailing List archive

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

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



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.

> 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. But even if you have to determine the useful timeouts
experimentally, they depend on frontend hardware, so the application
cannot know them.

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.

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?"


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


Johannes


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



Home | Main Index | Thread Index