jlacvdr wrote:
> 2007/10/9, Manu Abraham <abraham.manu@xxxxxxxxx>:
>> jlacvdr wrote:
>>> I rewrote a part of stb0899_dvbs2_algo( ) to remove duplicate source
>>> code and to get a source code more readable.
>>> I added also re-initialization of some registers.
>>> The result is a lower probability to don't obtain the lock.
>>>
>>> I tested on TT-s2 3200 and on Knc1 dvb-s2 plus.
>>> It must work on other cards, the patch touch only stb0899 part.
>>>
>>> I don't remember the time duration to lock, but if you want I can measure it.
>>>
>>> The aim of this patch, it's obtain the lock all the time.
>>>
>>> Regards,
>>>
>> I doubt whether there is a problem in acquiring LOCK on the KNC1, Satelco and the TT cards.
>
> without the patch, I can't lock all the time, and it's seems that
> other persons have the same problem.
>
Some cards, yes. What transponder where you trying to tune with KNC1 card and having issues ?
>
>> Julian, Marco can you guys please confirm ?
>>
>>
>>
>> Let me walk through your patch ....
>> (I feel something wrong in the patch)
>>
>>
>> --- linux/drivers/media/dvb/frontends/stb0899_algo.c.org 2007-10-08 21:25:09.000000000 +0200
>> +++ linux/drivers/media/dvb/frontends/stb0899_algo.c 2007-10-08 21:25:06.000000000 +0200
>> @@ -1351,7 +1351,17 @@
>>
>> s32 offsetfreq, searchTime, FecLockTime, pilots, iqSpectrum;
>> int i = 0;
>> + int cpt = 0;
>> u32 reg, csm1;
>> + s32 retry = 0;
>> +
>> +
>> + reg = STB0899_READ_S2REG( STB0899_S2DEMOD, DMD_CNTRL2 );
>> + STB0899_SETFIELD_VAL( SPECTRUM_INVERT, reg, 1 );
>> + stb0899_write_s2reg( state, STB0899_S2DEMOD, STB0899_BASE_DMD_CNTRL2, STB0899_OFF0_DMD_CNTRL2, reg );
>>
>>
>>
>> Why do you forcefully invert the I/Q inputs ? Different hardware have different configurations.
>
> yes, there are different hardware configurations, so with this patch
> the algo find automatically the good configuration.
> This is an initialiation, I begin with a I/Q configuration, if failure
> the configuration is inverted.
Q) Does it work for you, if you started with SWAP_OFF, rather than SWAP_ON,
retaining your logic. Or do you see any other issues/degradation when you change
the initial INVERSION state ?
Currently there will be a case of inversion in your logic, but for the hardware that we
have and given the networks, the chances of finding an inversion is much less. Can
you please check whether INVERSION_OFF in the initial case does work better still, if
not worser ?
>>
>> +
>> + do
>> + {
>>
>> if (internal->srate <= 2000000) {
>> searchTime = 5000; /* 5000 ms max time to lock UWP and CSM, SYMB <= 2Mbs */
>> @@ -1381,9 +1391,16 @@
>> STB0899_SETFIELD_VAL(FRESRS, reg, 1);
>> stb0899_write_reg(state, STB0899_TSTRES, reg);
>>
>> + reg = STB0899_READ_S2REG( STB0899_S2DEMOD, CRL_NOM_FREQ );
>> + STB0899_SETFIELD_VAL( CRL_NOM_FREQ, reg, 0xd0 );
>> + stb0899_write_s2reg( state, STB0899_S2DEMOD, STB0899_BASE_CRL_NOM_FREQ, STB0899_OFF0_CRL_NOM_FREQ, 0xd0 );
>> +
>>
>>
>>
>> You read Nominal Frequency into "reg", set 208 Hz into "reg", ignore reg ..
>> After which you forcefully enter 208 Hz into the Complex mixer straight away.
>> Even if you required to reprogram the mixer to 208 Hz, i don't see then why
>> do you need the Complex mixer current setting as a part of the Carrier Recovery ?
>>
>> But, i don't see this "magic frequency" in any of the specs from STM.
>>
>> Although one question i have, irrespective to your patch, does setting the
>> Complex Mixer to "0" Hz (30 bit unsigned) help in your case, as applicable to you ?
>>
>>
>
> Before starting acquisition, I restore the initial conditions.
> The 208 is the initial value of nominal frequency in CRL_NOM_FREQ
> register. (can be found is the datasheet)
Ok. reasonable, missed that one. Thanks for pointing it out. Will test it out, but
please do see the first question that i raised.
Manu
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
