Re: [RFCv1] add DTMB support for DVB API

[Antti Palosaari <crope@iki.fi>]

On 12/23/2011 03:38 PM, Andreas Oberritter wrote:
> On 22.12.2011 22:30, Antti Palosaari wrote:
>> @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
>>       GUARD_INTERVAL_1_128,
>>       GUARD_INTERVAL_19_128,
>>       GUARD_INTERVAL_19_256,
>> +    GUARD_INTERVAL_PN420,
>> +    GUARD_INTERVAL_PN595,
>> +    GUARD_INTERVAL_PN945,
>>   } fe_guard_interval_t;
>
> What does PN mean in this context?

It stays for pseudo noise.

Generally those are rather same as PN420 = GI 1/4, PN595 = GI 1/6, PN945 
= GI 1/9. But as a old DVB-T GI, cyclic prefix, is rather likely some 
static data without any real payload meaning, the PN GI is enchanted 
inserting some data that have meaning. Also PN GI is boosted, like 
doubled TX power in order to easy sync.

Here is the one good research paper which compares DVB-T and DTMB [1]
And this Wikipedia page is rather helful too [2]


As I have read much more docs today I have now some changes I want to do:

CARRIER
=======
typedef enum fe_transmit_mode {
	TRANSMISSION_MODE_C=1,
	TRANSMISSION_MODE_C=3780,
} fe_transmit_mode_t;

(If not "=" mark is not possible then use C1, C3780)

Instead of adding new carrier param, just use exiting one since it seems 
to be just suitable. Extend DTMB modes C=1 and C=3780.



GUARD INTERVAL (PN-mode)
========================
typedef enum fe_guard_interval {
	GUARD_INTERVAL_PN420,
	GUARD_INTERVAL_PN595,
	GUARD_INTERVAL_PN945,
} fe_guard_interval_t;



CODE RATE
=========
typedef enum fe_code_rate {
	FEC_04,
	FEC_06,
	FEC_08,
} fe_code_rate_t;

I have strong feeling old FECs, 1 over 2, are 100% suitable only for the 
Reed-Solomon coding. For BCH + LDPC coding those are not so suitable as 
code rate is not exact and thus with LDPC 0.4/0.6/0.8 is used. I have 
mentioned that earlier too, but after I read that [1] I think it is just 
like that. It is not big issue but still I would like to use those 
instead old.

Otherwise FEC_2_5 for code rate 0.4 should be defined.



MODULATION (constellation)
==========================
typedef enum fe_modulation {
	QAM_4_NR,
} fe_modulation_t;

I feel QAM4-NR fits here too, since it is mentioned every document just 
one more supported modulation like QAM32, QAM16, QAM4...


INTERLEAVING
============
typedef enum fe_interleaving {
	INTERLEAVING_240,
	INTERLEAVING_720,
} fe_interleaving_t;

I think better to add enum for all possible interleavers we can have. I 
suspect there will be very limited amount of interleave settings 
supported by each DTV modulation, thus enum is good choice.



That's all. I will wait comments maybe tomorrow night and make new 
propose or RFC. I hope comments. And all those comments given are taken 
accepted unless I replied something back. And please look research paper 
[1], it is very good. Happy Xmas!


[1] Analysis and Performance Comparison of DVB-T and DTMB Systems for 
Terrestrial Digital TV
http://hal.archives-ouvertes.fr/docs/00/32/58/24/PDF/MLIU_ICCS2008.pdf

[2] OFDM system comparison table
http://en.wikipedia.org/wiki/OFDM#OFDM_system_comparison_table

regards
Antti
-- 
http://palosaari.fi/