[linux-dvb] DVB-S2 and other (new) modulation standards

Johannes Stezenbach js at linuxtv.org
Wed Nov 23 00:00:23 CET 2005

On Tue, Nov 22, 2005, Felix Domke wrote:
> in the tuxbox irc channel we were discussing how to tune to DVB-S2
> transponders, of course using all that not-yet-existing (at least not in
> numbers) hardware which we all wait for.
> The problem is that the current dvb_qpsk_parameters cannot really be
> extended without breaking backward compatibility, and still, -S2 isn't
> strictly QPSK but QAM too, but on the other hand has nothing to do with
> DVB-C and the already defined dvb_qam_parameters.

Maybe we should finally rename FE_QPSK etc. and dvb_qpsk_parameters etc.
to FE_TYPE_DVB_S etc. and dvb_tuning_parameters_dvb_t etc.,
and provide backwards compat #defines for "old" apps?
This wouldn't create binary compatibilty problems.

> Basically we had two ideas:
> The first one was:
> #define FE_SET_FRONTEND_EX    _IOW('o', xx, struct
> dvb_frontend_parameters_ex)
> #define FE_STANDARD_DVB_S 0
> #define FE_STANDARD_DVB_C 1
> #define FE_STANDARD_DVB_T 2
> #define FE_STANDARD_DVB_S2 3
> struct dvb_frontend_parameters_ex {
>   int standard; /* this is new! */
>   __u32 frequency;
>   fe_spectral_inversion_t inversion;
>   union {
>     struct dvb_qpsk_parameters qpsk;
>     struct dvb_qpsk2_parameters qpsk2; // qpsk + -S2 specific stuff
>     struct dvb_qam_parameters  qam;
>     struct dvb_ofdm_parameters ofdm;
>     struct dvb_vsb_parameters vsb;
>   } u;
> };
> The other method, which i prefer, is:
> #define FE_SET_STANDARD     _IOW('o', xx, int)
> #define FE_STANDARD_DVB_S 0
> #define FE_STANDARD_DVB_C 1
> #define FE_STANDARD_DVB_T 2
> #define FE_STANDARD_DVB_S2 3
> FE_CAN_DVBS = xxx,
> FE_CAN_DVBC = xxx,
> FE_CAN_DVBT = xxx,
> FE_CAN_ATSC = xxx,
> FE_CAN_DVBS2 = xxx,
> The current dvb_frontend_parameters could be extended for the new
> standard. Each standard would define to use exactly one
> "dvb_xxx_parameters" in that union.

How about enum fe_rolloff_flag from Marcel's posting?

If the size of struct dvb_frontend_parameters changes we
break binary compatibility. However, since struct dvb_ofdm_parameters
is quite a bit larger than the other ones, it might work to
just add struct dvb_qpsk2_parameters to the union in
struct dvb_frontend_parameters.

> This method would also catch the DVB-S/DVB-T-combi frontends which
> lately appeared here. One could set the STANDARD, and the frontend would
> change it's complete personality (probably including other FE_CAN_-caps,
> changing the frequency_min/max/..-limits etc.). A frontend could decide
> to stop supporting SEC commands when switched to DVB-T mode etc.

Hm. How do we handle dvb_frontend_info.type?

> A final question was how to support DVB-H. Is DVB-H totally backward
> compatible to DVB-T? (ignoring the 4k mode, of course, but that could be
> added backward-compatible to DVB-T) Do we want to support that power
> management features, if yes, how? A new dvb_dvbh_parameters, based on
> the _ofdm-one, with some added fields? I never did anything DVB-H
> related, so please excuse my ignorance.

I know next to nothing about DVB-H.


More information about the linux-dvb mailing list