On Sat, Nov 12, 2011 at 12:07 AM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > 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. DVB-S uses 3 different rolloffs just like DVB-S2. In fact the rolloff doesn't have anything to do with the delivery system at all, but something that which is independant and physical to the channel, rather than something logical such as a delivery system, looking at a satellite transponder's viewpoint. For general (home) broadcast purposes, we use only 0.35. There are many other usages, which is not yet applicable with especially Linux DVB with regards to narrow band operations such as DVB feeds and DSNG. There are many usages for the second generation delivery systems, which will likely realize only a very small part. Eg: there are other aspects to DVB-S2 such as ACM and VCM, which most likely we wouldn't cover. the reason is that the users of it are most likely propreitary users of it and neither would they prefer to have an open source version for it, nor would any Open Source users be likely to implement it. Eg: Ericson's Director CA system, where they have complete control over the box, rather than the user. As far as I am aware they have a return path as well. > > 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. You need to know FEC, modulation too .. Eg: If you have 16APSK where you have 4 bits, in comparison to 3 bits as with 8PSK, then you require lesser bandwidth. Also, higher the Error correction information bits set in (redundant), the more bandwidth it needs to occupy. This is the same with any Digital Channel whether it be Satellite/Cable/Terrestrial, whatever delivery system it is. Regards, Manu -- 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
