No subject


Wed Aug 29 02:32:41 CEST 2007


and hence found it not usable. But it does resemble some aspects, but not all.


>> But what you said initially is different from what you are saying now.
> 
> How so? I just added more detail for clarification, it doesn't
> contradict what I said earlier.
> 
>> This zigzag method what STM generally use is called Fs/2 zigzag.
>> ie the zigzag is based on the sampling frequency, 
>> ie optimized for the sampling at the nyquist rate, since the most important
>> part in a demodulator is the ADC clock, to put it short.
> 
> Which is just a more complicated wy of saying "derived from the demod's
> carrier capture range", right?

All methods are based on the capture range directly. But doesn't mean that they are the same.
a = f(b) doesn't mean that a = b

>>> Why do you still try to single out stv0299 when I told you
>>> that almost all existing DVB-S frontends use it?
>>> (cx24116 being the one exception, as Georg Acher informed me.)
>>
>> Intel CE6313 is different, Fujitsu MB86A15/16 is different, CX24123 is different, and many others
>> The dst based one's are different.
> 
> You can probably find more examples if you try hard enough, but just
> grep the code for "get_tune_settings" to see the current state
> of affairs (note that dvb_frontend.c enables zig-zag using default
> values for frontends which don't implement get_tune_settings).

Will take a look at that approach.


>> The CX24116 has it's roots from the CX24123 demod, just like how the STB0899  has some roots
>> in the STV0299.
>>
>> The reason is that they do not simply zigzag. The MB86A15/6 from Fujitsu for example sweeps
>> the spectrum, not zigzag's. Different methods, that's all
>>
>> I am not just stating something stupid, but referring quite a lot of demodulator specifications.
>> Not just one STV0299 or CX24116
>>
>> For a person writing a driver for the first time, that device always different.
>> Look at XC3028 as an example
>>
>> So the only common one's are the one's from STM. I am not trying to single out the STV0299,
>> but i was looking at why there is a drastic difference in LOCK/tune times with the STB0899 and the
>> STV0299, while the STB0899 what i am using is in STV0299 tuning algorithm compatible way.
> 
> Well, there are serveral years of development between stv0299 and
> stb0899, one would hope they used the time to improve their
> algorithms. And the stb0899 runs at higher clock rates and has

The STB0899 runs at 90MHz in DVB-S mode, not much different. The DVB-S tuning algorithm is mostly the same,
but there is an additional mode where you can use a STB0899 specific mode of tuning as well.

I am using the STV0299 compat mode of operation. The other one is a bit more faster though,
but initially for me to get it going was more important than speed, but i found that even in the
compatibility mode it worked damn fast.

> more processing power. And the tuner and the whole electrical
> design of the card matters, etc. pp.
> I haven't used SAT equipment for serveral years now, I don't
> remember the stv0299 based FF cards we had at convergence
> as being slow. What card do you use for comparison?

I used a B2C2 skystar. (that was the only one where i had a normal STV0299 based on it.)
The only other one i had was a Galaxis FF card, but the ghost went out of it.

The VP-1030A (dst) uses the Fs/2 zigzag for the STV0299 on board which is implemented in firmware,
rather than in the driver.

> Did you do timing measurements?

The same implementation i haven't tried on the STV0299 driver. But based on the driver in
the x86 class CPU on the dst it looked like it was tuning faster.

I will try to do it a while later and get in some benchmarks.
 
>> I hope i am not loosing you, in what i am trying to say. 
>>
>> What i am stating is that, there is a derivative of a Fs/2 zigzag in dvb_frontend, which is not a
>> Fs/2 zigzag even, such that it can be adapted for others.
>>
>>  
>>>> Ok, now that i explained the test scenario, how would you prefer LNB drift be provided
>>>> to the frontend ?
>>>>
>>>> The criteria would be thus, that the user be able to specify the drift for his LNB, since
>>>> people have small LO drift values to large LO drift values. ie it is not fixed as it is originally
>>>> thought to be.
>>>>
>>>> Do you think it would be the best if the user specifies the drift ? Or maybe in a user
>>>> specific library, for example the lnb.c that one could be extended further.
>>>>
>>>> What's your opinion ?
>>> Most people have no idea what drift their LNB has, nor should they
>>> ever have to care about it.
>> Hmm ..
>>
>> Then i guess the swzigzag for the STV0299 in dvb_frontend is a bit bogus thing,
>> which has been forced for other devices where it is not even applicable.
> 
> Sorry, I can't follow that conclusion.
> 
> The guys who implemented dvb_frontend noticed that all the vendor's
> "tuning algorithm" flow charts looked similar, and factored out common
> code into dvb-core to simplify the individual demod drivers.

never mind, it looks different (to me). Maybe it is that it doesn't look like that to me.
Maybe it's just that i am seeing it in a different light, dunno.

> There's certainly room to improve and extend dvb_frontend, but
> why are you opposed to keep common code which _works_ for a variety
> of frontends?

I am not opposed to that, but i am not seeing the common factor in there, since
there looks like some differences, but i can't really make out how i can plug it in
there. Probably if i tried that, it might've broken the swzigzag and hence took a
different approach of implementing in the driver, where it could be useful later
on for other drivers, which do not do a zigzag either.
ie even devices that even do not share a common approach


Manu



More information about the linux-dvb mailing list