Some thoughts and questions

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

 



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@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux