[linux-dvb] Some thoughts and questions

[Manu Abraham]

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