From: Manu Abraham <abraham.manu@gmail.com>
To: linux-dvb@linuxtv.org
Subject: Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails
Date: Sat, 22 Mar 2008 21:12:59 +0400 [thread overview]
Message-ID: <47E53E1B.5050302@gmail.com> (raw)
In-Reply-To: <200803220711.07186@orion.escape-edv.de>
Hi Oliver,
Oliver Endriss wrote:
> Hi Manu,
>
> Manu Abraham wrote:
>> 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.
>
> Thank you for these detailed explanations. This stuff is sometimes hard
> to understand for someone who only deals with electronics as a hobby.
> ;-)
>
>>>> 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.
>
> Ok, some calculations according your formula
>
>>>>> BW = (1 + RO) * SR/2 + 5) * 1.3
>
> 45 MSPS:
> BW = ((1 + 0.35) * 45/2 + 5) * 1.3 = 46
>
> -> cutoff 36 MHz (maximum value supported)
>
> 27 MSPS:
> BW = ((1 + 0.35) * 27/2 + 5) * 1.3 = 30,2
>
> -> cutoff 31 MHz
>
> 22 MSPS:
> BW = ((1 + 0.35) * 22/2 + 5) * 1.3 = 25,8
>
> -> cutoff 26 MHz
>
> Are these calculations correct, or did I miss something here?
It looks fine, just round it off to the next integer. ie always round it
up, rather than rounding it down. For the cutoff at 36MHz, it is fine as
well, since at the last step, you will not need an offset, since it
would be the last step in the spectrum.
>> 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.
>
> (See table 14 in the datasheet.)
yep
>> 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.
>
> Afaics a simple pre-calculated lookup table with 32 entries should do
> the job. At least for the cut-off frequency.
That's possible, since you need only 32 precomputed entries, rather than
continuous values. That would be much better too, without any runtime
overheads. Just the table needs to be done nice.
>> 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. ;-) )
>
> Ah - now I understand why our drivers work surprisingly well. We ignore
> all math due to lack of support from the vendors, and rely on the
> assumption that the chip designers had enough beer. :-)
lol.
>> 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.. :-(
>
> After reading the comments in the driver, I think this is a valid
> assumption...
>
>> 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.
>
> Obviously there is no public datasheet for the TDA10086,
> and I don't have a TT-1401 card either. :-(
>
> Changeset http://linuxtv.org/hg/v4l-dvb/rev/8a19aa788239 was the result
> of combining patches from the ML, more or less educated guessing and
> some testing done by a user.
>
> I don't know what register 0x02 exactly does. The tests showed that
> value 0x35 was required for reliable tuning, while 0x00 was required to
> redurce BER after establishing the lock...
the register 1x defines 1) reference divider 2) the VCO frequency ratio
The reference divider looks at the step size.
The VCO calibration might make things a bit better, but before starting
to play around with that, i would suggest to check whether the basic
changes themselves help.
What we have here is a generic datasheet for the tuner chip. The step
size, is in fact dictated by external components: Normally an external
tuner manufacturer specifies what step size is ideal for their tuner
implementation, due to external component variations, from the reference
design.
The VCO ratio i don't have a clue exactly, as what it would be doing,
maybe it implies that there is a frequency multiplier/scaler for the
oscillator, don't have a real idea on it, will have a detailed look at
it, when mind is a bit more clear.
Regards,
Manu
_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
next prev parent reply other threads:[~2008-03-22 17:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-14 13:29 [linux-dvb] (no subject) ldvb
2008-03-14 13:33 ` Vladimir Prudnikov
2008-03-14 14:39 ` ldvb
2008-03-14 15:17 ` Vladimir Prudnikov
2008-03-14 15:24 ` [linux-dvb] TT budget S-1401 Horizontal transponder fails ldvb
2008-03-17 10:20 ` [linux-dvb] TDA10086 fails? DiSEqC bad? TT " ldvb
2008-03-18 17:38 ` [linux-dvb] TT-budget S-1401 issues. " ldvb
2008-03-20 0:18 ` [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 " Oliver Endriss
2008-03-20 16:33 ` ldvb
2008-03-20 20:55 ` Hartmut Hackmann
2008-03-20 21:14 ` Manu Abraham
2008-03-20 21:57 ` Hartmut Hackmann
2008-03-21 9:15 ` Oliver Endriss
2008-03-21 15:43 ` Manu Abraham
2008-03-21 16:55 ` Manu Abraham
2008-03-22 6:11 ` Oliver Endriss
2008-03-22 17:12 ` Manu Abraham [this message]
2008-04-10 20:40 ` Oliver Endriss
2008-04-10 23:33 ` hermann pitton
2008-04-11 21:29 ` Oliver Endriss
2008-04-11 23:35 ` hermann pitton
2008-04-11 21:12 ` Hartmut Hackmann
2008-04-11 21:36 ` Oliver Endriss
2008-03-21 18:36 ` Matthias Schwarzott
2008-03-21 20:00 ` Manu Abraham
2008-03-21 20:15 ` Matthias Schwarzott
2008-03-21 20:47 ` Manu Abraham
2008-03-21 23:25 ` Matthias Schwarzott
2008-03-22 1:27 ` Manu Abraham
2008-03-21 10:44 ` ldvb
2008-03-21 8:56 ` Oliver Endriss
2008-03-21 10:56 ` ldvb
2008-03-21 14:25 ` ldvb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47E53E1B.5050302@gmail.com \
--to=abraham.manu@gmail.com \
--cc=linux-dvb@linuxtv.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox