[linux-dvb] Improving recovery in the frontend tuning thread
js at linuxtv.org
Mon Sep 5 12:13:16 CEST 2005
On Fri, Sep 02, 2005 Jon Burgess wrote:
> While reading through the frontend tuning thread code I noticed that the
> algorithm in update_delay() looks wrong. The code doesn't have any
> comments in it to indicate what it is intended to do, but the way I read
> it, the intention is to slow down the scanning if we've recently locked
> and make it faster when we've not locked for a while.
> The code does the right thing if the quality level is > 128, by
> returning an increasing delay as the quality increases (i.e. more delay
> when we are locked most of the time).
> What I think is wrong is that as the quality goes below 128 the delay
> also starts to increase! This is because q2 goes negative and so q2*q2
> is positive and increases as quality goes to zero. If we never get a
> lock then the delay is just as long as if we have a near perfect lock.
> I reckon the behaviour needs to be adjusted as per this patch so that
> the code returns "min_delay" for all values of quality < 128. It should
> help recover more quickly if the signal has been unlocked for a long time.
> Does this make things better?
> Or is the large delay when the quality is near zero intentional?
Good question. I guess that if you have a really bad signal you want to
slow down the zig-zag scan. What this piece of uncommented voodoo code
seems to do is to start a zig-zag scan fast, and if no signal is found,
get slower and slower.
Makes sense to me, don't you think so?
More information about the linux-dvb