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
