On Sun, Nov 13, 2011 at 7:02 PM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > Em 11-11-2011 20:34, Manu Abraham escreveu: >> 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. > > Ok. > >> >> 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. > > Manu, you're probably thinking in terms of the TS bit rate, and not the > modulator symbol rate. > > The number of bits don't matter here, as the symbol rate is specified > in bauds (e. g. symbols per second), and not in bits/s. A PSK modulator is a state machine: where states/symbols are logically represented by bits, given that the state can either be a 0 or 1 BPSK states=2 bits=1 QPSK states=4 bits=2 8PSK states=8 bits=3 16PSK states=16 bits=4 32PSK states=32 bits=5 http://en.wikipedia.org/wiki/Constellation_diagram http://en.wikipedia.org/wiki/Gray_code Symbol Rate is generally specified in SPS, ie Symbols/sec, or in Bauds. AFAICS, We generally use Symbols Per Second rather than bauds. http://www.asiasat.com/asiasat/contentView.php?section=69&lang=0 http://www.b4utv.com/subs/technology.shtml http://www.skynewsinternational.com/watch/satellite-information I haven't seen a demodulator specification which states Mbaud, but have seen them stated as MSPS or kSPS. Now, assuming a 36MHz TP as an example: The given bandwidth is better or efficiently used by a higher order modulation. This is the reason why DVB.org states that DVB-S2 saves 30% bandwidth. Quoting you: "Anyway, when the roll-off is known, only symbol rate is needed, in order to know the needed bandwidth." Given a fixed TP CHBW, according to you: Channel Bandwidth can be calculated by knowing Symbol Rate alone, with a known rolloff. I say that this is not possible. Since the number of states/symbols for any given channel depends on the modulation order as well. I hope that clears up things for you. > The conversion from bauds to bits/s is to multiply the number of bits per > symbol by the rate, in bauds. > > A higher number of bits for a given modulation just increase the number of > possible states that the modulation will use. So, it will require a higher > signal to noise relation at the demod, to avoid miss-detection, but this is > a separate issue. That's why for higher order modulations, demodulators use better Error Correction Schemes (eg: BCH/Turbo) when the modulation order is higher. http://en.wikipedia.org/wiki/Modulation_order http://en.wikipedia.org/wiki/BCH_code > The roll-off, minimal bandwidth (referred as "Nyquist frequency" by the DVB-C > specs) and symbol rate are related by this equation: > f = symbol_rate * (1 + roll_off) > > The f value is the Nyquist frequency, and it will dictate the low-pass filter > needed to confine the entire signal of the channel (with is, basically, the > amount of bandwidth required by the channel). > >> Also, higher the Error correction information bits set in (redundant), >> the more bandwidth it needs to occupy. > > The error correction algorithm will reduce the bit rate of the TS stream, > but won't affect the symbol rate at the modulator. No. That's an incorrect statement. FEC gives the receiver the ability to correct errors without needing a reverse channel to request retransmission of data, but at the cost of a fixed, higher forward channel bandwidth. http://en.wikipedia.org/wiki/Forward_error_correction >> This is the same with any >> Digital Channel whether it be Satellite/Cable/Terrestrial, whatever >> delivery system it is. > > Yes. > >> >> 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 > > Hope it helps to clear your understanding. 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
