Manu Abraham wrote: > Hi Oliver, > > Oliver Endriss wrote: >> Hi, >> >> Manu Abraham wrote: >>> Hi Hartmut, >>> >>> Hartmut Hackmann wrote: >>> >>>> This might be right! I could not get good information regarding the >>>> transponder bandwidths. We might need to make this depend on the >>>> symbol rate or a module parameter. >>> You can calculate the tuner bandwidth from the transponder symbol rate >>> (in Mbaud) for DVB-S: >>> >>> BW = (1 + RO) * SR/2 + 5) * 1.3 >> Apparently I need some lessons in signal theory. ;-) >> What does R0 stand for? > > RO stands for Rolloff. This isn't anything big, but just defines the > sharpness of the bandwidth curve. You can think how a filter's bandwidth > would look like, when it is plotted out. This is just a filter > characteristic. > > Normally why you need this is not new. Traditionally for old PLL based > tuners, this used to be in hardware, ie a LC component in the pre > stages, prior to the tuner. > > With the arrival of Silicon Tuners, things do have changed. These things > have been made software configurable. There are advantages and > disadvantages to this. Well, there's so much that can talked about it, > but well let me not make it too long. > > For Broadcast applications, ie all TV signals that we receive RO = 35% > We do have other rolloff as well, but generally the others are not used > in broadcast apps, but for professional purposes. When you have a lower > rolloff, what happens is that the filter is more of a tuned filter and > considered narrower slightly. > > The advantage of a narrower filter is that since the edges fall of > sharply, lesser power is wasted, but brings in the disadvantage that the > spectrum is a bit more congested, but alternatibvely somebody could just > argue as well, you can pack in more into the entire spectrum. > > >> Do we have to select a higher cut-off value to compensate for the LNB >> drift and other stuff like that? > > The "5" in there, is in fact implies +/-5Mhz for the LNB drift (5 Mhz on > either side off the offset. A LNB can drift in either direction at > different periods of the day, depending on the temperature. This drift > can cause an acquisition to fail, or an already acquired LOCK to fail on > a very general note). The drift is standard and is specified in one of > the ETSI specifications, one which i read a while back but don't > remember the specification number. > I just looked at the tuner (TDA8262) datasheet, it says: The internal circuitry performs the Zero-IF quadrature frequency conversion and two in-phase (IP/IN) and two quadrature(QP/QN) output signals can directly be used to feed a Satellite Demodulator and Decoder circuit (SDD). Low pass filter cut-off frequency can be adjusted from 5 MHz to 36 MHz in 32 steps. This allows a large flexibility in the SDD input. 10 gain values are present at output amplifier to compensate cut-off frequency adjustment and single output application. Maybe, the best thing to do is divide the spectrum into 32 parts with the lower end at 5MHz and the upper end at 36Mhz equi-distantly. I don't know why it is done in steps as mentioned in there, but i think it is due to a NCO (Numerically Controlled Oscillator) which has 32 steps. With these different steps, based on the calculation, you can slightly optimize the offset if needed for the ones at the end of the spectrum, from what you calculated out. Also note that, the tuner can do 5 - 36 Mhz, so 45 MSPS will be at the very last block and in the case of almost all silicon tuners will need a bit of care to handle properly, also you might see a higher BER in some cases when the filter cannot be pushed to what extend it needs to be. I took a look at the driver, tda826x.c, just saw how simple that driver looks. No wonder ... Even with the vendors, there are just a few people who can really explain all the aspects. (RF and math can sometimes be considered as drinking and driving on a much lighter aspect, when used "properly", anyone who looks at it, won't understand what's going on and what would happen next, in most cases, unless you are in the same state, where you might tend to be in the same harmonic. Maybe that's why some people claim that beer provides a much higher level of success. ;-) ) The worst part in there is that, like all Silicon tuners, gain also plays a significant part. Normally the vendor provides what gain is required for each step, but the datasheet doesn't seem to specify that any place. Normally the higher gain will be applied to the lower SR, and the lower gain to the higher SR. Maybe you can experiment with the gain distribution with regards to the SR. The reason to have a gain distribution, is to avoid the demodulator getting saturated somehow. The "somehow" part is a bit device specific. There's so much math going on within the demodulator. In fact a demodulator is nothing but a device doing a transform from one domain to the other, as it's core functionality although there are other features too in a demodulator. Additionally, it looks like the VCO needs calibration too .. The calibration helps the VCO to remain within the defined limits, rather than with some unknown offset to a tuned frequency. All of which seems to be missing from the driver. Our drivers are far away from being sub-optimal even. It isn't doing anything what is the bare minimum even. It looks like the driver is a 1:1 register dump from an existing windows driver for a particular frequency, symbol rate and rolloff.. :-( The datasheet is also a bit cryptic. It looks to me, at first glance that the VCO needs to be calibrated for that specific step, wait for that specific VCO comparator settling time, then attempt a tune with the relevant step. This might help to reduce the BER as seen by the demodulator, what i saw in another post by somebody else. Well it is not easy too, but far from it. .. So can't blame anyone for it. Also with all this done, it needs some tinkering practically, to reach the best what is possible within the resources available. Regards, Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
