Add Brazil support on w_scan

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.

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.

Hi Mauro,

Quoted 3 lines

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. :)

Quoted 3 lines

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.

w_scan-20110206/scan.c line 1995

Quoted 11 lines

w_scan-20110206/scan.c +4 -0

@@ -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?

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;

case FE_QPSK:
// channel means here: transponder,

I need an valid answer which solution is better to accept this patch.

cheers,
Winfried

Em 28-03-2011 14:20, [email protected] escreveu:

Quoted 6 lines

Hi Mauro,

Quoted 3 lines

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.

Quoted 7 lines

Good. :)

Quoted 3 lines

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.

Quoted 14 lines

w_scan-20110206/scan.c line 1995

Quoted 12 lines

w_scan-20110206/scan.c +4 -0

@@ -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.

Quoted 1 line

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 */

...
}

Quoted 56 lines

Em 28-03-2011 14:20, [email protected] escreveu:

Quoted 6 lines

Hi Mauro,

Quoted 3 lines

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.

Quoted 7 lines

Good. :)

Quoted 3 lines

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.

Quoted 14 lines

w_scan-20110206/scan.c line 1995

Quoted 12 lines

w_scan-20110206/scan.c +4 -0

@@ -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.

Quoted 1 line

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.

Quoted 2 lines

So, the above change won't cause regressions, although it could be improved.

If w_scan assumes that every 6MHz cable network, also outside Brazil, will use it's maximum theoretical symbol rate *only* like your patch was implemented, it will probably fail as well, because in practice lower values are used.

Your patch disabled the looping through different symbol rates for any 6MHz network; therefore i was asking.

So I changed it now to scan any srate for 6MHz networks, but skip over those which are unsupported by bandwidth limitation.

Quoted 35 lines

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;

Quoted 4 lines

	/* Scan channel */

...
}

Doesnt look reasonable, since every DVB-C scan would take easily several hours this way.

Sorting into groups makes sense, one per bandwidth, but with the widely used first for each group is better. And still limit to common used srates -> done.

So, it's included now, but i changed the whole stuff a little.

Em 29-03-2011 17:11, [email protected] escreveu:

Quoted 1 line

So I changed it now to scan any srate for 6MHz networks, but skip over those which are unsupported by bandwidth limitation.

Anyway, I'll test the today's version and reply if I detect any troubles on it.

Em 29-03-2011 20:21, Mauro Carvalho Chehab escreveu:

Quoted 2 lines

Em 29-03-2011 17:11, [email protected] escreveu:

Quoted 1 line

So I changed it now to scan any srate for 6MHz networks, but skip over

those which are unsupported by bandwidth limitation.
...

Quoted 1 line

Anyway, I'll test the today's version and reply if I detect any troubles

on it.

Test results:

	$ ./w_scan -c BR -fc 
Took about 30 mins for scan. As the board I'm using doesn't support
QAM_AUTO
for DVB-C, it seek only QAM_64

Quoted 7 lines

Em 29-03-2011 20:21, Mauro Carvalho Chehab escreveu:

Quoted 2 lines

Em 29-03-2011 17:11, [email protected] escreveu:

Quoted 1 line

So I changed it now to scan any srate for 6MHz networks, but skip over

those which are unsupported by bandwidth limitation.
...

Quoted 1 line

Anyway, I'll test the today's version and reply if I detect any troubles

Quoted 8 lines

on it.

Test results:

	$ ./w_scan -c BR -fc 
Took about 30 mins for scan. As the board I'm using doesn't support
QAM_AUTO
for DVB-C, it seek only QAM_64

This is unexpected && should be fixed to fit to w_scan's default behaviour: first QAM_64, then QAM_256.

Can you pls re-check with the following change in countries.c line 500ff

/*
* start/stop values for dvbc qam loop
* 0 == QAM_64, 1 == QAM_256, 2 == QAM_128
*/
int dvbc_qam_max(int channel, int channellist) {

switch(channellist) {
       case DVBC_FI:    return 2; //QAM128
+      case DVBC_BR:
       case DVBC_FR:
       case DVBC_QAM:   return 1; //QAM256
       default:         return 0; //no qam loop
       }
}

int dvbc_qam_min(int channel, int channellist) {
switch(channellist) {
case DVBC_FI:
+ case DVBC_BR:
case DVBC_FR:
case DVBC_QAM: return 0; //QAM64
default: return 0; //no qam loop
}
}

I don't think that adding QAM_128 makes sense.

Later, if i have more reports from 6MHz network users, i will reduce the number of symbol rates.

Em 31-03-2011 14:15, [email protected] escreveu:

Quoted 44 lines

Quoted 7 lines

Em 29-03-2011 20:21, Mauro Carvalho Chehab escreveu:

Quoted 2 lines

Em 29-03-2011 17:11, [email protected] escreveu:

Quoted 1 line

So I changed it now to scan any srate for 6MHz networks, but skip over

those which are unsupported by bandwidth limitation.
...

Quoted 1 line

Anyway, I'll test the today's version and reply if I detect any troubles

Quoted 8 lines

on it.

Test results:

	$ ./w_scan -c BR -fc 
Took about 30 mins for scan. As the board I'm using doesn't support
QAM_AUTO
for DVB-C, it seek only QAM_64

This is unexpected && should be fixed to fit to w_scan's default behaviour: first QAM_64, then QAM_256.

Can you pls re-check with the following change in countries.c line 500ff

/*
* start/stop values for dvbc qam loop
* 0 == QAM_64, 1 == QAM_256, 2 == QAM_128
*/
int dvbc_qam_max(int channel, int channellist) {

switch(channellist) {
       case DVBC_FI:    return 2; //QAM128
+      case DVBC_BR:
       case DVBC_FR:
       case DVBC_QAM:   return 1; //QAM256
       default:         return 0; //no qam loop
       }
}

int dvbc_qam_min(int channel, int channellist) {
switch(channellist) {
case DVBC_FI:
+ case DVBC_BR:
case DVBC_FR:
case DVBC_QAM: return 0; //QAM64
default: return 0; //no qam loop
}
}