[linux-dvb] [PATCH] Multi protocol support (stage #1)

Manu Abraham abraham.manu at gmail.com
Thu Apr 27 13:32:21 CEST 2006


Hello Patrick,

Patrick Boettcher wrote:
> Hi Manu,
>
> linuxtv seems to be down currently, would you please bounce my answer 
> in that case.
>

Done.

> +enum fe_stream {
> +       FE_STREAM_HP                    = 0x00000001,
> +       FE_STREAM_LP                    = 0x00000002
> +};
>
> [..]
>
> +enum fe_bandwidths {
> +       FE_BANDWIDTH_QUERY              = 0x00000000,
> +       FE_BANDWIDTH_8_MHZ              = 0x00000001,
> +       FE_BANDWIDTH_7_MHZ              = 0x00000002,
> +       FE_BANDWIDTH_6_MHZ              = 0x00000004,
> +       FE_BANDWIDTH_AUTO               = 0x10000000
> +};
>
> In DVB-H other bandwidth can be used. IMHO, it would be more useful to 
> specify the bandwidth in MHz, instead of have defines.


What do you think of having a specific parameter "bandwidth" for DVB-H
in the relevant data structure ? Reason being DVB-T has it just
selectable between the fields.


>
> +enum fe_inversion {
> +       FE_INVERSION_QUERY              = 0x00000000,
> +       FE_INVERSION_OFF                = 0x00000001,
> +       FE_INVERSION_ON                 = 0x00000002,
> +       FE_INVERSION_AUTO               = 0x10000000
> +};
>
> Afaik, at least for DVB-T/H, Inversion is not a real tuning parameter. 
> There is not reason for a broadcaster to send the inverted spectrum... 
> the inversion-switch I saw so, was always only because of the 
> tuner-output. So in fact the inversion differences have been caused by 
> different designs.

 From basic logic that's what i too thought, why do we need phase
inversion for Frequency Divsion Multiplex. But as i read couple of
articles and specifications and some datasheets, i came up across like
this ..

"During the up-conversion and the following downconversion, the COFDM
spectrum can be inverted, depending on the equipment used. This bit
determines if the COFDM signal should be spectrally inverted (1) or not
(0)."

So i think, we agree on the fact that it is dependant on the hardware
implementation

>
>> From the tuning point of view inversion should be always AUTO. 
>
> +enum fe_hierarchy_info {
> +       FE_HIERARCHY_QUERY              = 0x00000000,
> +       FE_HIERARCHY_NONE               = 0x00000001,
> +       FE_HIERARCHY_1                  = 0x00000002,
> +       FE_HIERARCHY_2                  = 0x00000004,
> +       FE_HIERARCHY_4                  = 0x00000008,
> +       FE_HIERARCHY_AUTO               = 0x10000000
> +};
>
> Those setting seem to come from a modulator-menu ;).
>
> Maybe hierarchy on/off and another parameter alpha is better, or like 
> this:
>
> +enum fe_hierarchy_info {
> +       FE_HIERARCHY_QUERY              = 0x00000000,
> +       FE_HIERARCHY_OFF                = 0x00000001,
> +       FE_HIERARCHY_ON_ALPHA_1         = 0x00000002,
> +       FE_HIERARCHY_ON_ALPHA_2         = 0x00000004,
> +       FE_HIERARCHY_ON_ALPHA_4         = 0x00000008,
> +       FE_HIERARCHY_AUTO               = 0x10000000
> +};
>
> What do you think? In conjuntion with fe_stream we finally can really 
> use hierarchy mode with linux-dvb.
>


Yeah, sounds good. DVB-S2 also uses HP/LP streams similar to DVB-T. The
only problem is someone having an issue stating future compatibility.


> +enum fe_mpefec{
> +       FE_MPEFEC_ON                    = 0x00000001,
> +       FE_MPEFEC_OFF                   = 0x00000002,
> +};
> +
> +enum fe_timeslicing {
> +       FE_TIMESLICING_ON               = 0x00000001,
> +       FE_TIMESLICING_OFF              = 0x00000002
> +};
>
> Hmm, OK, What about AUTO for timeslicing and mpefec.
>


As i went through the specs, Timeslicing and MPEFEC are indicators, ie
RO values. So do we need AUTO ? This was one thing that crept into my
mind. And one more thing came up yesterday, since we will have more
delivery systems/modulations etc in future and we intend it to be
serviced by one IOCTL, GET_PARAMS, having a field to selectively ignore
the specified type will help in lesser I/O transactions , which might
not be necessary for the user app. ie, the use app may selectively
choose to ignore that parameter.

For example FE_IGNORE_PARAM_TYPE = 0
using this, will cause it not to query back that relavant parameter.
What do you think ?

> +/**
> + *     DVB-T parameters
> + */
> +struct dvbt_params {
> +       enum fe_modulations             constellation;
> +       enum fe_bandwidths              bandwidth;
> +       enum fe_fecrates                code_rate_HP;
> +       enum fe_fecrates                code_rate_LP;
> +       enum fe_transmit_modes          transmission_mode;
> +       enum fe_guard_intervals         guard_interval;
> +       enum fe_hierarchy_info          hierarchy;
> +};
> +
> +/**
> + *     DVB-H parameters
> + */
> +struct dvbh_params {
> +       enum fe_modulations             constellation;
> +       enum fe_bandwidths              bandwidth;
> +       enum fe_fecrates                code_rate_HP;
> +       enum fe_fecrates                code_rate_LP;
> +       enum fe_transmit_modes          transmission_mode;
> +       enum fe_guard_intervals         guard_interval;
> +       enum fe_hierarchy_info          hierarchy;
> +       enum fe_mpefec                  mpefec;
> +       enum fe_timeslicing             timeslicing;
> +};
>
> In hierarchy mode, how to select the HP or LP stream?
>

Specify the code rate for the relevant HP/LP stream ?


> I think for dvbh and dvbt we need to add:
>
> +       enum fe_stream                  stream;
>
> Default should be always the HP-stream.
>

Ah, thanks for pointing it out. So that makes it necessary for DVB-S2,
DVB-T and DVB-H

> Sorry for being so short - but vacation is waiting :)
>

No problems, Thanks for the comments.


Regards,
Manu





More information about the linux-dvb mailing list