Hi all,

After quite a lot of eyeballing in dvb_frontend.c, Some thoughts and questions 
that i came
 up with having no answers.

They are such:

1) LNB drift: 
http://linuxtv.org/hg/v4l-dvb/file/4e590391b11f/linux/drivers/media/dvb/dvb-core/dvb_frontend.c


      279               /* calculate the lnb_drift */
      280               fepriv->lnb_drift = fepriv->auto_step * 
fepriv->step_size;
      281 
      282               /* wrap the auto_step if we've exceeded the maximum 
drift */
      283               if (fepriv->lnb_drift > fepriv->max_drift) {
      284                       fepriv->auto_step = 0;
      285                       fepriv->auto_sub_step = 0;
      286                       fepriv->lnb_drift = 0;
      287               }

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.

The reason being LNB drift being attributed to the Noise Temperature and is LNB 
specific
You can't calculate it in anyway.

Currently, only userspace can know about this and this is LNB model specific ! 
Also there is no way how one can tell the frontend driver about it.

My guess is that the person who added this changed confused with PLL step's and 
the channel spacing, natural frequency of the system and hence. Can someone who 
has a more better insight clarify ?

Also interesting is this line

      306                       fepriv->lnb_drift = -fepriv->lnb_drift;

LNB drift going up and down ? Sounds like bad understanding. Thermal runaway on 
LNB's happen in one direction.
 ie, they are not Bidirectional.

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.

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.


2) Inversion AUTO

      273       /* are we using autoinversion? */
      274       autoinversion = ((!(fe->ops.info.caps & FE_CAN_INVERSION_AUTO)) 
&&
      275                        (fepriv->parameters.inversion == 
INVERSION_AUTO));

 
What does Inversion AUTO mean ? As far as i understand Inversion means the I/Q 
inputs swapped. It is either not swapped or not.

What does Auto mean, again ? The driver author doesn't know whether I/Q inputs 
are swapped on the hardware ?
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.

Looking at scan.c, i see the same misunderstanding there as well.

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.

Can someone clarify these two ? 

Thanks,
Manu


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Reply via email to