From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: handygewinnspiel@gmx.de
Cc: linux-media@vger.kernel.org
Subject: Re: [w_scan PATCH] Add Brazil support on w_scan
Date: Mon, 28 Mar 2011 15:46:39 -0300 [thread overview]
Message-ID: <4D90D78F.7050308@redhat.com> (raw)
In-Reply-To: <20110328172045.64750@gmx.net>
Em 28-03-2011 14:20, handygewinnspiel@gmx.de escreveu:
> Hi Mauro,
>
>> This patch adds support for both ISDB-T and DVB-C @6MHz used in
>> Brazil, and adds a new bit rate of 5.2170 MSymbol/s, found on QAM256
>> transmissions at some Brazilian cable operators.
>
> Good. :)
>
>> While here, fix compilation with kernels 2.6.39 and later, where the
>> old V4L1 API were removed (so, linux/videodev.h doesn't exist anymore).
>> This is needed to compile it on Fedora 15 beta.
>
> videodev.h should have never been in there. Was already reported and will be removed instead.
>
>> @@ -1985,6 +1986,10 @@
>> dvbc_symbolrate_min=dvbc_symbolrate_max=0;
>> break;
>> case FE_QAM:
>> + // 6MHz DVB-C uses lower symbol rates
>> + if (freq_step(channel, this_channellist) == 6000000) {
>> + dvbc_symbolrate_min=dvbc_symbolrate_max=17;
>> + }
>> break;
>> case FE_QPSK:
>> // channel means here: transponder,
>
> This one causes me headache, because this one has side-effects to all other DVB-C cases using 6MHz bandwidth.
> Are there *any cases* around, where some country may use DVB-C with symbolrates other than 5.217Mbit/s?
If you take a look at EN 300 429[1], The DVB-C roll-off factor (alpha) is defined as 0.15.
[1] EN 300 429 V1.2.1 (1998-04), chapter 9, page 16, and table B.1
So, the amount of the needed bandwidth (e. g. the Nyquist cut-off frequency) is given by:
Bw = Symbol_rate * (1 + 0.15)
E. g. the maximum symbol rate is given by:
Symbol_rate(6MHz) = 6000000/1.15 = 5217391.30434782608695652173
Symbol_rate(7MHz) = 7000000/1.15 = 6086956.52173913043478260869
Symbol_rate(8MHz) = 8000000/1.15 = 6956521.73913043478260869565
As you see, for Countries using 6MHz bandwidth, the maximum value is about 5.127 Mbauds.
With the current w_scan logic of assuming 6.9 or 6.875 Mbauds by default for DVB-C,
w_scan will never find any channel, if the channel bandwidth fits into a 6MHz (or 7MHz)
channel spacing.
So, the above change won't cause regressions, although it could be improved.
IMHO, a different logic could be used instead, if the user doesn't use the -S parameter, like:
int dvbc_symbolrate[] = {
7000000,
6956500, /* Max Symbol rate for 8 MHz channel bandwidth */
6956000,
6952000,
6950000,
6900000,
6875000,
6811000,
6790000,
6250000,
6111000,
/* Weird: I would expect 6086 or 6086.5 here, as the max rate for 7MHz spacing */
5900000, /* Require at least 7 MHz channel bandwidth */
5483000,
5217000, /* Max Symbol rate for 6 MHz channel bandwidth */
5156000,
5000000,
4000000,
3450000,
};
for (i = 0; i < ARRAY_SIZE(dvbc_symbolrate)) {
if (freq_step(channel, this_channellist) / 1.15 > dvbc_symbolrate[i])
next;
/* Scan channel */
...
}
Btw, this looks weird to me:
static int dvbc_symbolrate(int index)
{
switch(index) {
...
case 11: return 7000000;
...
While it might work, the amount of bandwidth is 8.050 MHz. Yet, as tuner low-pass filter
will probably not attenuate too much the extra 50kHz, I don't doubt that someone would
be tempted to use this rate, but probably some boards will have troubles with that.
> I know that for Europe there are many cases where low symbolrates are used, even if higher would be possible.
>
> If there are any doubts, i would prefer a solution like this and add all countries know to use this srate:
>
> dvbc_symbolrate_min=dvbc_symbolrate_max=0;
> break;
> case FE_QAM:
> + // 6MHz DVB-C uses lower symbol rates
> + switch (this_channellist) {
> + case DVBC_BR:
> + dvbc_symbolrate_min=dvbc_symbolrate_max=17;
> + break;
> + default:;
> + }
> break;
Yeah, this would work for Brazil, provided that we won't find any other operator
here using a Symbol rate bellow the maximum allowed.
> case FE_QPSK:
> // channel means here: transponder,
>
>
> I need an valid answer which solution is better to accept this patch.
>
> cheers,
> Winfried
next prev parent reply other threads:[~2011-03-28 18:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-28 14:29 [w_scan PATCH] Add Brazil support on w_scan Mauro Carvalho Chehab
2011-03-28 17:20 ` handygewinnspiel
2011-03-28 18:46 ` Mauro Carvalho Chehab [this message]
2011-03-29 20:11 ` handygewinnspiel
2011-03-29 23:21 ` Mauro Carvalho Chehab
2011-03-31 10:45 ` Mauro Carvalho Chehab
2011-03-31 17:15 ` handygewinnspiel
2011-03-31 19:50 ` Mauro Carvalho Chehab
2011-03-31 19:52 ` Mauro Carvalho Chehab
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=4D90D78F.7050308@redhat.com \
--to=mchehab@redhat.com \
--cc=handygewinnspiel@gmx.de \
--cc=linux-media@vger.kernel.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