Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Spectral Inversion (was Re: Re: patch for scan (-t bitfield select))



Robert Schlabbach writes:
 > From: "Holger Waechtler" <holger@convergence.de>
 > > the modulation point in the complex I/Q plane.
 > 
 > I beg to differ ;) You are correct about I and Q specifying the
 > constellation point, with I being the In-phase amplitude and Q being the
 > quadrature amplitude. But you cannot say one of the differential IF lines
 > carries the I signal and the other carries the Q signal. In fact, you could
 > only use one IF line to carry the signal, with both I and Q in it...

Not after some filtering which usually occurs before and/or inside the
demodulator before the "inversion switch" logic.


 > BTW, I wasn't quite right about the spectral inversion. Here is a good
 > quick explanation of what it is:
 > 
 > http://www.rfcafe.com/references/electrical/spectral_inv.htm
 > 
 > Basically, it means the signal spectrum is "mirrored" around the center
 > frequency: What was originally above the center frequency ends up below it,
 > and vice versa. And this effect happens when the LO (=PLL) frequency in a
 > downconversion is greater than the target frequency - a scenario you have
 > with typical tuners, where you add the IF center frequency to the target
 > frequency.
 > 
 > So to not have a spectral inversion in the tuner, you would have to have a
 > tuner in which you _subtract_ the IF center frequency from the desired
 > target frequency to get the PLL frequency. Do such tuner modules really
 > exist? If not, they *all* spectrally invert the signal...

What about those downconverters with 0 IF?

Anyway, the inversion of the signal inside the tuner and how it
reaches the demodulator is irrelevant. The user space parameter
"inversion" should reflect the property of the signal as it is sent
(or maybe better how it reaches the tuner in case of satellite bands
where the usual LNB LO is above the signal frequency? Are there any?).
The driver should compensate for any internal inversions.

E.g. Eutelsat services are encouraged not to send inverted signals:

http://www.eutelsat.com/satellites/pdf/Diseqc/Reference%20docs/recom_trans_para_broadcasters&operators_DVB_multiplexes_using_EUTELSAT_syst.pdf

The document also mentions that some providers send inverted signals anyway and
the receiver software should be able to handle it.
But most signals should be uninverted.

It also happens that cable providers just switch inversion.
This happened here with the cable provider ISH when they upgraded 
their cable for providing internet. I don't know if there was a technical
reason (new hardware) or just done for the fun of it ...


Ralph


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index