public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
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


  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