Felix Hi,
Felix Domke wrote:
> 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).
Ideally when zigzag is employed, in the end result the offset should be zero or neglible.
In the case of the STB0899, IIRC it is rounded off. So in most cases, you don't have an
offset.
> 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).
Yeah agreed, you are right.
But even then you shouldn't be tuning to the entire bandwidth. But i guess then you are using
the drift to do that calculation in dvb_frontend.c, which is something very much STV0299 specific.
You will be trying to tune to the entire bandwidth in such a case, which would be a bit dependant
on the PLL, afaict. this wouldn't be a problem on ZIF devices, but on simple PLL's this brings in an
additional penality. The penality is imposed on the demodulator and not on the tuner, in such
a case. the result is that improper tuning results, failing to LOCK to vcertain transponders etc.
The point to be noted is that other demodulators using the same parameters is forced to behave
in a STV0299 specific way, which is obviously wrong, as well.
If you look at the STB0899, the DVB-S mode what i use, does the STV0299 compatible way of zig-zag.
> 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.
The STB0899 does exactly the same, but it doesn't need zigzag as defined in dvb_frontend.c
>> 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.
I just asked the question, since it affects other devices in an inverse way.
But this we cannot exactly say each device how it would respond to the same.
Some devices behave very bad. For a long time i tried disabling the swzigzag
for the dst, but then i had to come up with various hacks to get it going.
Also this is specific to DVB-S alone. Rather than saying that, it is much demod specific
i would say, since one of the devices that i have it has a microcontroller/CPU on it to
do the specific zigzag tuning, in a well device optimized way (the demod is still STV0299).
In such a case, i have to just resort to workarounds.
>> 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.
AFAICS, Inversion isn't a part of the transport.
> - Inversion can be caused by tuner-specific wiring (some STV0299-based
> frontends have swapped I/Q inputs)
>
This is correct.
> So you see, sometimes there is no way to know the Inversion setting.
>
When it is just a matter of wiring on the hardware/card, why not do it according
to the hardware rather than trying to do autodetection, by taking up more time ?
The point being, it is just a matter of detecting it one time, whether the specific
hardware has I/Q input swapped or not.
> 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.
Just because some hardware is capable of detecting the inversion, does it mean
that we need to emulate that same mode by doing it in software thereby making
tuning slow on the devices, that cannot do the AUTO mode ?
This is one thing that confuse me.
>> 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).
Didn't think of that case. But in that case it would be a matter of the userspace
telling the driver whether it is negative or positive, ie INVERSION ON or OFF
>> 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.
I use zig-zag in the STB0899, as you can see from the multiproto tree
> And auto-inversion as well. You cannot do those things in userspace,
> because you don't know enough of the frontend.
>
The only case i can think of inversion, from what you added is from the LNB mixer, where
there would be inversion. In this case the userspace does know that there is inversion involved.
In the case of the hardware being wired differently, the driver, from the config struct knows
whether i/Q inputs are swapped or not.
So in either case, we know whether INVERSION exists. My thought goes like this, when we know
INVERSION exists or not, combination of the config struct + userspace LNB information
(eg: we have LNB info in lnb.c in dvb-apps/szap) why do AUTO ? It takes twice the time for a valid LOCK,
just because INVERSION information wasn't taken care of, even when it was available.
Manu
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
