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...
[...]
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...)
Hello,
we should not forget the AFC funktion of the frontends in this case. Most
frondends have an acqusition range up to +-12% of Symbolrate, and the older
ves1893 up to symbolrate/2. So all things we do to alter the frequency
(zigzag, bending, drift-offset) could be corrected internaly by the
frontend. So we get some funny sideband effects at the moment, eg. run into
the wrong transponder during zigzag scan (reported by Klaus some weeks
bevor).
So i think the best way is to disable the AFC (if possible), so we could do
all things by the driver.