[linux-dvb] Lost lock problems over extended periods of time

[Manu Abraham]

Andrew de Quincey wrote:
> On Tuesday 07 June 2005 18:24, Manu Abraham wrote:
>>Andrew de Quincey wrote:
>>>On Tuesday 07 June 2005 17:32, Andrew de Quincey wrote:
>>>>>>>The periods used to vary, don't know what exactly caused them to vary
>>>>>>>either. The variations used to happen something like what you said 10
>>>>>>>~ 12 hours or sometime it was 48 hours. But 72 hours seemed the
>>>>>>>maximum that it would go many times.
>>>>>>Interesting - thats exactly it.. so its across completely different
>>>>>>card architectures!? (I assume you're still talking about the twinhan
>>>>>>cards here)
>>>>>Exactly.. I am talking about different firmware based ones too FTA and
>>>>>CI based.. different generations too.. Regarding that issue i' am almost
>>>>>tied up in knots... :-(
>>>>>
>>>>>I had a revision AV7110 1.3 card, which was blown when i received itself
>>>>>from Galaxis as a sample given to one of our guys. Even an lspci did not
>>>>>show anything at all, on some motherboards inserting the card into the
>>>>>PCI slot itself would result in a hung BIOS. After that i decided that,
>>>>>i would never again go with one of those FF cards. (eventhough they are
>>>>>the same TT-PCI cards remarketed)
>>>>>
>>>>>That was the time i first started up with DVB, and in this region could
>>>>>not see any other hardware other than Twinhan and got my first card as
>>>>>well as suggested for many others as well as my company too. But the
>>>>>biggest problem their was drivers, whether be it Windows or Linux. well
>>>>>you know the rest..
>>>>OK, my hack doesn't help. I used the following patch in dvb_frontend.c:
>>>>Index: dvb_frontend.c
>>>>===================================================================
>>>>RCS
>>>>file:
>>>>/cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/dvb-core/dvb_frontend.c,v
>>>>retrieving revision 1.96
>>>>diff -a -u -r1.96 dvb_frontend.c
>>>>--- dvb_frontend.c      17 Nov 2004 14:30:33 -0000      1.96
>>>>+++ dvb_frontend.c      7 Jun 2005 16:29:35 -0000
>>>>@@ -507,9 +507,10 @@
>>>>                       else {
>>>>                               /* if we _WERE_ tuned, but now don't have
>>>>a lock,
>>>>                                * need to zigzag */
>>>>-                               fe->state = FESTATE_ZIGZAG_FAST;
>>>>-                               fe->started_auto_step = fe->auto_step;
>>>>-                               check_wrapped = 0;
>>>>+                               fe->state = FESTATE_RETUNE;
>>>>+                               dvb_frontend_init (fe);
>>>>+                               printk("DVB: LOST LOCK - attempting
>>>>retune\n");
>>>>+                          continue;
>>>>                       }
>>>>               }
>>>>
>>>>But, it just sits there printing "DVB LOST LOCK". Of course when I retune
>>>>it works perfectly! This time, it only took about 30 mins to lose the
>>>>lock though.
>>>Just a thought - could it be the DiSEQC? I'm just using simple
>>>tone/voltage control myself. Do all these cards use the same LNB chip on
>>>them? The DVB-S stv0299 ones I have here all seem to use an LNBP16A chip.
>>Twinhan has a STV0299 based tuner on quite a few of the cards.. but no
>>LNBP16..
>>
>>I don't think it is the DiSEqC, since the DiSEqC never worked properly
>>on the Twinhan until recently.. But when it started working some other
>>problems also came up..
>>
>>What i was wondering (a wild thought) was that, is something disturbing
>>the frontend settings once it is set up ? That was the only way that a
>>lock could be lost on the Twinhan cards, since i cannot logically think
>>of any other reason that's what written to a register is lost. But
>>that's too wild a thought.
> 
> That is sort of what I was thinking in desperation and my first hack :) The 
> only thing it didn't do is set the tone/voltage settings again - which may 
> explain why the first hack didn't retune - thats what I'm trying now - a 
> combination of set tone/voltage plus reset & FE settings.
> 

But i was thinking whether we would treating the symptom in that case ..
I was wondering why the lock goes off at all in the first case ..

>>Dominique had a similar problem, but that was triggered off at a certain
>>period of time nearing midnight on TPS, but could be something else
>>too... Maybe he can test the same on the Twinhan DST-CI and see what's
>>the effect..
> 
> That is very weird. The problem I have is definitely not something weird being 
> transmitted - other sites with the same channels from the same satellite 
> don't die at the same time. Most don't die at all.
>

These two are not related at all.. But there is one problem in which my 
wild thought also related way in some way (?) ... The MCU crashes when a 
wrong command is sent .. When this incident happened, the MCU also 
crashed.. The MCU does not crash on any bad signal is what i 
believe/understand, but i might be wrong here..

To get the card up and functioning a reload of modules was necessary. 
that's what i remember..

> Unless of course it is some inteference at the sites with the problem, but I 
> think that is unlikely really.
> 

That's what i too thought.. Then i thought about some IRQ problems, 
which turned out to be negative too ..


Manu