Johannes Stezenbach wrote:
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.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,
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.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.
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.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);