Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 01/06/2013 07:03 PM, Mauro Carvalho Chehab wrote: Em Thu, 03 Jan 2013 23:33:49 +0200 Antti Palosaari escreveu: On 01/03/2013 06:29 PM, Mauro Carvalho Chehab wrote: Em Thu, 3 Jan 2013 14:14:29 -0200 Mauro Carvalho Chehab escreveu: Em Thu, 03 Jan 2013 16:18:26 +0100 Klaus Schmidinger escreveu: On 03.01.2013 14:20, Mauro Carvalho Chehab wrote: Em Wed, 2 Jan 2013 00:38:50 +0530 Manu Abraham escreveu: On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab wrote: Em Tue, 1 Jan 2013 22:18:49 +0530 Manu Abraham escreveu: On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab wrote: [RFCv4] dvb: Add DVBv5 properties for quality parameters The DVBv3 quality parameters are limited on several ways: - Doesn't provide any way to indicate the used measure; - Userspace need to guess how to calculate the measure; - Only a limited set of stats are supported; - Doesn't provide QoS measure for the OFDM TPS/TMCC carriers, used to detect the network parameters for DVB-T/ISDB-T; - Can't be called in a way to require them to be filled all at once (atomic reads from the hardware), with may cause troubles on interpreting them on userspace; - On some OFDM delivery systems, the carriers can be independently modulated, having different properties. Currently, there's no way to report per-layer stats; per layer stats is a mythical bird, nothing of that sort does exist. Had you ever read or tried to get stats from an ISDB-T demod? If you had, you would see that it only provides per-layer stats. Btw, this is a requirement to follow the ARIB and ABNT ISDB specs. I understand you keep writing junk for ages, but nevertheless: Do you have any idea what's a BBHEADER (DVB-S2) or PLHEADER (DVB-T2) ? The headers do indicate what MODCOD (aka Modulation/Coding Standard follows, whatever mode ACM, VCM or CCM) follows. These MODCOD foolows a TDM approach with a hierarchial modulation principle. This is exactly what ISDB does too. No, I didn't check DVB-S2/T2 specs deeply enough to understand if they're doing the same thing as ISDB. Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation. It uses a FDM (OFDM is a type of Frequency Division Multiplexing). So, if you're saying that DVB-S2 uses TDM, it is very different than ISDB-T. As DVB-T2 uses an FDM type of modulation (OFDM), it would be possible to segment the carriers there, just like ISDB, or to use TDM hierarchical modulation techniques. And for your info: " The TMCC control information is common to all TMCC carriers and error correction is performed by using difference-set cyclic code." Yes, TMCC carriers are equal and they are always modulated using DBPSK. That is done to make it possible to receive the TMCC carriers even under worse SNR conditions, where it may not be possible to decode the segment groups. It seems that you completely missed the point though. On ISDB-T, the carriers that belong to each group of segments (except for the control carriers - carriers 1 to 107) uses a completely independent modulation. Also, as they're spaced in frequency, the interference of each segment is different. So, error indications are different on each segment. Btw, in any case, the datasheets of ISDB-T demods clearly shows that the BER measures are per segment group (layer). For example, for the BER measures before Viterbi, those are the register names for a certain demod: VBERSNUMA Bit count of BER measurement before Viterbi in A layer VBERSNUMB Bit count of BER measurement before Viterbi in B layer VBERSNUMC Bit count of BER measurement before Viterbi in C layer It has another set of registers for BER after Viterbi, and for PER after Viterbi and RS, for bit count errors, etc. There's no way to get any type of "global" BER measure, simply because ISDB-T demods don't provide. Maybe we should put all this theoretical discussion aside for the moment and think about what is *really* needed by real world applications. As with any receiver, VDR simply wants to have some measure of the signal's "strength" and "quality". These are just two values that should be delivered by each frontend/demux, using the *same* defined and mandatory range. I don't care what exactly that is, but it needs to be the same for all devices. What values a particular driver uses internally to come up with these is of no interest to VDR. The "signal strength" might just be what is currently returned through FE_READ_SIGNAL_STRENGTH (however, normalized to the same range in all drivers, which currently is not the case). The "signal quality" might use flags like FE_HAS_SIGNAL, FE_HAS_CARRIER, FE_HAS_VITERBI, FE_HAS_SYNC, as well as SNR, BER and UNC (if available) to form some value where 0 means no quality at all, and 0x means excellent quality. If a particular frontend/demux uses totally different concepts,
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Em Thu, 03 Jan 2013 23:33:49 +0200 Antti Palosaari escreveu: > On 01/03/2013 06:29 PM, Mauro Carvalho Chehab wrote: > > Em Thu, 3 Jan 2013 14:14:29 -0200 > > Mauro Carvalho Chehab escreveu: > > > >> Em Thu, 03 Jan 2013 16:18:26 +0100 > >> Klaus Schmidinger escreveu: > >> > >>> On 03.01.2013 14:20, Mauro Carvalho Chehab wrote: > Em Wed, 2 Jan 2013 00:38:50 +0530 > Manu Abraham escreveu: > > > On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab > > wrote: > >> Em Tue, 1 Jan 2013 22:18:49 +0530 > >> Manu Abraham escreveu: > >> > >>> On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab > >>> wrote: > >>> > [RFCv4] dvb: Add DVBv5 properties for quality parameters > > The DVBv3 quality parameters are limited on several ways: > - Doesn't provide any way to indicate the used measure; > - Userspace need to guess how to calculate the measure; > - Only a limited set of stats are supported; > - Doesn't provide QoS measure for the OFDM TPS/TMCC > carriers, used to detect the network parameters for > DVB-T/ISDB-T; > - Can't be called in a way to require them to be filled > all at once (atomic reads from the hardware), with may > cause troubles on interpreting them on userspace; > - On some OFDM delivery systems, the carriers can be > independently modulated, having different properties. > Currently, there's no way to report per-layer stats; > >>> > >>> per layer stats is a mythical bird, nothing of that sort does exist. > >> > >> Had you ever read or tried to get stats from an ISDB-T demod? If you > >> had, you would see that it only provides per-layer stats. Btw, this is > >> a requirement to follow the ARIB and ABNT ISDB specs. > > > > I understand you keep writing junk for ages, but nevertheless: > > > > Do you have any idea what's a BBHEADER (DVB-S2) or > > PLHEADER (DVB-T2) ? The headers do indicate what MODCOD > > (aka Modulation/Coding Standard follows, whatever mode ACM, > > VCM or CCM) follows. These MODCOD foolows a TDM approach > > with a hierarchial modulation principle. This is exactly what ISDB > > does too. > > No, I didn't check DVB-S2/T2 specs deeply enough to understand > if they're doing the same thing as ISDB. > > Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation. > It uses a FDM (OFDM is a type of Frequency Division Multiplexing). > > So, if you're saying that DVB-S2 uses TDM, it is very different than > ISDB-T. As DVB-T2 uses an FDM type of modulation (OFDM), it would > be possible to segment the carriers there, just like ISDB, or to > use TDM hierarchical modulation techniques. > > > > > And for your info: > > > > " The TMCC control information is > > common to all TMCC carriers and > > error correction is performed by using > > difference-set cyclic code." > > Yes, TMCC carriers are equal and they are always modulated using DBPSK. > That is done to make it possible to receive the TMCC carriers even under > worse SNR conditions, where it may not be possible to decode the segment > groups. > > It seems that you completely missed the point though. On ISDB-T, the > carriers that belong to each group of segments (except for the control > carriers - carriers 1 to 107) uses a completely independent modulation. > Also, as they're spaced in frequency, the interference of each segment > is different. So, error indications are different on each segment. > > Btw, in any case, the datasheets of ISDB-T demods clearly shows that > the BER measures are per segment group (layer). > > For example, for the BER measures before Viterbi, those are the register > names for a certain demod: > > VBERSNUMA Bit count of BER measurement before Viterbi in A layer > VBERSNUMB Bit count of BER measurement before Viterbi in B layer > VBERSNUMC Bit count of BER measurement before Viterbi in C layer > > It has another set of registers for BER after Viterbi, and for PER after > Viterbi and RS, for bit count errors, etc. > > There's no way to get any type of "global" BER measure, simply because > ISDB-T demods don't provide. > >>> > >>> Maybe we should put all this theoretical discussion aside for the moment > >>> and > >>> think about what is *really* needed by real world applications. As with > >>> any > >>> receiver, VDR simply wants to have some measure of the signal's "strength" > >>> and "quality". These are just two values that should be delivered by each > >>> frontend/demux, using the *same* defined and
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On Fri, Jan 4, 2013 at 10:33 AM, VDR User wrote: > On Thu, Jan 3, 2013 at 1:33 PM, Antti Palosaari wrote: >> I would not like to define exact units for BER and USB as those are quite >> hard to implement and also non-sense. User would like just to see if there >> is some (random) numbers and if those numbers are rising or reducing when he >> changes antenna or adjusts gain. We are not making a professional signal >> analyzers - numbers does not need to be 100% correctly. > > Just a small comment here. Since this may finally be done, why not do > it the best way? In the end I think that's better and I don't see any > harm in having the capability to make a pro-grade signal analyzer. > After years of waiting, I don't think half-assing is a good idea. The problem is not in creating an API for such a thing. The problem arises from the fact that all devices need to worked to comply to the API. It might not factually possible to do that, since most drivers are reverse engineered or written in a crude way.. In a lot many cases, there are not even the right documents to do that. An API alone doesn't solve anything at all. Here we are talking about making pro grade software based on home grade silicon, for which most don't have proper documentation. Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On Thu, Jan 3, 2013 at 1:33 PM, Antti Palosaari wrote: > I would not like to define exact units for BER and USB as those are quite > hard to implement and also non-sense. User would like just to see if there > is some (random) numbers and if those numbers are rising or reducing when he > changes antenna or adjusts gain. We are not making a professional signal > analyzers - numbers does not need to be 100% correctly. Just a small comment here. Since this may finally be done, why not do it the best way? In the end I think that's better and I don't see any harm in having the capability to make a pro-grade signal analyzer. After years of waiting, I don't think half-assing is a good idea. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Em Thu, 03 Jan 2013 23:33:49 +0200 Antti Palosaari escreveu: > On 01/03/2013 06:29 PM, Mauro Carvalho Chehab wrote: > > Em Thu, 3 Jan 2013 14:14:29 -0200 > > Mauro Carvalho Chehab escreveu: > > > >> Em Thu, 03 Jan 2013 16:18:26 +0100 > >> Klaus Schmidinger escreveu: > >> > >>> On 03.01.2013 14:20, Mauro Carvalho Chehab wrote: > Em Wed, 2 Jan 2013 00:38:50 +0530 > Manu Abraham escreveu: > > > On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab > > wrote: > >> Em Tue, 1 Jan 2013 22:18:49 +0530 > >> Manu Abraham escreveu: > >> > >>> On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab > >>> wrote: > >>> > [RFCv4] dvb: Add DVBv5 properties for quality parameters > > The DVBv3 quality parameters are limited on several ways: > - Doesn't provide any way to indicate the used measure; > - Userspace need to guess how to calculate the measure; > - Only a limited set of stats are supported; > - Doesn't provide QoS measure for the OFDM TPS/TMCC > carriers, used to detect the network parameters for > DVB-T/ISDB-T; > - Can't be called in a way to require them to be filled > all at once (atomic reads from the hardware), with may > cause troubles on interpreting them on userspace; > - On some OFDM delivery systems, the carriers can be > independently modulated, having different properties. > Currently, there's no way to report per-layer stats; > >>> > >>> per layer stats is a mythical bird, nothing of that sort does exist. > >> > >> Had you ever read or tried to get stats from an ISDB-T demod? If you > >> had, you would see that it only provides per-layer stats. Btw, this is > >> a requirement to follow the ARIB and ABNT ISDB specs. > > > > I understand you keep writing junk for ages, but nevertheless: > > > > Do you have any idea what's a BBHEADER (DVB-S2) or > > PLHEADER (DVB-T2) ? The headers do indicate what MODCOD > > (aka Modulation/Coding Standard follows, whatever mode ACM, > > VCM or CCM) follows. These MODCOD foolows a TDM approach > > with a hierarchial modulation principle. This is exactly what ISDB > > does too. > > No, I didn't check DVB-S2/T2 specs deeply enough to understand > if they're doing the same thing as ISDB. > > Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation. > It uses a FDM (OFDM is a type of Frequency Division Multiplexing). > > So, if you're saying that DVB-S2 uses TDM, it is very different than > ISDB-T. As DVB-T2 uses an FDM type of modulation (OFDM), it would > be possible to segment the carriers there, just like ISDB, or to > use TDM hierarchical modulation techniques. > > > > > And for your info: > > > > " The TMCC control information is > > common to all TMCC carriers and > > error correction is performed by using > > difference-set cyclic code." > > Yes, TMCC carriers are equal and they are always modulated using DBPSK. > That is done to make it possible to receive the TMCC carriers even under > worse SNR conditions, where it may not be possible to decode the segment > groups. > > It seems that you completely missed the point though. On ISDB-T, the > carriers that belong to each group of segments (except for the control > carriers - carriers 1 to 107) uses a completely independent modulation. > Also, as they're spaced in frequency, the interference of each segment > is different. So, error indications are different on each segment. > > Btw, in any case, the datasheets of ISDB-T demods clearly shows that > the BER measures are per segment group (layer). > > For example, for the BER measures before Viterbi, those are the register > names for a certain demod: > > VBERSNUMA Bit count of BER measurement before Viterbi in A layer > VBERSNUMB Bit count of BER measurement before Viterbi in B layer > VBERSNUMC Bit count of BER measurement before Viterbi in C layer > > It has another set of registers for BER after Viterbi, and for PER after > Viterbi and RS, for bit count errors, etc. > > There's no way to get any type of "global" BER measure, simply because > ISDB-T demods don't provide. > >>> > >>> Maybe we should put all this theoretical discussion aside for the moment > >>> and > >>> think about what is *really* needed by real world applications. As with > >>> any > >>> receiver, VDR simply wants to have some measure of the signal's "strength" > >>> and "quality". These are just two values that should be delivered by each > >>> frontend/demux, using the *same* defined and
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 01/03/2013 06:29 PM, Mauro Carvalho Chehab wrote: Em Thu, 3 Jan 2013 14:14:29 -0200 Mauro Carvalho Chehab escreveu: Em Thu, 03 Jan 2013 16:18:26 +0100 Klaus Schmidinger escreveu: On 03.01.2013 14:20, Mauro Carvalho Chehab wrote: Em Wed, 2 Jan 2013 00:38:50 +0530 Manu Abraham escreveu: On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab wrote: Em Tue, 1 Jan 2013 22:18:49 +0530 Manu Abraham escreveu: On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab wrote: [RFCv4] dvb: Add DVBv5 properties for quality parameters The DVBv3 quality parameters are limited on several ways: - Doesn't provide any way to indicate the used measure; - Userspace need to guess how to calculate the measure; - Only a limited set of stats are supported; - Doesn't provide QoS measure for the OFDM TPS/TMCC carriers, used to detect the network parameters for DVB-T/ISDB-T; - Can't be called in a way to require them to be filled all at once (atomic reads from the hardware), with may cause troubles on interpreting them on userspace; - On some OFDM delivery systems, the carriers can be independently modulated, having different properties. Currently, there's no way to report per-layer stats; per layer stats is a mythical bird, nothing of that sort does exist. Had you ever read or tried to get stats from an ISDB-T demod? If you had, you would see that it only provides per-layer stats. Btw, this is a requirement to follow the ARIB and ABNT ISDB specs. I understand you keep writing junk for ages, but nevertheless: Do you have any idea what's a BBHEADER (DVB-S2) or PLHEADER (DVB-T2) ? The headers do indicate what MODCOD (aka Modulation/Coding Standard follows, whatever mode ACM, VCM or CCM) follows. These MODCOD foolows a TDM approach with a hierarchial modulation principle. This is exactly what ISDB does too. No, I didn't check DVB-S2/T2 specs deeply enough to understand if they're doing the same thing as ISDB. Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation. It uses a FDM (OFDM is a type of Frequency Division Multiplexing). So, if you're saying that DVB-S2 uses TDM, it is very different than ISDB-T. As DVB-T2 uses an FDM type of modulation (OFDM), it would be possible to segment the carriers there, just like ISDB, or to use TDM hierarchical modulation techniques. And for your info: " The TMCC control information is common to all TMCC carriers and error correction is performed by using difference-set cyclic code." Yes, TMCC carriers are equal and they are always modulated using DBPSK. That is done to make it possible to receive the TMCC carriers even under worse SNR conditions, where it may not be possible to decode the segment groups. It seems that you completely missed the point though. On ISDB-T, the carriers that belong to each group of segments (except for the control carriers - carriers 1 to 107) uses a completely independent modulation. Also, as they're spaced in frequency, the interference of each segment is different. So, error indications are different on each segment. Btw, in any case, the datasheets of ISDB-T demods clearly shows that the BER measures are per segment group (layer). For example, for the BER measures before Viterbi, those are the register names for a certain demod: VBERSNUMA Bit count of BER measurement before Viterbi in A layer VBERSNUMB Bit count of BER measurement before Viterbi in B layer VBERSNUMC Bit count of BER measurement before Viterbi in C layer It has another set of registers for BER after Viterbi, and for PER after Viterbi and RS, for bit count errors, etc. There's no way to get any type of "global" BER measure, simply because ISDB-T demods don't provide. Maybe we should put all this theoretical discussion aside for the moment and think about what is *really* needed by real world applications. As with any receiver, VDR simply wants to have some measure of the signal's "strength" and "quality". These are just two values that should be delivered by each frontend/demux, using the *same* defined and mandatory range. I don't care what exactly that is, but it needs to be the same for all devices. What values a particular driver uses internally to come up with these is of no interest to VDR. The "signal strength" might just be what is currently returned through FE_READ_SIGNAL_STRENGTH (however, normalized to the same range in all drivers, which currently is not the case). The "signal quality" might use flags like FE_HAS_SIGNAL, FE_HAS_CARRIER, FE_HAS_VITERBI, FE_HAS_SYNC, as well as SNR, BER and UNC (if available) to form some value where 0 means no quality at all, and 0x means excellent quality. If a particular frontend/demux uses totally different concepts, it can just use whatever it deems reasonable to form the "strength" and "quality" values. The important thing here is just that a
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On Fri, Jan 4, 2013 at 2:09 AM, Antti Palosaari wrote: > > Manu, here is manual of the professional ISDB-T signal analyzer. Look > especially BER measurement picture from "Slide 10". Sure, it looks so. Just wondering what the TDM stuffing would do after the hierarchial combiner. Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 01/03/2013 09:53 PM, Mauro Carvalho Chehab wrote: Em Fri, 4 Jan 2013 01:02:02 +0530 Manu Abraham escreveu: On Fri, Jan 4, 2013 at 12:57 AM, Mauro Carvalho Chehab wrote: Em Fri, 4 Jan 2013 00:39:25 +0530 Manu Abraham escreveu: Hi Antti, On Thu, Jan 3, 2013 at 9:04 PM, Antti Palosaari wrote: On 01/01/2013 06:48 PM, Manu Abraham wrote: On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab wrote: [RFCv4] dvb: Add DVBv5 properties for quality parameters The DVBv3 quality parameters are limited on several ways: - Doesn't provide any way to indicate the used measure; - Userspace need to guess how to calculate the measure; - Only a limited set of stats are supported; - Doesn't provide QoS measure for the OFDM TPS/TMCC carriers, used to detect the network parameters for DVB-T/ISDB-T; - Can't be called in a way to require them to be filled all at once (atomic reads from the hardware), with may cause troubles on interpreting them on userspace; - On some OFDM delivery systems, the carriers can be independently modulated, having different properties. Currently, there's no way to report per-layer stats; per layer stats is a mythical bird, nothing of that sort does exist. If some driver states that it is simply due to lack of knowledge at the coding side. ISDB-T uses hierarchial modulation, just like DVB-S2 or DVB-T2 Manu, you confused now two concept (which are aimed to resolve same real life problem) - hierarchical coding and multiple transport stream. Both are quite similar on lower level of radio channel, but differs on upper levels. Hierarchical is a little bit weird baby as it remuxes those lower lever radio channels (called layers in case of ISDB-T) to one single mux! That is not really correct. There is one single OFDM channel, the layers are processed via hierarchial separation. Stuffing exists, to maintain constant rate. http://farm9.staticflickr.com/8077/8343296328_e1e375b519_b_d.jpg When rate is constant within the same channel.. (The only case what I can think parameters could be different with a constant rate, is that stuffing frames are unaccounted for. Most likely a bug ?) What did you smoke? That picture has nothing to do with ISDB! ARIB STD – B31 Version 1.6-E2 －17－ Fig. 3-2 shows the basic configuration of the channel coding. It just shows, you understand crap. That is the picture you need to look, not the random one you picked. It clearly shows there that, after the hierarchical coding done by the "Division of TS into hierarchical levels", the TS packets are split into 3 independent channels, each with its own convolutional coding, carrier modulation, etc. This picture shows how each program is split at the FDM sub-carriers: http://en.wikipedia.org/wiki/File:ISDB-T_CH_Seg_Prog_allocation.jpg.svg There, LD programs are at segment 0 (S0). HD programs use 12 segments and SD programs use 4 segments. As each segment group has a different spectrum (as they're using FDM), and are modulated with different encoding schemas (modulation type, FEC, etc), they have different QoS measures. Segment 0 (the one at the center of the spectrum) is less sensitive to inter-channel interference. That's why it is used for LD programs. Cheers, Mauro Manu, here is manual of the professional ISDB-T signal analyzer. Look especially BER measurement picture from "Slide 10". I think you don't bother to say Anritsu MS8901A ISDB-T Digital Broadcast Signal Analyzer, which street price is $20,000, does not know how to measure ISDB-T statistics http://downloadfiles.anritsu.com/Files/en-US/Product-Introductions/Product-Introduction/MS8901A_EL1100.pdf Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On Thu, Jan 3, 2013 at 6:50 PM, Mauro Carvalho Chehab wrote: > Em Wed, 2 Jan 2013 00:38:50 +0530 > Manu Abraham escreveu: > >> On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab >> wrote: >> > Em Tue, 1 Jan 2013 22:18:49 +0530 >> > Manu Abraham escreveu: >> > >> >> On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab >> >> wrote: >> >> >> >> > [RFCv4] dvb: Add DVBv5 properties for quality parameters >> >> > >> >> > The DVBv3 quality parameters are limited on several ways: >> >> > - Doesn't provide any way to indicate the used measure; >> >> > - Userspace need to guess how to calculate the measure; >> >> > - Only a limited set of stats are supported; >> >> > - Doesn't provide QoS measure for the OFDM TPS/TMCC >> >> > carriers, used to detect the network parameters for >> >> > DVB-T/ISDB-T; >> >> > - Can't be called in a way to require them to be filled >> >> > all at once (atomic reads from the hardware), with may >> >> > cause troubles on interpreting them on userspace; >> >> > - On some OFDM delivery systems, the carriers can be >> >> > independently modulated, having different properties. >> >> > Currently, there's no way to report per-layer stats; >> >> >> >> per layer stats is a mythical bird, nothing of that sort does exist. >> > >> > Had you ever read or tried to get stats from an ISDB-T demod? If you >> > had, you would see that it only provides per-layer stats. Btw, this is >> > a requirement to follow the ARIB and ABNT ISDB specs. >> >> I understand you keep writing junk for ages, but nevertheless: >> >> Do you have any idea what's a BBHEADER (DVB-S2) or >> PLHEADER (DVB-T2) ? The headers do indicate what MODCOD >> (aka Modulation/Coding Standard follows, whatever mode ACM, >> VCM or CCM) follows. These MODCOD foolows a TDM approach >> with a hierarchial modulation principle. This is exactly what ISDB >> does too. > > No, I didn't check DVB-S2/T2 specs deeply enough to understand > if they're doing the same thing as ISDB. > > Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation. > It uses a FDM (OFDM is a type of Frequency Division Multiplexing). • ISDB‐T uses a modulation method referred to as Band Segmented OFDM Transmission with Time Interleave. Definition: Time Division Multiplexing (TDM) is the time interleaving of samples from several sources so that the information from these sources can be transmitted serially over a single communication channel. Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Em Fri, 4 Jan 2013 01:02:02 +0530 Manu Abraham escreveu: > On Fri, Jan 4, 2013 at 12:57 AM, Mauro Carvalho Chehab > wrote: > > Em Fri, 4 Jan 2013 00:39:25 +0530 > > Manu Abraham escreveu: > > > >> Hi Antti, > >> > >> On Thu, Jan 3, 2013 at 9:04 PM, Antti Palosaari wrote: > >> > On 01/01/2013 06:48 PM, Manu Abraham wrote: > >> >> > >> >> On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab > >> >> wrote: > >> >> > >> >>> [RFCv4] dvb: Add DVBv5 properties for quality parameters > >> >>> > >> >>> The DVBv3 quality parameters are limited on several ways: > >> >>> - Doesn't provide any way to indicate the used measure; > >> >>> - Userspace need to guess how to calculate the measure; > >> >>> - Only a limited set of stats are supported; > >> >>> - Doesn't provide QoS measure for the OFDM TPS/TMCC > >> >>>carriers, used to detect the network parameters for > >> >>>DVB-T/ISDB-T; > >> >>> - Can't be called in a way to require them to be filled > >> >>>all at once (atomic reads from the hardware), with may > >> >>>cause troubles on interpreting them on userspace; > >> >>> - On some OFDM delivery systems, the carriers can be > >> >>>independently modulated, having different properties. > >> >>>Currently, there's no way to report per-layer stats; > >> >> > >> >> > >> >> per layer stats is a mythical bird, nothing of that sort does exist. If > >> >> some > >> >> driver states that it is simply due to lack of knowledge at the coding > >> >> side. > >> >> > >> >> ISDB-T uses hierarchial modulation, just like DVB-S2 or DVB-T2 > >> > > >> > > >> > Manu, you confused now two concept (which are aimed to resolve same real > >> > life problem) - hierarchical coding and multiple transport stream. Both > >> > are > >> > quite similar on lower level of radio channel, but differs on upper > >> > levels. > >> > > >> > Hierarchical is a little bit weird baby as it remuxes those lower lever > >> > radio channels (called layers in case of ISDB-T) to one single mux! > >> > >> That is not really correct. There is one single OFDM channel, the layers > >> are processed via hierarchial separation. Stuffing exists, to maintain > >> constant rate. > >> > >> http://farm9.staticflickr.com/8077/8343296328_e1e375b519_b_d.jpg > >> > >> When rate is constant within the same channel.. > >> (The only case what I can think parameters could be different with a > >> constant rate, > >> is that stuffing frames are unaccounted for. Most likely a bug ?) > > > > What did you smoke? That picture has nothing to do with ISDB! > > > > ARIB STD – B31 > Version 1.6-E2 > －17－ > Fig. 3-2 shows the basic configuration of the channel coding. > > It just shows, you understand crap. That is the picture you need to look, not the random one you picked. It clearly shows there that, after the hierarchical coding done by the "Division of TS into hierarchical levels", the TS packets are split into 3 independent channels, each with its own convolutional coding, carrier modulation, etc. This picture shows how each program is split at the FDM sub-carriers: http://en.wikipedia.org/wiki/File:ISDB-T_CH_Seg_Prog_allocation.jpg.svg There, LD programs are at segment 0 (S0). HD programs use 12 segments and SD programs use 4 segments. As each segment group has a different spectrum (as they're using FDM), and are modulated with different encoding schemas (modulation type, FEC, etc), they have different QoS measures. Segment 0 (the one at the center of the spectrum) is less sensitive to inter-channel interference. That's why it is used for LD programs. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On Fri, Jan 4, 2013 at 12:57 AM, Mauro Carvalho Chehab wrote: > Em Fri, 4 Jan 2013 00:39:25 +0530 > Manu Abraham escreveu: > >> Hi Antti, >> >> On Thu, Jan 3, 2013 at 9:04 PM, Antti Palosaari wrote: >> > On 01/01/2013 06:48 PM, Manu Abraham wrote: >> >> >> >> On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab >> >> wrote: >> >> >> >>> [RFCv4] dvb: Add DVBv5 properties for quality parameters >> >>> >> >>> The DVBv3 quality parameters are limited on several ways: >> >>> - Doesn't provide any way to indicate the used measure; >> >>> - Userspace need to guess how to calculate the measure; >> >>> - Only a limited set of stats are supported; >> >>> - Doesn't provide QoS measure for the OFDM TPS/TMCC >> >>>carriers, used to detect the network parameters for >> >>>DVB-T/ISDB-T; >> >>> - Can't be called in a way to require them to be filled >> >>>all at once (atomic reads from the hardware), with may >> >>>cause troubles on interpreting them on userspace; >> >>> - On some OFDM delivery systems, the carriers can be >> >>>independently modulated, having different properties. >> >>>Currently, there's no way to report per-layer stats; >> >> >> >> >> >> per layer stats is a mythical bird, nothing of that sort does exist. If >> >> some >> >> driver states that it is simply due to lack of knowledge at the coding >> >> side. >> >> >> >> ISDB-T uses hierarchial modulation, just like DVB-S2 or DVB-T2 >> > >> > >> > Manu, you confused now two concept (which are aimed to resolve same real >> > life problem) - hierarchical coding and multiple transport stream. Both are >> > quite similar on lower level of radio channel, but differs on upper levels. >> > >> > Hierarchical is a little bit weird baby as it remuxes those lower lever >> > radio channels (called layers in case of ISDB-T) to one single mux! >> >> That is not really correct. There is one single OFDM channel, the layers >> are processed via hierarchial separation. Stuffing exists, to maintain >> constant rate. >> >> http://farm9.staticflickr.com/8077/8343296328_e1e375b519_b_d.jpg >> >> When rate is constant within the same channel.. >> (The only case what I can think parameters could be different with a >> constant rate, >> is that stuffing frames are unaccounted for. Most likely a bug ?) > > What did you smoke? That picture has nothing to do with ISDB! > ARIB STD – B31 Version 1.6-E2 －17－ Fig. 3-2 shows the basic configuration of the channel coding. It just shows, you understand crap. Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Em Fri, 4 Jan 2013 00:39:25 +0530 Manu Abraham escreveu: > Hi Antti, > > On Thu, Jan 3, 2013 at 9:04 PM, Antti Palosaari wrote: > > On 01/01/2013 06:48 PM, Manu Abraham wrote: > >> > >> On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab > >> wrote: > >> > >>> [RFCv4] dvb: Add DVBv5 properties for quality parameters > >>> > >>> The DVBv3 quality parameters are limited on several ways: > >>> - Doesn't provide any way to indicate the used measure; > >>> - Userspace need to guess how to calculate the measure; > >>> - Only a limited set of stats are supported; > >>> - Doesn't provide QoS measure for the OFDM TPS/TMCC > >>>carriers, used to detect the network parameters for > >>>DVB-T/ISDB-T; > >>> - Can't be called in a way to require them to be filled > >>>all at once (atomic reads from the hardware), with may > >>>cause troubles on interpreting them on userspace; > >>> - On some OFDM delivery systems, the carriers can be > >>>independently modulated, having different properties. > >>>Currently, there's no way to report per-layer stats; > >> > >> > >> per layer stats is a mythical bird, nothing of that sort does exist. If > >> some > >> driver states that it is simply due to lack of knowledge at the coding > >> side. > >> > >> ISDB-T uses hierarchial modulation, just like DVB-S2 or DVB-T2 > > > > > > Manu, you confused now two concept (which are aimed to resolve same real > > life problem) - hierarchical coding and multiple transport stream. Both are > > quite similar on lower level of radio channel, but differs on upper levels. > > > > Hierarchical is a little bit weird baby as it remuxes those lower lever > > radio channels (called layers in case of ISDB-T) to one single mux! > > That is not really correct. There is one single OFDM channel, the layers > are processed via hierarchial separation. Stuffing exists, to maintain > constant rate. > > http://farm9.staticflickr.com/8077/8343296328_e1e375b519_b_d.jpg > > When rate is constant within the same channel.. > (The only case what I can think parameters could be different with a > constant rate, > is that stuffing frames are unaccounted for. Most likely a bug ?) What did you smoke? That picture has nothing to do with ISDB! ISDB not only does hierarchical split. It also splits the OFDM carriers into 3 layers, each layer with its own modulation, guard interval, inner FEC, etc. Each of those layers behave as an independent channel, providing different bit rates. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Hi Antti, On Thu, Jan 3, 2013 at 9:04 PM, Antti Palosaari wrote: > On 01/01/2013 06:48 PM, Manu Abraham wrote: >> >> On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab >> wrote: >> >>> [RFCv4] dvb: Add DVBv5 properties for quality parameters >>> >>> The DVBv3 quality parameters are limited on several ways: >>> - Doesn't provide any way to indicate the used measure; >>> - Userspace need to guess how to calculate the measure; >>> - Only a limited set of stats are supported; >>> - Doesn't provide QoS measure for the OFDM TPS/TMCC >>>carriers, used to detect the network parameters for >>>DVB-T/ISDB-T; >>> - Can't be called in a way to require them to be filled >>>all at once (atomic reads from the hardware), with may >>>cause troubles on interpreting them on userspace; >>> - On some OFDM delivery systems, the carriers can be >>>independently modulated, having different properties. >>>Currently, there's no way to report per-layer stats; >> >> >> per layer stats is a mythical bird, nothing of that sort does exist. If >> some >> driver states that it is simply due to lack of knowledge at the coding >> side. >> >> ISDB-T uses hierarchial modulation, just like DVB-S2 or DVB-T2 > > > Manu, you confused now two concept (which are aimed to resolve same real > life problem) - hierarchical coding and multiple transport stream. Both are > quite similar on lower level of radio channel, but differs on upper levels. > > Hierarchical is a little bit weird baby as it remuxes those lower lever > radio channels (called layers in case of ISDB-T) to one single mux! That is not really correct. There is one single OFDM channel, the layers are processed via hierarchial separation. Stuffing exists, to maintain constant rate. http://farm9.staticflickr.com/8077/8343296328_e1e375b519_b_d.jpg When rate is constant within the same channel.. (The only case what I can think parameters could be different with a constant rate, is that stuffing frames are unaccounted for. Most likely a bug ?) Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Em Thu, 3 Jan 2013 14:14:29 -0200 Mauro Carvalho Chehab escreveu: > Em Thu, 03 Jan 2013 16:18:26 +0100 > Klaus Schmidinger escreveu: > > > On 03.01.2013 14:20, Mauro Carvalho Chehab wrote: > > > Em Wed, 2 Jan 2013 00:38:50 +0530 > > > Manu Abraham escreveu: > > > > > >> On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab > > >> wrote: > > >>> Em Tue, 1 Jan 2013 22:18:49 +0530 > > >>> Manu Abraham escreveu: > > >>> > > On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab > > wrote: > > > > > [RFCv4] dvb: Add DVBv5 properties for quality parameters > > > > > > The DVBv3 quality parameters are limited on several ways: > > > - Doesn't provide any way to indicate the used measure; > > > - Userspace need to guess how to calculate the measure; > > > - Only a limited set of stats are supported; > > > - Doesn't provide QoS measure for the OFDM TPS/TMCC > > >carriers, used to detect the network parameters for > > >DVB-T/ISDB-T; > > > - Can't be called in a way to require them to be filled > > >all at once (atomic reads from the hardware), with may > > >cause troubles on interpreting them on userspace; > > > - On some OFDM delivery systems, the carriers can be > > >independently modulated, having different properties. > > >Currently, there's no way to report per-layer stats; > > > > per layer stats is a mythical bird, nothing of that sort does exist. > > >>> > > >>> Had you ever read or tried to get stats from an ISDB-T demod? If you > > >>> had, you would see that it only provides per-layer stats. Btw, this is > > >>> a requirement to follow the ARIB and ABNT ISDB specs. > > >> > > >> I understand you keep writing junk for ages, but nevertheless: > > >> > > >> Do you have any idea what's a BBHEADER (DVB-S2) or > > >> PLHEADER (DVB-T2) ? The headers do indicate what MODCOD > > >> (aka Modulation/Coding Standard follows, whatever mode ACM, > > >> VCM or CCM) follows. These MODCOD foolows a TDM approach > > >> with a hierarchial modulation principle. This is exactly what ISDB > > >> does too. > > > > > > No, I didn't check DVB-S2/T2 specs deeply enough to understand > > > if they're doing the same thing as ISDB. > > > > > > Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation. > > > It uses a FDM (OFDM is a type of Frequency Division Multiplexing). > > > > > > So, if you're saying that DVB-S2 uses TDM, it is very different than > > > ISDB-T. As DVB-T2 uses an FDM type of modulation (OFDM), it would > > > be possible to segment the carriers there, just like ISDB, or to > > > use TDM hierarchical modulation techniques. > > > > > >> > > >> And for your info: > > >> > > >> " The TMCC control information is > > >> common to all TMCC carriers and > > >> error correction is performed by using > > >> difference-set cyclic code." > > > > > > Yes, TMCC carriers are equal and they are always modulated using DBPSK. > > > That is done to make it possible to receive the TMCC carriers even under > > > worse SNR conditions, where it may not be possible to decode the segment > > > groups. > > > > > > It seems that you completely missed the point though. On ISDB-T, the > > > carriers that belong to each group of segments (except for the control > > > carriers - carriers 1 to 107) uses a completely independent modulation. > > > Also, as they're spaced in frequency, the interference of each segment > > > is different. So, error indications are different on each segment. > > > > > > Btw, in any case, the datasheets of ISDB-T demods clearly shows that > > > the BER measures are per segment group (layer). > > > > > > For example, for the BER measures before Viterbi, those are the register > > > names for a certain demod: > > > > > > VBERSNUMA Bit count of BER measurement before Viterbi in A layer > > > VBERSNUMB Bit count of BER measurement before Viterbi in B layer > > > VBERSNUMC Bit count of BER measurement before Viterbi in C layer > > > > > > It has another set of registers for BER after Viterbi, and for PER after > > > Viterbi and RS, for bit count errors, etc. > > > > > > There's no way to get any type of "global" BER measure, simply because > > > ISDB-T demods don't provide. > > > > Maybe we should put all this theoretical discussion aside for the moment and > > think about what is *really* needed by real world applications. As with any > > receiver, VDR simply wants to have some measure of the signal's "strength" > > and "quality". These are just two values that should be delivered by each > > frontend/demux, using the *same* defined and mandatory range. I don't care > > what exactly that is, but it needs to be the same for all devices. > > What values a particular driver uses internally to come up with these > > is of no interest to VDR. The "signal strength" might just be what is > > current
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Em Thu, 03 Jan 2013 16:18:26 +0100 Klaus Schmidinger escreveu: > On 03.01.2013 14:20, Mauro Carvalho Chehab wrote: > > Em Wed, 2 Jan 2013 00:38:50 +0530 > > Manu Abraham escreveu: > > > >> On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab > >> wrote: > >>> Em Tue, 1 Jan 2013 22:18:49 +0530 > >>> Manu Abraham escreveu: > >>> > On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab > wrote: > > > [RFCv4] dvb: Add DVBv5 properties for quality parameters > > > > The DVBv3 quality parameters are limited on several ways: > > - Doesn't provide any way to indicate the used measure; > > - Userspace need to guess how to calculate the measure; > > - Only a limited set of stats are supported; > > - Doesn't provide QoS measure for the OFDM TPS/TMCC > >carriers, used to detect the network parameters for > >DVB-T/ISDB-T; > > - Can't be called in a way to require them to be filled > >all at once (atomic reads from the hardware), with may > >cause troubles on interpreting them on userspace; > > - On some OFDM delivery systems, the carriers can be > >independently modulated, having different properties. > >Currently, there's no way to report per-layer stats; > > per layer stats is a mythical bird, nothing of that sort does exist. > >>> > >>> Had you ever read or tried to get stats from an ISDB-T demod? If you > >>> had, you would see that it only provides per-layer stats. Btw, this is > >>> a requirement to follow the ARIB and ABNT ISDB specs. > >> > >> I understand you keep writing junk for ages, but nevertheless: > >> > >> Do you have any idea what's a BBHEADER (DVB-S2) or > >> PLHEADER (DVB-T2) ? The headers do indicate what MODCOD > >> (aka Modulation/Coding Standard follows, whatever mode ACM, > >> VCM or CCM) follows. These MODCOD foolows a TDM approach > >> with a hierarchial modulation principle. This is exactly what ISDB > >> does too. > > > > No, I didn't check DVB-S2/T2 specs deeply enough to understand > > if they're doing the same thing as ISDB. > > > > Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation. > > It uses a FDM (OFDM is a type of Frequency Division Multiplexing). > > > > So, if you're saying that DVB-S2 uses TDM, it is very different than > > ISDB-T. As DVB-T2 uses an FDM type of modulation (OFDM), it would > > be possible to segment the carriers there, just like ISDB, or to > > use TDM hierarchical modulation techniques. > > > >> > >> And for your info: > >> > >> " The TMCC control information is > >> common to all TMCC carriers and > >> error correction is performed by using > >> difference-set cyclic code." > > > > Yes, TMCC carriers are equal and they are always modulated using DBPSK. > > That is done to make it possible to receive the TMCC carriers even under > > worse SNR conditions, where it may not be possible to decode the segment > > groups. > > > > It seems that you completely missed the point though. On ISDB-T, the > > carriers that belong to each group of segments (except for the control > > carriers - carriers 1 to 107) uses a completely independent modulation. > > Also, as they're spaced in frequency, the interference of each segment > > is different. So, error indications are different on each segment. > > > > Btw, in any case, the datasheets of ISDB-T demods clearly shows that > > the BER measures are per segment group (layer). > > > > For example, for the BER measures before Viterbi, those are the register > > names for a certain demod: > > > > VBERSNUMA Bit count of BER measurement before Viterbi in A layer > > VBERSNUMB Bit count of BER measurement before Viterbi in B layer > > VBERSNUMC Bit count of BER measurement before Viterbi in C layer > > > > It has another set of registers for BER after Viterbi, and for PER after > > Viterbi and RS, for bit count errors, etc. > > > > There's no way to get any type of "global" BER measure, simply because > > ISDB-T demods don't provide. > > Maybe we should put all this theoretical discussion aside for the moment and > think about what is *really* needed by real world applications. As with any > receiver, VDR simply wants to have some measure of the signal's "strength" > and "quality". These are just two values that should be delivered by each > frontend/demux, using the *same* defined and mandatory range. I don't care > what exactly that is, but it needs to be the same for all devices. > What values a particular driver uses internally to come up with these > is of no interest to VDR. The "signal strength" might just be what is > currently returned through FE_READ_SIGNAL_STRENGTH (however, normalized to > the same range in all drivers, which currently is not the case). The "signal > quality" might use flags like FE_HAS_SIGNAL, FE_HAS_CARRIER, FE_HAS_VITERBI, > FE_HAS_SYNC, as well as SNR, BER and
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 01/01/2013 06:48 PM, Manu Abraham wrote: On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab wrote: [RFCv4] dvb: Add DVBv5 properties for quality parameters The DVBv3 quality parameters are limited on several ways: - Doesn't provide any way to indicate the used measure; - Userspace need to guess how to calculate the measure; - Only a limited set of stats are supported; - Doesn't provide QoS measure for the OFDM TPS/TMCC carriers, used to detect the network parameters for DVB-T/ISDB-T; - Can't be called in a way to require them to be filled all at once (atomic reads from the hardware), with may cause troubles on interpreting them on userspace; - On some OFDM delivery systems, the carriers can be independently modulated, having different properties. Currently, there's no way to report per-layer stats; per layer stats is a mythical bird, nothing of that sort does exist. If some driver states that it is simply due to lack of knowledge at the coding side. ISDB-T uses hierarchial modulation, just like DVB-S2 or DVB-T2 Manu, you confused now two concept (which are aimed to resolve same real life problem) - hierarchical coding and multiple transport stream. Both are quite similar on lower level of radio channel, but differs on upper levels. Hierarchical is a little bit weird baby as it remuxes those lower lever radio channels (called layers in case of ISDB-T) to one single mux! There is only single TS which demodulator is responsible to remux all those 3 physical "layer" channels, which could be modulated differently. So after demodulation you really has a TS which contains stream that has different statistics. That's opposite to compared for multiple TS principle used for DVB-T2/S2. In case of multiple TS you have same statistics for whole TS (but naturally there could be multiple TS after demodulation). regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 03.01.2013 14:20, Mauro Carvalho Chehab wrote: Em Wed, 2 Jan 2013 00:38:50 +0530 Manu Abraham escreveu: On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab wrote: Em Tue, 1 Jan 2013 22:18:49 +0530 Manu Abraham escreveu: On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab wrote: [RFCv4] dvb: Add DVBv5 properties for quality parameters The DVBv3 quality parameters are limited on several ways: - Doesn't provide any way to indicate the used measure; - Userspace need to guess how to calculate the measure; - Only a limited set of stats are supported; - Doesn't provide QoS measure for the OFDM TPS/TMCC carriers, used to detect the network parameters for DVB-T/ISDB-T; - Can't be called in a way to require them to be filled all at once (atomic reads from the hardware), with may cause troubles on interpreting them on userspace; - On some OFDM delivery systems, the carriers can be independently modulated, having different properties. Currently, there's no way to report per-layer stats; per layer stats is a mythical bird, nothing of that sort does exist. Had you ever read or tried to get stats from an ISDB-T demod? If you had, you would see that it only provides per-layer stats. Btw, this is a requirement to follow the ARIB and ABNT ISDB specs. I understand you keep writing junk for ages, but nevertheless: Do you have any idea what's a BBHEADER (DVB-S2) or PLHEADER (DVB-T2) ? The headers do indicate what MODCOD (aka Modulation/Coding Standard follows, whatever mode ACM, VCM or CCM) follows. These MODCOD foolows a TDM approach with a hierarchial modulation principle. This is exactly what ISDB does too. No, I didn't check DVB-S2/T2 specs deeply enough to understand if they're doing the same thing as ISDB. Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation. It uses a FDM (OFDM is a type of Frequency Division Multiplexing). So, if you're saying that DVB-S2 uses TDM, it is very different than ISDB-T. As DVB-T2 uses an FDM type of modulation (OFDM), it would be possible to segment the carriers there, just like ISDB, or to use TDM hierarchical modulation techniques. And for your info: " The TMCC control information is common to all TMCC carriers and error correction is performed by using difference-set cyclic code." Yes, TMCC carriers are equal and they are always modulated using DBPSK. That is done to make it possible to receive the TMCC carriers even under worse SNR conditions, where it may not be possible to decode the segment groups. It seems that you completely missed the point though. On ISDB-T, the carriers that belong to each group of segments (except for the control carriers - carriers 1 to 107) uses a completely independent modulation. Also, as they're spaced in frequency, the interference of each segment is different. So, error indications are different on each segment. Btw, in any case, the datasheets of ISDB-T demods clearly shows that the BER measures are per segment group (layer). For example, for the BER measures before Viterbi, those are the register names for a certain demod: VBERSNUMA Bit count of BER measurement before Viterbi in A layer VBERSNUMB Bit count of BER measurement before Viterbi in B layer VBERSNUMC Bit count of BER measurement before Viterbi in C layer It has another set of registers for BER after Viterbi, and for PER after Viterbi and RS, for bit count errors, etc. There's no way to get any type of "global" BER measure, simply because ISDB-T demods don't provide. Maybe we should put all this theoretical discussion aside for the moment and think about what is *really* needed by real world applications. As with any receiver, VDR simply wants to have some measure of the signal's "strength" and "quality". These are just two values that should be delivered by each frontend/demux, using the *same* defined and mandatory range. I don't care what exactly that is, but it needs to be the same for all devices. What values a particular driver uses internally to come up with these is of no interest to VDR. The "signal strength" might just be what is currently returned through FE_READ_SIGNAL_STRENGTH (however, normalized to the same range in all drivers, which currently is not the case). The "signal quality" might use flags like FE_HAS_SIGNAL, FE_HAS_CARRIER, FE_HAS_VITERBI, FE_HAS_SYNC, as well as SNR, BER and UNC (if available) to form some value where 0 means no quality at all, and 0x means excellent quality. If a particular frontend/demux uses totally different concepts, it can just use whatever it deems reasonable to form the "strength" and "quality" values. The important thing here is just that all this needs to be hidden inside the driver, and the only interface to an application are ioctl() calls that return these two values. So I suggest that you define this minimal interface and allow app
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Em Wed, 2 Jan 2013 00:38:50 +0530 Manu Abraham escreveu: > On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab > wrote: > > Em Tue, 1 Jan 2013 22:18:49 +0530 > > Manu Abraham escreveu: > > > >> On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab > >> wrote: > >> > >> > [RFCv4] dvb: Add DVBv5 properties for quality parameters > >> > > >> > The DVBv3 quality parameters are limited on several ways: > >> > - Doesn't provide any way to indicate the used measure; > >> > - Userspace need to guess how to calculate the measure; > >> > - Only a limited set of stats are supported; > >> > - Doesn't provide QoS measure for the OFDM TPS/TMCC > >> > carriers, used to detect the network parameters for > >> > DVB-T/ISDB-T; > >> > - Can't be called in a way to require them to be filled > >> > all at once (atomic reads from the hardware), with may > >> > cause troubles on interpreting them on userspace; > >> > - On some OFDM delivery systems, the carriers can be > >> > independently modulated, having different properties. > >> > Currently, there's no way to report per-layer stats; > >> > >> per layer stats is a mythical bird, nothing of that sort does exist. > > > > Had you ever read or tried to get stats from an ISDB-T demod? If you > > had, you would see that it only provides per-layer stats. Btw, this is > > a requirement to follow the ARIB and ABNT ISDB specs. > > I understand you keep writing junk for ages, but nevertheless: > > Do you have any idea what's a BBHEADER (DVB-S2) or > PLHEADER (DVB-T2) ? The headers do indicate what MODCOD > (aka Modulation/Coding Standard follows, whatever mode ACM, > VCM or CCM) follows. These MODCOD foolows a TDM approach > with a hierarchial modulation principle. This is exactly what ISDB > does too. No, I didn't check DVB-S2/T2 specs deeply enough to understand if they're doing the same thing as ISDB. Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation. It uses a FDM (OFDM is a type of Frequency Division Multiplexing). So, if you're saying that DVB-S2 uses TDM, it is very different than ISDB-T. As DVB-T2 uses an FDM type of modulation (OFDM), it would be possible to segment the carriers there, just like ISDB, or to use TDM hierarchical modulation techniques. > > And for your info: > > " The TMCC control information is > common to all TMCC carriers and > error correction is performed by using > difference-set cyclic code." Yes, TMCC carriers are equal and they are always modulated using DBPSK. That is done to make it possible to receive the TMCC carriers even under worse SNR conditions, where it may not be possible to decode the segment groups. It seems that you completely missed the point though. On ISDB-T, the carriers that belong to each group of segments (except for the control carriers - carriers 1 to 107) uses a completely independent modulation. Also, as they're spaced in frequency, the interference of each segment is different. So, error indications are different on each segment. Btw, in any case, the datasheets of ISDB-T demods clearly shows that the BER measures are per segment group (layer). For example, for the BER measures before Viterbi, those are the register names for a certain demod: VBERSNUMA Bit count of BER measurement before Viterbi in A layer VBERSNUMB Bit count of BER measurement before Viterbi in B layer VBERSNUMC Bit count of BER measurement before Viterbi in C layer It has another set of registers for BER after Viterbi, and for PER after Viterbi and RS, for bit count errors, etc. There's no way to get any type of "global" BER measure, simply because ISDB-T demods don't provide. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab wrote: > Em Tue, 1 Jan 2013 22:18:49 +0530 > Manu Abraham escreveu: > >> On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab >> wrote: >> >> > [RFCv4] dvb: Add DVBv5 properties for quality parameters >> > >> > The DVBv3 quality parameters are limited on several ways: >> > - Doesn't provide any way to indicate the used measure; >> > - Userspace need to guess how to calculate the measure; >> > - Only a limited set of stats are supported; >> > - Doesn't provide QoS measure for the OFDM TPS/TMCC >> > carriers, used to detect the network parameters for >> > DVB-T/ISDB-T; >> > - Can't be called in a way to require them to be filled >> > all at once (atomic reads from the hardware), with may >> > cause troubles on interpreting them on userspace; >> > - On some OFDM delivery systems, the carriers can be >> > independently modulated, having different properties. >> > Currently, there's no way to report per-layer stats; >> >> per layer stats is a mythical bird, nothing of that sort does exist. > > Had you ever read or tried to get stats from an ISDB-T demod? If you > had, you would see that it only provides per-layer stats. Btw, this is > a requirement to follow the ARIB and ABNT ISDB specs. I understand you keep writing junk for ages, but nevertheless: Do you have any idea what's a BBHEADER (DVB-S2) or PLHEADER (DVB-T2) ? The headers do indicate what MODCOD (aka Modulation/Coding Standard follows, whatever mode ACM, VCM or CCM) follows. These MODCOD foolows a TDM approach with a hierarchial modulation principle. This is exactly what ISDB does too. And for your info: " The TMCC control information is common to all TMCC carriers and error correction is performed by using difference-set cyclic code." Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Em Tue, 1 Jan 2013 22:18:49 +0530 Manu Abraham escreveu: > On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab > wrote: > > > [RFCv4] dvb: Add DVBv5 properties for quality parameters > > > > The DVBv3 quality parameters are limited on several ways: > > - Doesn't provide any way to indicate the used measure; > > - Userspace need to guess how to calculate the measure; > > - Only a limited set of stats are supported; > > - Doesn't provide QoS measure for the OFDM TPS/TMCC > > carriers, used to detect the network parameters for > > DVB-T/ISDB-T; > > - Can't be called in a way to require them to be filled > > all at once (atomic reads from the hardware), with may > > cause troubles on interpreting them on userspace; > > - On some OFDM delivery systems, the carriers can be > > independently modulated, having different properties. > > Currently, there's no way to report per-layer stats; > > per layer stats is a mythical bird, nothing of that sort does exist. Had you ever read or tried to get stats from an ISDB-T demod? If you had, you would see that it only provides per-layer stats. Btw, this is a requirement to follow the ARIB and ABNT ISDB specs. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab wrote: > [RFCv4] dvb: Add DVBv5 properties for quality parameters > > The DVBv3 quality parameters are limited on several ways: > - Doesn't provide any way to indicate the used measure; > - Userspace need to guess how to calculate the measure; > - Only a limited set of stats are supported; > - Doesn't provide QoS measure for the OFDM TPS/TMCC > carriers, used to detect the network parameters for > DVB-T/ISDB-T; > - Can't be called in a way to require them to be filled > all at once (atomic reads from the hardware), with may > cause troubles on interpreting them on userspace; > - On some OFDM delivery systems, the carriers can be > independently modulated, having different properties. > Currently, there's no way to report per-layer stats; per layer stats is a mythical bird, nothing of that sort does exist. If some driver states that it is simply due to lack of knowledge at the coding side. ISDB-T uses hierarchial modulation, just like DVB-S2 or DVB-T2 Once the Outer code is decoded, the OFDM segments are separated using Hierarchial separation. This is well described by NHK. "To improve mobile reception and robustness to multipath interference, the system performs, in symbol units, time interleaving plus frequency interleaving according to the arrangement of OFDM segments. Pilot signals for demodulation and control symbols consisting of TMCC information are combined with information symbols to an OFDM frame. Here, information symbols are modulated by Differential Binary Phase Shift Keying (DBPSK) and guard intervals are added at the IFFT output. [3] Hierarchical transmission A mixture of fixed-reception programs and mobile reception programs in the transmission system is made possible through the application of hierarchical transmission achieved by band division within a channel. "Hierarchical transmission" means that the three elements of channel coding, namely, the modulation system, the coding rate of convolutional correction code, and the time interleave length, can be independently set. Time and frequency interleaving are each performed in their respective hierarchical data segment. As described earlier, the smallest hierarchical unit in a frequency spectrum is one OFDM segment." Please don't muck up existing working things with uber crap. Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Em Sat, 29 Dec 2012 11:36:16 -0500
Devin Heitmueller escreveu:
> On Fri, Dec 28, 2012 at 6:56 PM, Mauro Carvalho Chehab
> wrote:
> > The DVBv3 quality parameters are limited on several ways:
> > - Doesn't provide any way to indicate the used measure;
> > - Userspace need to guess how to calculate the measure;
> > - Only a limited set of stats are supported;
> > - Doesn't provide QoS measure for the OFDM TPS/TMCC
> > carriers, used to detect the network parameters for
> > DVB-T/ISDB-T;
> > - Can't be called in a way to require them to be filled
> > all at once (atomic reads from the hardware), with may
> > cause troubles on interpreting them on userspace;
> > - On some OFDM delivery systems, the carriers can be
> > independently modulated, having different properties.
> > Currently, there's no way to report per-layer stats;
> > This RFC adds the header definitions meant to solve that issues.
> > After discussed, I'll write a patch for the DocBook and add support
> > for it on some demods. Support for dvbv5-zap and dvbv5-scan tools
> > will also have support for those features.
>
> Hi Mauro,
<...>
> You have a units field which is "decibels", but in what unit? 1 dB /
> unit? 0.1 db / unit? 1/255 db / unit? This particular issue is why
> the current snr field varies across even demods where we have the
> datasheets. Many demods reported in 0.1 dB increments, while others
> reported in 1/255 dB increments.
There was min/max values there to allow userspace to calculate the scale,
but it seems simpler to just define a 0.1dB step.
<...>
> This needs to be defined *in the spec*,
Sure. After we agree on the API we'll be using, I'll write the spec bits
and add the logic on a driver. I did that in the past, but as the discussions
were long and no consensus was reached. So, I opted to just write the changes
at the frontend.h for the discussons.
<...>
Ok, I decided to post a version 4, removing the things that I won't be using
(that got inherited by a previous proposal from another developer sent to
the ML a few years ago).
This version defines 4 types of statistics: signal, SNR, BER, error count
at the TMCC/TPS carrier. There are just 2 possible ranges:
dB (actually 0.1 dB);
percentage, from 0 to 100%.
There's a third "range" type that means that a given parameter is not
available. I didn't add any bits to indicate why, as the reason may not
be relevant to userspace. It might make sense to have different types, one
for temporary unavailability and another one for permanent unavailability.
There's also one parameter to enumerate what QoS parameters are supported by
the driver.
Regards,
Mauro
-
[RFCv4] dvb: Add DVBv5 properties for quality parameters
The DVBv3 quality parameters are limited on several ways:
- Doesn't provide any way to indicate the used measure;
- Userspace need to guess how to calculate the measure;
- Only a limited set of stats are supported;
- Doesn't provide QoS measure for the OFDM TPS/TMCC
carriers, used to detect the network parameters for
DVB-T/ISDB-T;
- Can't be called in a way to require them to be filled
all at once (atomic reads from the hardware), with may
cause troubles on interpreting them on userspace;
- On some OFDM delivery systems, the carriers can be
independently modulated, having different properties.
Currently, there's no way to report per-layer stats;
This RFC adds the header definitions meant to solve that issues.
After discussed, I'll write a patch for the DocBook and add support
for it on some demods. Support for dvbv5-zap and dvbv5-scan tools
will also have support for those features.
Signed-off-by: Mauro Carvalho Chehab
---
include/uapi/linux/dvb/frontend.h | 78 ++-
include/uapi/linux/dvb/frontend.h | 60 +-
1 file changed, 59 insertions(+), 1 deletion(-)
v3: Just update http://patchwork.linuxtv.org/patch/9578/ to current tip
v4: API simplified and addressed some issues pointed by Devin
--- patchwork.orig/include/uapi/linux/dvb/frontend.h
+++ patchwork/include/uapi/linux/dvb/frontend.h
@@ -365,7 +365,14 @@ struct dvb_frontend_event {
#define DTV_INTERLEAVING 60
#define DTV_LNA61
-#define DTV_MAX_COMMANDDTV_LNA
+/* Quality parameters */
+#define DTV_ENUM_QUALITY 62 /* Enumerates supported QoS parameters
*/
+#define DTV_FE_SIGNAL 63 /* Signal strength at the demod */
+#define DTV_QUALITY_SNR64 /* Signal/Noise ratio */
+#define DTV_ERROR_BER 65 /* Bit error rate since signal lock */
+#define DTV_ERROR_COUNT66 /* Monotonic error count since
signal lock at TMCC or TPS carrier
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Em Sat, 29 Dec 2012 18:49:21 +0100 Klaus Schmidinger escreveu: > On 29.12.2012 17:36, Devin Heitmueller wrote: > > On Fri, Dec 28, 2012 at 6:56 PM, Mauro Carvalho Chehab > > wrote: > >> The DVBv3 quality parameters are limited on several ways: > >> - Doesn't provide any way to indicate the used measure; > >> - Userspace need to guess how to calculate the measure; > >> - Only a limited set of stats are supported; > >> - Doesn't provide QoS measure for the OFDM TPS/TMCC > >>carriers, used to detect the network parameters for > >>DVB-T/ISDB-T; > >> - Can't be called in a way to require them to be filled > >>all at once (atomic reads from the hardware), with may > >>cause troubles on interpreting them on userspace; > >> - On some OFDM delivery systems, the carriers can be > >>independently modulated, having different properties. > >>Currently, there's no way to report per-layer stats; > >> This RFC adds the header definitions meant to solve that issues. > >> After discussed, I'll write a patch for the DocBook and add support > >> for it on some demods. Support for dvbv5-zap and dvbv5-scan tools > >> will also have support for those features. > > > > Hi Mauro, > > > > As I've told you multiple times in the past, where this proposal falls > > apart is in its complete lack of specificity for real world scenarios. > > > > You have a units field which is "decibels", but in what unit? 1 dB / > > unit? 0.1 db / unit? 1/255 db / unit? This particular issue is why > > the current snr field varies across even demods where we have the > > datasheets. Many demods reported in 0.1 dB increments, while others > > reported in 1/255 dB increments. > > > > What happens when you ask for the SNR field when there is so signal > > lock (on most demods the SNR registers return garbage in this case)? > > What is the return value to userland? What happens when the data is > > unavailable for some other reason? What happens when you have group > > of statistics being asked for in a single call and *one* of them > > cannot be provided for some reason (in which case you cannot rely on a > > simple errno value since it doesn't apply to the entire call)? > > > > You need to take a step back and think about this from an application > > implementors standpoint. Most app developers for the existing apps > > look to show two data points: a signal indicator (0-100%), and some > > form of SNR (usually in dB, plotted on a scale where something like 40 > > dB=100% [of course this max varies by modulation type]). What would I > > need to do with the data you've provided to show that info? Do I > > really need to be a background in signal theory and understand the > > difference between SNR and CNR in order to tell the user how good his > > signal is? > > > > Since as an app developer I typically only have one or two tuners, how > > the hell am I supposed to write a piece of code that shows those two > > pieces of information given the huge number of different combinations > > of data types that demods could return given the proposed API? > > > > We have similar issues for UNC/BER values. Is the value returned the > > number of errors since the last time the application asked? Is it the > > number of errors in the last two seconds? Is it the number of errors > > since I reached signal lock? Does asking for the value clear out the > > counter? How do we handle the case where I asked for the data for the > > first time ten minutes after I reached signal lock? Are drivers > > internally supposed to be polling the register and updating the > > counters even when the application doesn't ask for the data (to handle > > cases where the demod's registers only have an error count for the > > last second's worth of data)? > > > > And where the examples that show "typical values" for the different > > modulation types? For example, I'm no expert in DVB-C but I'm trying > > to write an app which can be used by those users. What range of > > values will the API typically return for that modulation type? What > > values are "good" values, which represent "excellent" signal > > conditions, and what values suggest that the signal will probably be > > failing? > > > > What happens when a driver doesn't support a particular statistic? > > Right now some drivers return -EINVAL, others just set the field to > > zero or 0x1fff (in which case the user is mislead to believe that > > there is no signal lock *all* the time). > > > > EXAMPLES EXAMPLES EXAMPLES. This is the whole reason that the API > > behaves inconsistently today - somebody who did one of the early > > demods returned in 1/255 dB format, and then some other developer who > > didn't have the first piece of hardware wrote a driver and because > > he/she didn't *know* what the field was supposed to contain (and > > couldn't try it his/herself), that developer wro
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 29.12.2012 17:36, Devin Heitmueller wrote: On Fri, Dec 28, 2012 at 6:56 PM, Mauro Carvalho Chehab wrote: The DVBv3 quality parameters are limited on several ways: - Doesn't provide any way to indicate the used measure; - Userspace need to guess how to calculate the measure; - Only a limited set of stats are supported; - Doesn't provide QoS measure for the OFDM TPS/TMCC carriers, used to detect the network parameters for DVB-T/ISDB-T; - Can't be called in a way to require them to be filled all at once (atomic reads from the hardware), with may cause troubles on interpreting them on userspace; - On some OFDM delivery systems, the carriers can be independently modulated, having different properties. Currently, there's no way to report per-layer stats; This RFC adds the header definitions meant to solve that issues. After discussed, I'll write a patch for the DocBook and add support for it on some demods. Support for dvbv5-zap and dvbv5-scan tools will also have support for those features. Hi Mauro, As I've told you multiple times in the past, where this proposal falls apart is in its complete lack of specificity for real world scenarios. You have a units field which is "decibels", but in what unit? 1 dB / unit? 0.1 db / unit? 1/255 db / unit? This particular issue is why the current snr field varies across even demods where we have the datasheets. Many demods reported in 0.1 dB increments, while others reported in 1/255 dB increments. What happens when you ask for the SNR field when there is so signal lock (on most demods the SNR registers return garbage in this case)? What is the return value to userland? What happens when the data is unavailable for some other reason? What happens when you have group of statistics being asked for in a single call and *one* of them cannot be provided for some reason (in which case you cannot rely on a simple errno value since it doesn't apply to the entire call)? You need to take a step back and think about this from an application implementors standpoint. Most app developers for the existing apps look to show two data points: a signal indicator (0-100%), and some form of SNR (usually in dB, plotted on a scale where something like 40 dB=100% [of course this max varies by modulation type]). What would I need to do with the data you've provided to show that info? Do I really need to be a background in signal theory and understand the difference between SNR and CNR in order to tell the user how good his signal is? Since as an app developer I typically only have one or two tuners, how the hell am I supposed to write a piece of code that shows those two pieces of information given the huge number of different combinations of data types that demods could return given the proposed API? We have similar issues for UNC/BER values. Is the value returned the number of errors since the last time the application asked? Is it the number of errors in the last two seconds? Is it the number of errors since I reached signal lock? Does asking for the value clear out the counter? How do we handle the case where I asked for the data for the first time ten minutes after I reached signal lock? Are drivers internally supposed to be polling the register and updating the counters even when the application doesn't ask for the data (to handle cases where the demod's registers only have an error count for the last second's worth of data)? And where the examples that show "typical values" for the different modulation types? For example, I'm no expert in DVB-C but I'm trying to write an app which can be used by those users. What range of values will the API typically return for that modulation type? What values are "good" values, which represent "excellent" signal conditions, and what values suggest that the signal will probably be failing? What happens when a driver doesn't support a particular statistic? Right now some drivers return -EINVAL, others just set the field to zero or 0x1fff (in which case the user is mislead to believe that there is no signal lock *all* the time). EXAMPLES EXAMPLES EXAMPLES. This is the whole reason that the API behaves inconsistently today - somebody who did one of the early demods returned in 1/255 dB format, and then some other developer who didn't have the first piece of hardware wrote a driver and because he/she didn't *know* what the field was supposed to contain (and couldn't try it his/herself), that developer wrote a driver which returned in 0.1 dB format. This needs to be defined *in the spec*, or else we'll end up with developers (both app developers and kernel develoeprs implementing new demods) guessing how the API should behave based on whatever hardware they have, which is how we got in this mess in the first place. In short, you need to describe typical usage scenarios in terms of what values the API s
Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On Fri, Dec 28, 2012 at 6:56 PM, Mauro Carvalho Chehab wrote: > The DVBv3 quality parameters are limited on several ways: > - Doesn't provide any way to indicate the used measure; > - Userspace need to guess how to calculate the measure; > - Only a limited set of stats are supported; > - Doesn't provide QoS measure for the OFDM TPS/TMCC > carriers, used to detect the network parameters for > DVB-T/ISDB-T; > - Can't be called in a way to require them to be filled > all at once (atomic reads from the hardware), with may > cause troubles on interpreting them on userspace; > - On some OFDM delivery systems, the carriers can be > independently modulated, having different properties. > Currently, there's no way to report per-layer stats; > This RFC adds the header definitions meant to solve that issues. > After discussed, I'll write a patch for the DocBook and add support > for it on some demods. Support for dvbv5-zap and dvbv5-scan tools > will also have support for those features. Hi Mauro, As I've told you multiple times in the past, where this proposal falls apart is in its complete lack of specificity for real world scenarios. You have a units field which is "decibels", but in what unit? 1 dB / unit? 0.1 db / unit? 1/255 db / unit? This particular issue is why the current snr field varies across even demods where we have the datasheets. Many demods reported in 0.1 dB increments, while others reported in 1/255 dB increments. What happens when you ask for the SNR field when there is so signal lock (on most demods the SNR registers return garbage in this case)? What is the return value to userland? What happens when the data is unavailable for some other reason? What happens when you have group of statistics being asked for in a single call and *one* of them cannot be provided for some reason (in which case you cannot rely on a simple errno value since it doesn't apply to the entire call)? You need to take a step back and think about this from an application implementors standpoint. Most app developers for the existing apps look to show two data points: a signal indicator (0-100%), and some form of SNR (usually in dB, plotted on a scale where something like 40 dB=100% [of course this max varies by modulation type]). What would I need to do with the data you've provided to show that info? Do I really need to be a background in signal theory and understand the difference between SNR and CNR in order to tell the user how good his signal is? Since as an app developer I typically only have one or two tuners, how the hell am I supposed to write a piece of code that shows those two pieces of information given the huge number of different combinations of data types that demods could return given the proposed API? We have similar issues for UNC/BER values. Is the value returned the number of errors since the last time the application asked? Is it the number of errors in the last two seconds? Is it the number of errors since I reached signal lock? Does asking for the value clear out the counter? How do we handle the case where I asked for the data for the first time ten minutes after I reached signal lock? Are drivers internally supposed to be polling the register and updating the counters even when the application doesn't ask for the data (to handle cases where the demod's registers only have an error count for the last second's worth of data)? And where the examples that show "typical values" for the different modulation types? For example, I'm no expert in DVB-C but I'm trying to write an app which can be used by those users. What range of values will the API typically return for that modulation type? What values are "good" values, which represent "excellent" signal conditions, and what values suggest that the signal will probably be failing? What happens when a driver doesn't support a particular statistic? Right now some drivers return -EINVAL, others just set the field to zero or 0x1fff (in which case the user is mislead to believe that there is no signal lock *all* the time). EXAMPLES EXAMPLES EXAMPLES. This is the whole reason that the API behaves inconsistently today - somebody who did one of the early demods returned in 1/255 dB format, and then some other developer who didn't have the first piece of hardware wrote a driver and because he/she didn't *know* what the field was supposed to contain (and couldn't try it his/herself), that developer wrote a driver which returned in 0.1 dB format. This needs to be defined *in the spec*, or else we'll end up with developers (both app developers and kernel develoeprs implementing new demods) guessing how the API should behave based on whatever hardware they have, which is how we got in this mess in the first place. In short, you need to describe typical usage scenarios in terms of what values the API should be returning for diffe
Re: [linux-media] [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 29.12.2012 00:56, Mauro Carvalho Chehab wrote:
The DVBv3 quality parameters are limited on several ways:
- Doesn't provide any way to indicate the used measure;
- Userspace need to guess how to calculate the measure;
- Only a limited set of stats are supported;
- Doesn't provide QoS measure for the OFDM TPS/TMCC
carriers, used to detect the network parameters for
DVB-T/ISDB-T;
- Can't be called in a way to require them to be filled
all at once (atomic reads from the hardware), with may
cause troubles on interpreting them on userspace;
- On some OFDM delivery systems, the carriers can be
independently modulated, having different properties.
Currently, there's no way to report per-layer stats;
This RFC adds the header definitions meant to solve that issues.
After discussed, I'll write a patch for the DocBook and add support
for it on some demods. Support for dvbv5-zap and dvbv5-scan tools
will also have support for those features.
Signed-off-by: Mauro Carvalho Chehab
---
include/uapi/linux/dvb/frontend.h | 78 ++-
1 file changed, 77 insertions(+), 1 deletion(-)
v3: Just update http://patchwork.linuxtv.org/patch/9578/ to current tip
diff --git a/include/uapi/linux/dvb/frontend.h
b/include/uapi/linux/dvb/frontend.h
index c12d452..a998b9a 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -365,7 +365,21 @@ struct dvb_frontend_event {
#define DTV_INTERLEAVING 60
#define DTV_LNA 61
-#define DTV_MAX_COMMANDDTV_LNA
+/* Quality parameters */
+#define DTV_ENUM_QUALITY 45 /* Enumerates supported QoS parameters
*/
+#define DTV_QUALITY_SNR46
+#define DTV_QUALITY_CNR47
+#define DTV_QUALITY_EsNo 48
+#define DTV_QUALITY_EbNo 49
+#define DTV_QUALITY_RELATIVE 50
+#define DTV_ERROR_BER 51
+#define DTV_ERROR_PER 52
+#define DTV_ERROR_PARAMS 53 /* Error count at TMCC or TPS carrier */
+#define DTV_FE_STRENGTH54
+#define DTV_FE_SIGNAL 55
+#define DTV_FE_UNC 56
+
+#define DTV_MAX_COMMANDDTV_FE_UNC
typedef enum fe_pilot {
PILOT_ON,
@@ -452,12 +466,74 @@ struct dtv_cmds_h {
__u32 reserved:30;/* Align */
};
+/**
+ * Scale types for the quality parameters.
+ * @FE_SCALE_DECIBEL: The scale is measured in dB, typically
+ * used on signal measures.
+ * @FE_SCALE_LINEAR: The scale is linear.
+ * typically used on error QoS parameters.
+ * @FE_SCALE_RELATIVE: The scale is relative.
+ */
+enum fecap_scale_params {
+ FE_SCALE_DECIBEL,
+ FE_SCALE_LINEAR,
+ FE_SCALE_RELATIVE
+};
+
+/**
+ * struct dtv_status - Used for reading a DTV status property
+ *
+ * @value: value of the measure. Should range from 0 to 0x;
+ * @scale: Filled with enum fecap_scale_params - the scale
+ * in usage for that parameter
+ * @min: minimum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0.
+ * @max: maximum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0x.
+ *
+ * At userspace, min/max values should be used to calculate the
+ * absolute value of that measure, if fecap_scale_params is not
+ * FE_SCALE_RELATIVE, using the following formula:
+ * measure = min + (value * (max - min) / 0x)
+ *
+ * For error count measures, typically, min = 0, and max = 0x,
+ * and the measure represent the number of errors detected.
+ *
+ * Up to 4 status groups can be provided. This is for the
+ * OFDM standards where the carriers can be grouped into
+ * independent layers, each with its own modulation. When
+ * such layers are used (for example, on ISDB-T), the status
+ * should be filled with:
+ * stat.status[0] = global statistics;
+ * stat.status[1] = layer A statistics;
+ * stat.status[2] = layer B statistics;
+ * stat.status[3] = layer C statistics.
+ * and stat.len should be filled with the latest filled status + 1.
+ * If the frontend doesn't provide a global statistics,
+ * stat.has_global should be 0.
+ * Delivery systems that don't use it, should just set stat.len and
+ * stat.has_global with 1, and fill just stat.status[0].
+ */
+struct dtv_status {
+ __u16 value;
+ __u16 scale;
+ __s16 min;
+ __s16 max;
+} __attribute__ ((packed));
+
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct {
+ __u8 len;
+ __u8 has_global;
+
[PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
The DVBv3 quality parameters are limited on several ways:
- Doesn't provide any way to indicate the used measure;
- Userspace need to guess how to calculate the measure;
- Only a limited set of stats are supported;
- Doesn't provide QoS measure for the OFDM TPS/TMCC
carriers, used to detect the network parameters for
DVB-T/ISDB-T;
- Can't be called in a way to require them to be filled
all at once (atomic reads from the hardware), with may
cause troubles on interpreting them on userspace;
- On some OFDM delivery systems, the carriers can be
independently modulated, having different properties.
Currently, there's no way to report per-layer stats;
This RFC adds the header definitions meant to solve that issues.
After discussed, I'll write a patch for the DocBook and add support
for it on some demods. Support for dvbv5-zap and dvbv5-scan tools
will also have support for those features.
Signed-off-by: Mauro Carvalho Chehab
---
include/uapi/linux/dvb/frontend.h | 78 ++-
1 file changed, 77 insertions(+), 1 deletion(-)
v3: Just update http://patchwork.linuxtv.org/patch/9578/ to current tip
diff --git a/include/uapi/linux/dvb/frontend.h
b/include/uapi/linux/dvb/frontend.h
index c12d452..a998b9a 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -365,7 +365,21 @@ struct dvb_frontend_event {
#define DTV_INTERLEAVING 60
#define DTV_LNA61
-#define DTV_MAX_COMMANDDTV_LNA
+/* Quality parameters */
+#define DTV_ENUM_QUALITY 45 /* Enumerates supported QoS parameters
*/
+#define DTV_QUALITY_SNR46
+#define DTV_QUALITY_CNR47
+#define DTV_QUALITY_EsNo 48
+#define DTV_QUALITY_EbNo 49
+#define DTV_QUALITY_RELATIVE 50
+#define DTV_ERROR_BER 51
+#define DTV_ERROR_PER 52
+#define DTV_ERROR_PARAMS 53 /* Error count at TMCC or TPS carrier */
+#define DTV_FE_STRENGTH54
+#define DTV_FE_SIGNAL 55
+#define DTV_FE_UNC 56
+
+#define DTV_MAX_COMMANDDTV_FE_UNC
typedef enum fe_pilot {
PILOT_ON,
@@ -452,12 +466,74 @@ struct dtv_cmds_h {
__u32 reserved:30;/* Align */
};
+/**
+ * Scale types for the quality parameters.
+ * @FE_SCALE_DECIBEL: The scale is measured in dB, typically
+ * used on signal measures.
+ * @FE_SCALE_LINEAR: The scale is linear.
+ * typically used on error QoS parameters.
+ * @FE_SCALE_RELATIVE: The scale is relative.
+ */
+enum fecap_scale_params {
+ FE_SCALE_DECIBEL,
+ FE_SCALE_LINEAR,
+ FE_SCALE_RELATIVE
+};
+
+/**
+ * struct dtv_status - Used for reading a DTV status property
+ *
+ * @value: value of the measure. Should range from 0 to 0x;
+ * @scale: Filled with enum fecap_scale_params - the scale
+ * in usage for that parameter
+ * @min: minimum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0.
+ * @max: maximum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0x.
+ *
+ * At userspace, min/max values should be used to calculate the
+ * absolute value of that measure, if fecap_scale_params is not
+ * FE_SCALE_RELATIVE, using the following formula:
+ * measure = min + (value * (max - min) / 0x)
+ *
+ * For error count measures, typically, min = 0, and max = 0x,
+ * and the measure represent the number of errors detected.
+ *
+ * Up to 4 status groups can be provided. This is for the
+ * OFDM standards where the carriers can be grouped into
+ * independent layers, each with its own modulation. When
+ * such layers are used (for example, on ISDB-T), the status
+ * should be filled with:
+ * stat.status[0] = global statistics;
+ * stat.status[1] = layer A statistics;
+ * stat.status[2] = layer B statistics;
+ * stat.status[3] = layer C statistics.
+ * and stat.len should be filled with the latest filled status + 1.
+ * If the frontend doesn't provide a global statistics,
+ * stat.has_global should be 0.
+ * Delivery systems that don't use it, should just set stat.len and
+ * stat.has_global with 1, and fill just stat.status[0].
+ */
+struct dtv_status {
+ __u16 value;
+ __u16 scale;
+ __s16 min;
+ __s16 max;
+} __attribute__ ((packed));
+
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct {
+ __u8 len;
+ __u8 has_global;
+ struct dtv_status status[4];
+ } stat;
