On Sun, Sep 30, 2007, Manu Abraham wrote: > Johannes Stezenbach wrote: > > > > The actual drift is totally irrelevant for the zig-zag scan. > > Zig-zag is a trial-and-error approach, and only needs to know > > - the step size (derived from the demod's carrier capture range) > > - max. the number of steps (derived from channel bandwidth) > > - the time to wait between steps (derived from the demod's > > worst case time to lock on a signal) > > This is what i am doing in the STB0899 driver. You are preaching to the choir. Then why don't you use the dvb-core implementation instead of reimplementing it in the STB0899 driver? > 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? > > 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). > 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 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? Did you do timing measurements? > 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. 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? Johannes _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
