Johannes Stezenbach wrote: > 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? >From what i understood, it didn't resemble Fs/2 zigzag as i explained 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 _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
