[linux-dvb] Re: Types and capabilites for HDTV ATSC.

[Holger Waechtler <holger@qanu.de>]

I applied your proposed changes to the dvb-kernel CVS frontend.h file. 
You probably also need to add a struct dvb_atsc_parameters atsc to 
struct dvb_frontend_parameters parameter union, right?

It would then look like this:


struct dvb_atsc_parameters {
	fe_modulation_t  modulation;
	/* anything more? maybe 8VSB or 16VSB? */
};


struct dvb_frontend_parameters {
        __u32 frequency;
        fe_spectral_inversion_t inversion;
        union {
                struct dvb_qpsk_parameters qpsk;
                struct dvb_qam_parameters  qam;
                struct dvb_ofdm_parameters ofdm;
                struct dvb_atsc_parameters atsc;
        } u;
};



Mac Michaels wrote:
> After adding feedback from dvb-linux posts here is a summary 
> of additions for supporting ATSC frontends in DVB.
>
> In the frontend.h header file:
>
> Add a new  fe_type
>
> 	FE_ATSC
>
> Add two new capabilities to fe_caps
>
> 	FE_CAN_8VSB		= 0x200000,
> 	FE_CAN_16VSB		= 0x400000,
>
> 8VSB is for ATSC in the U.S. I don't know where 16VSB is 
> used, but the LGDT3302 supports it
>
>
> Mac Michaels
>
> On Tuesday 03 August 2004 07:47 pm, you wrote:
>
> > Mac Michaels wrote:
> >
> > > I am the owner of a FunsionHDTV 3 Gold card. I have the
> > > analog TV and audio working with my modificatons to the
> > > CX88 driver. I am working on the Digital TV (HDTV ATSC)
> > > and want to integrate it into DVB as I seems to be a
> > > good fit. The FusionHDTV card produces a transport
> > > stream that seems to fit well with DVB. I found Chris
> > > Pascoe's modifications to the cx88 driver and plan to
> > > adapt them for my card. The LGDT3302 frontend provides
> > > some of the signal quality data the other DVB
> > > demodulators provide. It tunes the same physical
> > > frequency bands as U.S. analog TV.
> > >
> > > I am not sure which fe_type I should use for the
> > > driver. FE_QAM seems appropriate for QAM 64/256 that is
> > > supported by the card. What existing or new type is
> > > ATSC HDTV? Does the driver register 2 interfaces, one
> > > for each type?
> > I'd propose FE_ATSC because it's not straight QAM but QAM
> > encapsulated in 8VSB -- similiar to the DVB-T/OFDM demods
> > which encapsulate a QPSK or QAM modulation in a OFDM
> > multiplexing scheme.
> >
> >
> > > I think a new fe_caps may be needed for 8VSB ATSC. How
> > > about:
> > >
> > > FE_CAN_VSB_8
> > >
> > > For fe_type FE_QAM the fe_caps should probably be
> > >
> > > FE_CAN_QAM_64 | FE_QAM_256
> > sounds good.
> >
> > Holger