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

[Johannes Stezenbach <js@convergence.de>]

Andrew de Quincey wrote:
> 
> Actually, the update_delay() is fine; its just that the TIMEOUT doesn't take 
> into account how long it takes to write to the frontend itself... I put in 
> some instrumentation, and its taking 25 jiffies to call FE_SET_FRONTEND... 
> I've checked the frontend code: no delays or anything.... (I'll check that 
> out again tomorrow in case I missed something).
> 
> I need to know more rationale behind the timeouts in the frontend loop though. 
> Is it meant to do at least one iteration of the zigzag scan when the lock is 
> lost?
> 
> You see it doesn't actually make sense to me as to why the timeout stuff is 
> there at all.. surely if a complete zigzag scan is done, and fails to lock on 
> at any point, it should set FE_TIMEDOUT. Then, if the lock is regained (e.g. 
> the cable is plugged back in), it can clear it again.
> 
> There is no point in setting FE_TIMEDOUT partway through a zigzag scan, 
> because the next attempt in the scan might be the one which works... 
> especially with low symbol rates which are _very_ sensitive to this.
> 
> To my understanding, the additional stuff with the TIMEOUT value is 
> superfluous, and causes problems. If this isn't the case, can you tell me 
> what I'm missing...

Well, the DVB API as specified by Nokia says that FE_SET_FRONTEND
should start tuning, and the result (failure or success) is relayed
to the application by means of an event with FE_GET_EVENT.
I.e. one FE_SET_FRONTEND -> one FE_GET_EVENT. But it's also
possible for the frontend to generate additional events, e.g.
when the cable is unplugged and replugged.

The frontend code should do what it can get a lock, and if that
fails, report the failure. IMHO this is the job of the driver,
because the timeouts depend on the type of frontend (or even
on the frontend making and model).

But Holger thought differently, and said the application should
do its own timeouts, because the driver cannot know how
long it wants to wait before assuming failure. The code
also generated superflous events during tuning. After some
debate he put in the current FE_TIMEDOUT cruft (with an arbitrarily
chosen timeout), which essentially means "your tuning attempt
already timed out, so the following tuning-failed event is
superflous and can be discarded". Or something like this
(I never quite understood it).

It's possible that a frontend reports failure after tuning, and
some time later report a success event (because the zig-zag
scan never gives up).


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);
  if it fails, try zigzag, if that fails retry slower
  zigzag, if that fails, report failure and keep trying with low prio
  and a limited scan range around the given frequency (i.e. wait for
  user to plug in the cable);
  things could be more complicated if one has to do autoprobing for
  inversion etc. in software
- lost signal: there are two possibilities:
    1. cable unplugged or a bird sits on your dish  -> do not zigzag,
       just wait for signal
    2. sun heated up the LNB until the freq drift got too large
       -> zigzag to correct drift
  Obviously there's no way to decide between 1. and 2., so one has
  to try zigzag always. I don't know how likely 2. is in practice.

Also, if one has found a LNB offset during zigzag, it would be the
same for all frequencies. But since one doesn't know whether one
is correcting an LNB offset or whether the frequency given to
FE_SET_FRONTEND was wrong, there is no way to tell -> LNB offset
must be determined from scratch at every zigzag scan. (One could
use a heuristic to retry the last LNB offset for the new freq,
but only if there was no DiSEqC seq which changed the LNB in between,
but I doubt it's worth trying...)


All in all, if you decide to mess with this stuff, be prepared to
invest a lot of time for experiments...


Johannes


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