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
