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 > > - LNBs have a constant error plus a temperature drift > (e.g. +/-1MHz error, +/-3Mhz drift for a temperature range > of -40 ... +60 °C -- cheap no name equipment usually worse) This is the old LNB, the one's we use are generally based on PLL's have some 15 - 20k drift > > - the demod can only compensate for a limited frequency offset > (e.g. both stv0299 and stb0899 QPSK are specced to +/-5% fM_CLK > for "Carrier loop capture range", where fM_CLK is typically > 88MHz for stv0299 and 108MHz for stb0899, thus 4.4 MHz vs. > 5.4 MHz. But note that this are best case figures which only > hold with good CNR.) > > - if the LNB error + drift is higer than what the demod can capture, > then tuning fails even a max of 20k is so small within the actual bandwidth window, for a demod not to lock A demod has a bandwidth of normally 5 - 10 MHz, depending on the device. > - _only when initial tuning fails_ does the sw zig-zag kick in, > and it attempts to tune in increasing steps around the nominal > frequency until the demod either locks on the signal, or > the scanned frequency range covers the complete channel bandwidth > (we want to avoid locking on the neighbour channel; note that > adjacent channels on satellite use different polarization so > we can't lock there unless we really stepped way too far) > > - the parameters for sw zig-zag are provided by the demod driver > in struct dvb_frontend_tune_settings > int min_delay_ms; // when to assume tuning failed -> do next step > int step_size; // size of zig-zag step > int max_drift; // when to stop zig-zagging > > a demod driver can disable sw zig-zag by setting step_size > and max_drift to zero (which is what DVB-T and DVB-C > drivers do) > > - sw zig-zag is by no means stv0299 specific and is used by > (almost?) all DVB-S demod drivers hmm, i didn't mean swzigzag, but as you see from that discussion, it was the drift that i am looking at > The bottom line is that: > > 1. zig-zag doesn't slow down tuning, because it only ever kicks > in when the initial tuning attempt failed > > (however, it is possible that a driver sets min_delay_ms > too small, then zig-zag kicks in too soon and ruins your day) > > 2. zig-zag tries harder to tune, and makes users happy, even > if tuning might take some time; > > without zig-zag, all you can do is tell your user > "sorry, no signal found" My point being to have zigzag specific to the demod, since each device of the devices which implements zigzag does it in a different way. The computation being different > 3. once zig-zag succeeded, the offset (drift compensation) > is stored and reused at the next channel switch -- thus > not every tuning is slowed down even if there is a large offset > > 4. zig-zag could also be implemented in user space, but > IMHO it's better the way it is now -- since some hw doesn't > heed sw zig-zag, and the ones that need it need different > parameters I wasn't meaning to implement it in userspace, it easier as it is within a driver, but as you see different devices does it in different way altogether. What i was suggesting was to move it into the drivers, where it would make life a bit more easier, rather than one device implement a search callback and another implement a set_params. This leads to confusion for a person writing a driver. With regards to the STB0899, it doesn't use the set_frontend call to avoid such a nasty circumstance. A new callback such as search is implemented. > IIRC Andrew de Quincey spent significant time optimizing the > zig-zag code and the parameters for various frontends. > I do remember the time where he spent so much time optimizing the swzigzag for the STV0299. > >> 2) Inversion AUTO > > In the old days there were literally two wires with the I and Q > signals running from the baseband processor to the QPSK modulator. > It probably was a common mistake that someone messed up the wiring at > the broadcaster. Nowadays the equipment is integrated and > the inversion setting is just a check box in the control software. > Still broadcasters seem to set it at random. You have any cases of broadcasters doing it in a non-standard way ? ie inverted transmission ? > Like Felix explained, at the receiver side you don't know if > the spectrum is inverted. If the demod firmware doesn't handle it, > you have to try both inversion settings in sw. And like with zig-zag, > you could do it in userspace but IMHO it's better to let the > core handle it. At the receiver side it is quite fine, we know that we can handle it when the downconversion phase is negative or when the I/Q inputs are connected in an inverted way The only question, being the broadcaster side. Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
