Em 14-11-2011 13:02, Manu Abraham escreveu: > On Mon, Nov 14, 2011 at 5:17 PM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxx> wrote: >> Em 13-11-2011 13:27, Manu Abraham escreveu: >>> 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 >> >> Manu, >> >> A good reference for working with those stuff is the Symon Haykin book: >> http://www.amazon.com/Communication-Systems-4th-Simon-Haykin/dp/0471178691 >> >> I used it a lot during the time I was studying Electrical Engineering it at University, >> and during my post-graduation. > > > Mauro, > > Well, if the discussion is about know the person whom you are talking > to: I did my Engineering degree in Electronics and Communication; > Simon and Haykin was just one among them in one of the semesters. I > still have those college books somewhere in an old dusty shelf. Later > on, I worked at the (Remote Sensing and CVAI labs) Indian Institute of > Sciences, Bangalore. Further down the lane, did work with media > broadcast organizations. > > I am not going to get into an argument session, where you keep on > changing the topic, with unrelated or incorrect stuff altogether. I'm not changing topic. All I'm saying since the beginning is that there's no need to add Bandwidth at the DVB API for cable/satellite, as, for the supported delivery systems, the symbol rate + roll-off can be used for bandwidth estimation, where needed, E. g.: Bandwidth = max_symbol_rate * (1 + roll_off) > > Let this thread die. :-) Agreed. 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
