Hi Manu,
> The point here is that the frontend (demodulator + tuner) doesn't know about the LNB drift.
> Also the most important point to be noted is that LNB drift cannot be calculated, but is measured on test criteria.
I think the misunderstanding is that lnb_drift doesn't correlate to any
physical property (like the difference of the LNB local oscillator to
its nominal value), but in fact is the offset between the userspace set
frequency and the real, tuned frequency (after zig-zack scanning).
When locking is finally archived (and only then), lnb_drift will hold
the real "LNB drift" (+Satellite drift +setting file derivation).
> Also interesting is this line
> 306 fepriv->lnb_drift = -fepriv->lnb_drift;
This is part of the zig-zack scan, which, as the name implies, scans up,
then jumps down ...
> As far as i can say, this one line #306, is playing with the derotator on the STV0299. The derotator is present on some of the demodulator's from STM. The derotator is used for Carrier recovery, as far as i can understand. Also most of the datasheets do specify that way.
The derotator on the STV0299 does the final frequency fine-tune. In a
locked state (and possibly before already), it contains the offset
between the PLL frequency and the center carrier frequency. The
derotator shifts the zero-IF signal to really zero (which isn't possible
with the PLL alone, given the relatively huge step size).
However, when the derotator value becomes bigger than the step size, the
offset should feedback into the PLL, because the bandwidth of the AD
conversion is limited. Everything which falls out of the AD bandwidth
(or better, its input filter) is lost, and cannot be recovered by
derotation.
> This is demodulator specific code. I don't understand why such demodulator specific code is part of the core where other devices can't even use it.
My understanding is that the basical concept is the same on every
frontend. Your input PLL ("tuner") is usually not exact enough to not
require a derotator in the demod.
I'm not saying that zig-zack scanning is a good thing, nor saying that
it's a bad thing. It doesn't perform well in all cases, that's true. But
please be very sure to understand the whole problem before trying to
attempt to remove things. I'm not a frontend guy, so please wait for
them to evaluate this topic and possible improvements.
> What does Inversion AUTO mean ? As far as i understand Inversion means the I/Q inputs swapped. It is either not swapped or not.
Again, your misunderstanding is the part of the picture we are looking at.
Inversion=AUTO just means that it's unknown, and the frontend should
autodetect it.
For several reasons, inversion autodetect is/was important. In a perfect
world, we would always know, but:
- Inversion might happen on up- and downconversion, depending on what
frequency situation you have.
- The SatelliteDeliverySystemDescriptor does not specify Inversion.
- Inversion can be caused by tuner-specific wiring (some STV0299-based
frontends have swapped I/Q inputs)
So you see, sometimes there is no way to know the Inversion setting.
Most, even older, demods support automatic inversion detection. I think
the STV0299 is an exception here. Thus the driver tries best to hide
this fact.
> At some point of time, i believed as well the fact that I/Q swap at the modulator (transmitter/satellite side) can cause an Inversion change.
Not only that, it will also be swapped by a frequency inversion, which
happens for example on a C-Band LNB (where the channel frequency is
lower than the local oscillator).
> But as i stand enlightened, i don't think this is right. I just happened to correct someone who asked me the same question, which was a major problem as to get proper tuning time on the STB0899 based cards. The lack of not using these two, the STB0899 tunes and LOCK's quite fast.
Yes, zig-zack needs some improvements. But we definitely need zigzack.
And auto-inversion as well. You cannot do those things in userspace,
because you don't know enough of the frontend.
Felix
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
