Mailing List archive

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

[linux-dvb] Re: Transponder switching taking considerably longer



Klaus Schmidinger wrote:
> Johannes Stezenbach wrote:
> > 
> > But AFAIK the intention of FE_RESET is to restart the frontend's
> > signal aquisition algorithms. It is also only called in
> > dvb_frontend_thread() when the lock has already been lost.
> > 
> > I guess the problem for you might be that there is a significant
> > frequency offset, but the changed dvb_frontend.c achieves a lock without
> > doing a zig-zag scan, so you get a quick initial lock but the signal
> > is weak. To correct this problem we would have to read the AFC value
> > from the frontend and correct the frequency if the offset is too large.
> > OTOH we've had other problems with AFC in the past...
...
> Aug  1 16:39:59 video kernel: AFC: f=1588000, f_is=1588214, offset=-214
> 
> If you consider +/-700 as small, I guess these aren't too large, either.

Then I don't know why you lose FE_HAS_LOCK, and especially why you
still get a good signal even without FE_HAS_LOCK. It's expected that
FE_RESET will break the signal, but the root cause is a broken
lock indicator from the frontend.

Anyway, we could do the following:
- set a flag before tuning
- in dvb_frontend_thread(): call FE_RESET ony if the flag is set
- reset the flag when we get FE_HAS_LOCK

-> FE_RESET will not be called if FE_HAS_LOCK drops out for short
   periods on an already tuned TP.

I'll whip up a patch to test this.

Johannes


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



Home | Main Index | Thread Index