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

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

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

Sounds good to me.

I did some tests in that direction, using a change in fe->parameters.frequency
to detect a channel change in dvb_frontend_thread():

--- dvb_frontend.c.001  Fri Aug  1 14:02:05 2003
+++ dvb_frontend.c      Fri Aug  1 17:31:21 2003
@@ -243,10 +243,15 @@
        memcpy (&e->parameters, &fe->parameters, 
                sizeof (struct dvb_frontend_parameters));
 
-       if (status & FE_HAS_LOCK)
+       if (status & FE_HAS_LOCK) {
                dvb_frontend_internal_ioctl (&fe->frontend,
                                             FE_GET_FRONTEND,
                                             &e->parameters);
+               printk("AFC: f=%d, f_is=%d, offset=%d\n",
+                               fe->parameters.frequency,
+                               e->parameters.frequency,
+                               fe->parameters.frequency - e->parameters.frequency);
+       }
        events->eventw = wp;
 
        up (&events->sem);
@@ -440,6 +445,8 @@
        struct dvb_frontend_data *fe = (struct dvb_frontend_data *) data;
        int quality = 0, delay = 3*HZ;
        fe_status_t s;
+        int hadLock = 0;//XXX
+        int oldFrequency = 0;
 
        dprintk ("%s\n", __FUNCTION__);
 
@@ -478,17 +485,25 @@
 
                s &= ~FE_TIMEDOUT;
 
+                if (fe->parameters.frequency != oldFrequency) {
+                   oldFrequency = fe->parameters.frequency;
+                   hadLock = 0;
+                   }
                if (s & FE_HAS_LOCK) {
                        fe->timeout_count = 0;
                        fe->lost_sync_count = 0;
+                        hadLock = 1;
                } else {
                        fe->lost_sync_count++;
                        if (!(fe->info->caps & FE_CAN_CLEAN_SETUP))
                                if (fe->lost_sync_count < 10) {
+                                        printk("dvb_frontend_internal_ioctl\n");//XXX
+                                        if (!hadLock)
                                        dvb_frontend_internal_ioctl(&fe->frontend,
                                                                    FE_RESET, NULL);
                                        continue;
                                }
+                        hadLock = 0;
                        dvb_frontend_recover (fe);
                        delay = HZ/5;
                        if (jiffies - fe->lost_sync_jiffies > TIMEOUT) {

This is just an ugly hack to be used for testing, but with this I get
fast transponder switching and no more glitches :-)

> I'll whip up a patch to test this.

I'm sure you'll find a cleaner solution to detect the channel change ;-)

Klaus


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