Em 11-11-2011 15:43, BOUWSMA Barry escreveu: > > On Do (Donnerstag) 10.Nov (November) 2011, 22:20, Mauro Carvalho Chehab wrote: > >> We should also think on a way to enumerate the supported values for each DVB $ >> the enum fe_caps is not enough anymore to store everything. It currently has $ >> filled (of a total of 32 bits), and we currently have: >> 12 code rates (including AUTO/NONE); > > I'm probably not looking at the correct source, but the numbers > seem to match, so I'll just note that in what I'm looking at, > there are missing the values 1/3 and 2/5 . Those were not added yet, as no driver currently uses it. > > But I have to apologise in that I've also not been paying > attention to this conversation, and haven't even been trying > to follow recent developments. > > >> 13 modulation types; > > Here I see missing QAM1024 and QAM4096 . Same here. > > >> 7 transmission modes; >> 7 bandwidths; > > Apparently DVB-C2 allows us any bandwidth from 8MHz to 450MHz, > rather than the discrete values used by the other systems. > If this is also applicable to other countries with 6MHz rasters, > would it be necessary in addition to specify carrier spacing, > either 2,232kHz or 1,674kHz as opposed to getting this from the > channel bandwidth? There are 3 parameters for Satellite and Cable systems: - Roll off factor; - Symbol Rate; - Bandwidth. Only two of the tree are independent, as the spec defines: Bandwidth = symbol rate * (1 + roll off). For DVB-C Annex A and C, roll off is fixed (0.15 and 0.13, respectively). ITU-T J 83 Annex B doesn't say anything about it, but the ANSI SCTE07 spec says that the roll-off is approx. 0.18 for 256-QAM and approx. 0.12 for 256-QAM. DVB-S also has a fixed roll-off of 0.35, while DVB-S2 allows configuring it. Not 100% sure, but ISDB-S also seems to use a per-modulation roll-off factor. Anyway, when the roll-off is known, only symbol rate is needed, in order to know the needed bandwidth. IMHO, we should add some function inside the DVB core to calculate the bandwidth for DVB-C (and DVB-C2), as the tuner saw filters require it, in order to filter spurious frequencies from adjacent channels. Some demods may also need such info. The DVBv5 API doesn't impose any step for the carrier value, as it is specified in Hz. So, I don't think that any change would be needed at the userspace API, in order to support DVB-C2 "continuous" carrier spacing. > > >> 8 guard intervals (including AUTO); > > Here I observe the absence of 1/64 . Same here: currently, no driver implements it. > > >> 5 hierarchy names; >> 4 rolloff's (probably, we'll need to add 2 more, to distinguish between$ > > > Of course, I'm just pointing out what I find, as I really don't > know anything about the transport systems, and someone who > actually does might be able to say more, and correct my errors. > > So just ignore me -- I'd rather see these values added sooner > than later if needed. Apparently the broadcasts from Borups > Allé scheduled to start sometime around now will be switching > over to use those mentioned to test their increased robustness. Implementing those parameters is not a matter of just adding new stuff at the core. Developers need DVB-C2 capable hardware, and access to a broadcaster using it (or access to some testing facility where DVB-C2 could be simulated). Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
