Johannes Stezenbach wrote: > On Sun, Sep 30, 2007 at 03:11:39AM +0400, Manu Abraham wrote: >> Johannes Stezenbach wrote: >>> On Sat, Sep 29, 2007, Manu Abraham wrote: >>>> ... >>> Instead of losing myself in the details of your questions, >>> some background info: >>> >>>> 1) LNB drift >> That said, since we have different LNB LO drifts and the frontend driver doesn't know >> what the actual drift the LO is having, but that only a standard (vague ?) definition of >> the drift, > > > 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) > > Got it _now_? Johannes, This is what i am doing in the STB0899 driver. You are preaching to the choir. But what you said initially is different from what you are saying now. 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. >> i would like to experiment a bit with the stb0899 with regards on the same. >> Since the STB0899 doesn't use the swzigzag from dvb_frontend.c, it is much easier to >> do it in the stb0899 driver. > > dvb_frontend lacks a hook which would allow one to > implement auto-offset correction for the TU1216 DVB-T demod > (I mean the +/- n * 125kHz or +/- n * 166kHz offset from the frequency > given in the NIT used by some transmitters to reduce interference with > adjacent channels.) > > If what you add for stb0899 would be usable for tu1216 etc. it > would be useful. You must not break the exisiting sw zig-zag though. ACK. This would work (search) Will be going this way for some other devices. >> (This is supposing on the basis that we are not fiddling around with the STV0299) > > 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. 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. 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. Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
