Mailing List archive

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

[linux-dvb] Re: dvb_frontend_recover not working



Johannes Stezenbach wrote:
Klaus Schmidinger wrote:

I was looking into why the driver doesn't recover after a loss
of signal (like when pulling the antenna cable for a few seconds)
and found that apparently (at least with DVB-S) it starts a
dvb_frontend_recover() sequence, but aquires a lock at a completely
different frequency, which is some 16MHz off the original transponder.

This is not surprising, because the fe->lnb_drift takes on values
of up to +/-15462 or so, which lets it run into the next transponder
at the same polarization as the current one. So no wonder there is no
more picture then, because the PIDs may be totally different on different
transponders.

I therefore limited the range of fe->lnb_drift in dvb_frontend_recover()
to some 8MHz,
When we asked for typical LNB drift values on this list a few years ago some people reported LNB drifts up to 9MHz. This is probably the worst-case value for a stone-old LNBs but that's what was used in these days.

Using today's hardware all this voodoo is not required anymore at all, the current demods have AFC search algorithms covering a range that is wide enough - all this code is legacy stuff for old hardware and has not been touched for a long time.

Well, it seems the calculation of the stepsize is wrong. The idea
was to limit the search to the range covered by the bandwidth of
the transponder. But given the variable name "lnb_drift", this
approach is wrong right from the start, because the drift (plus an
offset due to unprecise manufacturing/calibration) is independent
from the bandwidth/symbolrate. We might be better off using a
fixed value for stepsize so the scan covers, say, +/-4 MHz.
This approach was taken over from the old 0.9.4 driver code, but you're right. Don't know which exact drift value is good - as said above the discussion a few years agos lead to values that don't solve Klaus' problem.

but then it didn't lock on to any transponder any more.
This is what puzzles me, because the original transponder was perfectly
locked on with fe->lnb_drift==0, and that value is the first one that
gets tried in dvb_frontend_recover(). And since there can (due to the
limitation to 8MHz) be no more other transponder it might lock on to
by mistake, I don't understand why it doesn't lock on to the original
transponder any more. It just loops through the original frequency
+/-8MHz in 32 steps over and over again.

There's an #if 0'ed part in dvb_frontend_recover(). I guess
some frontends need the call to:
  dvb_frontend_internal_ioctl (&fe->frontend, FE_INIT, NULL);
some (old) demods hang then and when and need to get reinitialized under some circumstances. The original idea was to assume that the demod is crashed when it's not possible to lock after a few zigzag iterations. In this case the additional delay due to initialisation should not matter anyway. Don't remember when this has been disabled and whether this was ever required for demods used on consumer hardware, but since there have not been bug reports regarding this on this list I assume we can safely remove it.

Holger



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



Home | Main Index | Thread Index