| Message ID | 1357604750-772-2-git-send-email-mchehab@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Monday 7 January 2013 22:25:47 Mauro Carvalho Chehab wrote: <snip> > + <itemizedlist mark='bullet'> > + <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - If it is not possible to collect a given parameter (could be a transitory or permanent condition)</para></listitem> > + <listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 0.1 dB</para></listitem> > + <listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem> > + <listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem> > + </itemizedlist> <snip> > + <section id="DTV-QOS-SIGNAL-STRENGTH"> > + <title><constant>DTV_QOS_SIGNAL_STRENGTH</constant></title> > + <para>Indicates the signal strength level at the analog part of the tuner.</para> > + </section> Signal strength is traditionally an absolute field strength; there's no way in this API for me to provide my reference point, so two different front ends could represent the same signal strength as "0 dB" (where the reference point is one microwatt), "-30 dB" (where the reference point is one milliwatt), or "17 dB" (using a reference point of 1 millivolt on a 50 ohm impedance). Could you choose a reference point for signal strength, and specify that if you're using FE_SCALE_DECIBEL, you're referenced against that point? My preference would be to reference against 1 microwatt, as (on the DVB-T and ATSC cards I use) that leads to the signal measure being 0 dBµW if you've got perfect signal, negative number if your signal is weak, and positive numbers if your signal is strong. However, referenced against 1 milliwatt also works well for me, as the conversion is trivial.
Em Mon, 7 Jan 2013 22:25:47 -0200 Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: > The DVBv3 quality parameters are limited on several ways: > > - Doesn't provide any way to indicate the used measure, > so userspace need to guess how to calculate the measure; > > - Only a limited set of stats are supported; > > - 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. > > To address the above issues, adding a new DVBv5-based stats > API. > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > ... > +struct dtv_stats { > + __u8 scale; /* enum fecap_scale_params type */ > + union { > + __u32 uvalue; /* for counters and relative scales */ > + __s32 svalue; /* for 0.1 dB measures */ 32 bits for total bit count is not enough, as it can be truncated too early (~1 seg on ISDB-T, ~0.5 seg on DVB-C). I think we need to use 64 bits here, and put at the API that the drivers should monotonically increment. As struct buffer inside struct dtv_property has 48 bytes, we can do such change here without breaking userspace, as struct dtv_stats will have 37 bytes.
Am 08.01.2013 12:45, schrieb Simon Farnsworth: > On Monday 7 January 2013 22:25:47 Mauro Carvalho Chehab wrote: > <snip> >> + <itemizedlist mark='bullet'> >> + <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - If it is not possible to collect a given parameter (could be a transitory or permanent condition)</para></listitem> >> + <listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 0.1 dB</para></listitem> >> + <listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem> >> + <listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem> >> + </itemizedlist> > <snip> >> + <section id="DTV-QOS-SIGNAL-STRENGTH"> >> + <title><constant>DTV_QOS_SIGNAL_STRENGTH</constant></title> >> + <para>Indicates the signal strength level at the analog part of the tuner.</para> >> + </section> > Signal strength is traditionally an absolute field strength; there's no way in > this API for me to provide my reference point, so two different front ends > could represent the same signal strength as "0 dB" (where the reference point > is one microwatt), "-30 dB" (where the reference point is one milliwatt), or > "17 dB" (using a reference point of 1 millivolt on a 50 ohm impedance). > > Could you choose a reference point for signal strength, and specify that if > you're using FE_SCALE_DECIBEL, you're referenced against that point? > > My preference would be to reference against 1 microwatt, as (on the DVB-T and > ATSC cards I use) that leads to the signal measure being 0 dBµW if you've got > perfect signal, negative number if your signal is weak, and positive numbers > if your signal is strong. However, referenced against 1 milliwatt also works > well for me, as the conversion is trivial. Yeah, that's one of the most popular mistakes in the technical world. Decibel is a relative unit. X dB says nothing about the absolute value without a reference value. Hence these reference values must be specified in the document. Otherwise the reported signal strengths are meaningless / not comparable. It might be worth to take a look at what the wireles network people have done. IIRC, they had the same discussion about signal strength reporting a (longer) while ago. Just my two cents. Regards, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 8 January 2013 19:00:11 Frank Schäfer wrote: > Am 08.01.2013 12:45, schrieb Simon Farnsworth: > > On Monday 7 January 2013 22:25:47 Mauro Carvalho Chehab wrote: > > <snip> > >> + <itemizedlist mark='bullet'> > >> + <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - If it is not possible to collect a given parameter (could be a transitory or permanent condition)</para></listitem> > >> + <listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 0.1 dB</para></listitem> > >> + <listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem> > >> + <listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem> > >> + </itemizedlist> > > <snip> > >> + <section id="DTV-QOS-SIGNAL-STRENGTH"> > >> + <title><constant>DTV_QOS_SIGNAL_STRENGTH</constant></title> > >> + <para>Indicates the signal strength level at the analog part of the tuner.</para> > >> + </section> > > Signal strength is traditionally an absolute field strength; there's no way in > > this API for me to provide my reference point, so two different front ends > > could represent the same signal strength as "0 dB" (where the reference point > > is one microwatt), "-30 dB" (where the reference point is one milliwatt), or > > "17 dB" (using a reference point of 1 millivolt on a 50 ohm impedance). > > > > Could you choose a reference point for signal strength, and specify that if > > you're using FE_SCALE_DECIBEL, you're referenced against that point? > > > > My preference would be to reference against 1 microwatt, as (on the DVB-T and > > ATSC cards I use) that leads to the signal measure being 0 dBµW if you've got > > perfect signal, negative number if your signal is weak, and positive numbers > > if your signal is strong. However, referenced against 1 milliwatt also works > > well for me, as the conversion is trivial. > > Yeah, that's one of the most popular mistakes in the technical world. > Decibel is a relative unit. X dB says nothing about the absolute value > without a reference value. > Hence these reference values must be specified in the document. > Otherwise the reported signal strengths are meaningless / not comparable. > > It might be worth to take a look at what the wireles network people have > done. > IIRC, they had the same discussion about signal strength reporting a > (longer) while ago. > The wireless folk use dBm (reference point 1 milliwatt), as that's the reference point used in the 802.11 standard. Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference point (so suitable for carrier to noise etc, or for when the reference point is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is 1mW, so that frontends report in dBm? Note that if the frontend internally uses a different reference point, the conversion is always going to be adding or subtracting a constant.
On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth <simon.farnsworth@onelan.com> wrote: > The wireless folk use dBm (reference point 1 milliwatt), as that's the > reference point used in the 802.11 standard. > > Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference > point (so suitable for carrier to noise etc, or for when the reference point > is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is > 1mW, so that frontends report in dBm? > > Note that if the frontend internally uses a different reference point, the > conversion is always going to be adding or subtracting a constant. Hi Simon, Probably the biggest issue you're going to have is that very few of the consumer-grade demodulators actually report data in that format. And only a small subset of those actually provide the documentation in their datasheet. The goal behind the "strength" indicator is to provide a field even an idiot can understand. While I appreciate the desire to be able to access the data in it's an "advanced" format, in reality the number of demodulator drivers that would actually be able to report such is very small -- and the approach prevents a "lowest common denominator", which is what 99% of the users *actually* care about. For that matter, even the SNR field being reported in dB isn't going to allow you to reliably compare across different demodulator chips. If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't *really* mean demod Y performs better - just that it's reporting a better number. However it *does* allow you to compare the demod against itself either across multiple frequencies or under different signal conditions - which is what typical users really care about. And while I realize in your case, Simon, that your requirements may be different from typical consumer-grade applications, I worry that adding yet more complexity to the solution will just result in getting *NOTHING*, as we have for all these years every time the issue of signal statistics has been raised. Devin
On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote: > On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth > <simon.farnsworth@onelan.com> wrote: > > The wireless folk use dBm (reference point 1 milliwatt), as that's the > > reference point used in the 802.11 standard. > > > > Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference > > point (so suitable for carrier to noise etc, or for when the reference point > > is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is > > 1mW, so that frontends report in dBm? > > > > Note that if the frontend internally uses a different reference point, the > > conversion is always going to be adding or subtracting a constant. > > Hi Simon, > > Probably the biggest issue you're going to have is that very few of > the consumer-grade demodulators actually report data in that format. > And only a small subset of those actually provide the documentation in > their datasheet. > <snip> My specific concern is that we already see people complaining that their cable system or aerial installer's meter comes up with one number, and our documentation has completely different numbers. When we dig, this usually turns out to be because our documentation is in dBm, while their installer is using dBmV or dBµW, and no-one at the customer site knows the differences. If consumer demods don't report in a dB scale at all, we should drop dB as a unit; if they do report in a true dB scale, but the reference point is normally not documented, we need some way to distinguish demods where the reference point is unknown, and demods where someone has taken the time to find the reference point (which can be done with a signal generator). This is sounding more and more like an argument for adding FE_SCALE_DECIBEL_MILLIWATT - it gives those applications that care a way to tell the user that the signal strength reading from the application should match up to the signal strength reading on your installer's kit. Said applications could even choose to do the conversions for you, giving you all four commonly seen units (dBm, dBmV at 50?, dBmV at 75?, dBµW). > For that matter, even the SNR field being reported in dB isn't going > to allow you to reliably compare across different demodulator chips. > If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't > really mean demod Y performs better - just that it's reporting a > better number. However it does allow you to compare the demod > against itself either across multiple frequencies or under different > signal conditions - which is what typical users really care about. I'm not expecting people to compare across demods - I only care about the case where a user has got in a professional installer to help with their setup. The problem I want to avoid is a Linux application saying "-48 dB signal strength, 15 dB CNR", and the installer's kit saying "60 dBuV signal strength, 20 dB CNR", when we have enough information for the Linux application to say "-48 dBm (60 dBuV at 75?), 15 dB CNR", cueing the professional to remember that not all dB use the same reference point, and from there into accepting that Linux is reporting a similar signal strength and CNR to his kit. This also has implications for things like VDR - if the scale is FE_SCALE_DECIBEL but the measurement is absolute, the application probably doesn't want to report the measurement as a dB measure, but as an arbitrary scale; again, you don't want the application saying "50 dB", when the professional installer tells you that you have "0 dBuV".
Em Wed, 09 Jan 2013 11:02:23 +0000 Simon Farnsworth <simon.farnsworth@onelan.com> escreveu: > On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote: > > On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth > > <simon.farnsworth@onelan.com> wrote: > > > The wireless folk use dBm (reference point 1 milliwatt), as that's the > > > reference point used in the 802.11 standard. > > > > > > Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference > > > point (so suitable for carrier to noise etc, or for when the reference point > > > is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is > > > 1mW, so that frontends report in dBm? > > > > > > Note that if the frontend internally uses a different reference point, the > > > conversion is always going to be adding or subtracting a constant. > > > > Hi Simon, > > > > Probably the biggest issue you're going to have is that very few of > > the consumer-grade demodulators actually report data in that format. > > And only a small subset of those actually provide the documentation in > > their datasheet. > > > <snip> > My specific concern is that we already see people complaining that their cable > system or aerial installer's meter comes up with one number, and our > documentation has completely different numbers. When we dig, this usually > turns out to be because our documentation is in dBm, while their installer is > using dBmV or dBµW, and no-one at the customer site knows the differences. > > If consumer demods don't report in a dB scale at all, we should drop dB as a > unit; if they do report in a true dB scale, but the reference point is > normally not documented, we need some way to distinguish demods where the > reference point is unknown, and demods where someone has taken the time to > find the reference point (which can be done with a signal generator). > > This is sounding more and more like an argument for adding > FE_SCALE_DECIBEL_MILLIWATT - it gives those applications that care a way to > tell the user that the signal strength reading from the application should > match up to the signal strength reading on your installer's kit. Said > applications could even choose to do the conversions for you, giving you all > four commonly seen units (dBm, dBmV at 50?, dBmV at 75?, dBµW). > > > For that matter, even the SNR field being reported in dB isn't going > > to allow you to reliably compare across different demodulator chips. > > If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't > > really mean demod Y performs better - just that it's reporting a > > better number. However it does allow you to compare the demod > > against itself either across multiple frequencies or under different > > signal conditions - which is what typical users really care about. > > I'm not expecting people to compare across demods - I only care about the > case where a user has got in a professional installer to help with their > setup. The problem I want to avoid is a Linux application saying "-48 dB > signal strength, 15 dB CNR", and the installer's kit saying "60 dBuV signal > strength, 20 dB CNR", when we have enough information for the Linux > application to say "-48 dBm (60 dBuV at 75?), 15 dB CNR", cueing the > professional to remember that not all dB use the same reference point, and > from there into accepting that Linux is reporting a similar signal strength > and CNR to his kit. > > This also has implications for things like VDR - if the scale is > FE_SCALE_DECIBEL but the measurement is absolute, the application probably > doesn't want to report the measurement as a dB measure, but as an arbitrary > scale; again, you don't want the application saying "50 dB", when the > professional installer tells you that you have "0 dBuV". Yes, it makes sense to document that the signal strength should be reported on either dBm or dBµW, if the scale is FE_SCALE_DECIBEL. I prefer to specify it in terms of Watt (or a submultiple) than in terms of voltage/impedance, as different Countries use different impedances on DTV cabling (typically, 50? or 75?). So, either dBm or dBµW works for me. As you said, applications can convert between those mesures as they wish, by simply adding some constant when displaying the power measure. As the wifi subsytem use dBm, I vote for using dBm for the signal measure at the subsystem (actually, 0.1 dBm). Comments? Regards, Mauro
On Wednesday 9 January 2013 13:24:25 Mauro Carvalho Chehab wrote: <snip> > Yes, it makes sense to document that the signal strength should be reported > on either dBm or dBµW, if the scale is FE_SCALE_DECIBEL. I prefer to specify > it in terms of Watt (or a submultiple) than in terms of voltage/impedance, as > different Countries use different impedances on DTV cabling (typically, > 50? or 75?). > > So, either dBm or dBµW works for me. As you said, applications can convert > between those mesures as they wish, by simply adding some constant when > displaying the power measure. > > As the wifi subsytem use dBm, I vote for using dBm for the signal measure > at the subsystem (actually, 0.1 dBm). > 0.1 dBm suits me. I just want something that I can present to the end user in a format that will match their aerial installer's kit.
On 09.01.2013 12:02, Simon Farnsworth wrote: > On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote: >> On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth >> <simon.farnsworth@onelan.com> wrote: >>> The wireless folk use dBm (reference point 1 milliwatt), as that's the >>> reference point used in the 802.11 standard. >>> >>> Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference >>> point (so suitable for carrier to noise etc, or for when the reference point >>> is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is >>> 1mW, so that frontends report in dBm? >>> >>> Note that if the frontend internally uses a different reference point, the >>> conversion is always going to be adding or subtracting a constant. >> >> Hi Simon, >> >> Probably the biggest issue you're going to have is that very few of >> the consumer-grade demodulators actually report data in that format. >> And only a small subset of those actually provide the documentation in >> their datasheet. >> > <snip> > My specific concern is that we already see people complaining that their cable > system or aerial installer's meter comes up with one number, and our > documentation has completely different numbers. When we dig, this usually > turns out to be because our documentation is in dBm, while their installer is > using dBmV or dBµW, and no-one at the customer site knows the differences. > > If consumer demods don't report in a dB scale at all, we should drop dB as a > unit; if they do report in a true dB scale, but the reference point is > normally not documented, we need some way to distinguish demods where the > reference point is unknown, and demods where someone has taken the time to > find the reference point (which can be done with a signal generator). > > This is sounding more and more like an argument for adding > FE_SCALE_DECIBEL_MILLIWATT - it gives those applications that care a way to > tell the user that the signal strength reading from the application should > match up to the signal strength reading on your installer's kit. Said > applications could even choose to do the conversions for you, giving you all > four commonly seen units (dBm, dBmV at 50?, dBmV at 75?, dBµW). > >> For that matter, even the SNR field being reported in dB isn't going >> to allow you to reliably compare across different demodulator chips. >> If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't >> really mean demod Y performs better - just that it's reporting a >> better number. However it does allow you to compare the demod >> against itself either across multiple frequencies or under different >> signal conditions - which is what typical users really care about. > > I'm not expecting people to compare across demods - I only care about the > case where a user has got in a professional installer to help with their > setup. The problem I want to avoid is a Linux application saying "-48 dB > signal strength, 15 dB CNR", and the installer's kit saying "60 dBuV signal > strength, 20 dB CNR", when we have enough information for the Linux > application to say "-48 dBm (60 dBuV at 75?), 15 dB CNR", cueing the > professional to remember that not all dB use the same reference point, and > from there into accepting that Linux is reporting a similar signal strength > and CNR to his kit. > > This also has implications for things like VDR - if the scale is > FE_SCALE_DECIBEL but the measurement is absolute, the application probably > doesn't want to report the measurement as a dB measure, but as an arbitrary > scale; again, you don't want the application saying "50 dB", when the > professional installer tells you that you have "0 dBuV". Actually VDR doesn't care about "dB", "dBuV", "dBuW" or whatever. All it wants to do is to display the signal strength and quality in a way that, as Devin stated so very appropriately, even an idiot can understand ;-) VDR displays a bar that goes from 0 ("no signal at all") to full extent ("perfect signal"). So for VDR any value range that can be linearly converted to a range between 0% and 100% would do just fine. The only important thing is that it is the *same* for all frontends! Ideally I would expect values in the range 0x0000 thru 0xFFFF. Klaus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index 957e3ac..9168808 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml @@ -7,16 +7,29 @@ the capability ioctls weren't implemented yet via the new way.</para> <para>The typical usage for the <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant> API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters"> struct <constant>dvb_frontend_parameters</constant></link> were used.</para> +<section id="dtv-stats"> +<title>DTV stats type</title> +<programlisting> +struct dtv_stats { + __u16 value; + __u8 scale; +} __attribute__ ((packed)); +</programlisting> +</section> <section id="dtv-property"> <title>DTV property type</title> <programlisting> /* Reserved fields should be set to 0 */ + struct dtv_property { __u32 cmd; union { __u32 data; struct { - __u8 data[32]; + union { + __u8 data[32]; + __u16 data[16]; + } __u32 len; __u32 reserved1[3]; void *reserved2; @@ -850,6 +863,78 @@ enum fe_interleaving { <para>use the special macro LNA_AUTO to set LNA auto</para> </section> </section> + + <section id="frontend-qos-properties"> + <title>Frontend Quality of Service/Statistics indicators</title> + <para>Except for <link linkend="DTV-QOS-ENUM"><constant>DTV_QOS_ENUM</constant></link>, + the values are returned via <constant>dtv_property.stat</constant>.</para> + <para>For most delivery systems, this will return a single value for each parameter.</para> + <para>It should be noticed, however, that new OFDM delivery systems + like ISDB can use different modulation types for each group of carriers. + On such standards, up to 3 groups of statistics can be provided, one + for each carrier group (called "layer" on ISDB). + In order to be consistent with other delivery systems, the first + value at <link linkend="dtv-stats"><constant>dtv_property.stat.dtv_stats</constant></link> array refers to + a global indicator, if any. The other elements of the array represent + each layer, starting from layer A(index 1), layer B (index 2) and so on</para> + <para>The number of filled elements are stored at <constant>dtv_property.stat.len</constant>.</para> + <para>Each element of the <constant>dtv_property.stat.dtv_stats</constant> array consists on two elements:</para> + <itemizedlist mark='opencircle'> + <listitem><para><constant>value</constant> - Value of the measure</para></listitem> + <listitem><para><constant>scale</constant> - Scale for the value. It can be:</para> + <section id = "fecap-scale-params"> + <itemizedlist mark='bullet'> + <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - If it is not possible to collect a given parameter (could be a transitory or permanent condition)</para></listitem> + <listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 0.1 dB</para></listitem> + <listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem> + <listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem> + </itemizedlist> + </section> + </listitem> + </itemizedlist> + <section id="DTV-QOS-ENUM"> + <title><constant>DTV_QOS_ENUM</constant></title> + <para>A frontend needs to advertise the statistics it provides. This property allows to enumerate all + <link linkend="frontend-qos-properties">DTV QoS statistics</link> that are + supported by a given frontend.</para> + + <para><constant>dtv_property.len</constant> indicates the number of supported + <link linkend="frontend-qos-properties">DTV QoS statistics</link>.</para> + <para><constant>dtv_property.data16</constant> is an 16 bits array of the supported properties.</para> + </section> + <section id="DTV-QOS-SIGNAL-STRENGTH"> + <title><constant>DTV_QOS_SIGNAL_STRENGTH</constant></title> + <para>Indicates the signal strength level at the analog part of the tuner.</para> + </section> + <section id="DTV-QOS-CNR"> + <title><constant>DTV_QOS_CNR</constant></title> + <para>Indicates the signal to noise relation for the main carrier.</para> + + </section> + <section id="DTV-QOS-BIT-ERROR-COUNT"> + <title><constant>DTV_QOS_BIT_ERROR_COUNT</constant></title> + <para>Measures the number of bit errors since the last counter reset.</para> + <para>In order to get the BER (Bit Error Rate) measurement, it should be divided by + <link linkend="DTV-QOS-TOTAL-BITS-COUNT"><constant>DTV_QOS_TOTAL_BITS_COUNT</constant></link>.</para> + </section> + <section id="DTV-QOS-TOTAL-BITS-COUNT"> + <title><constant>DTV_QOS_TOTAL_BITS_COUNT</constant></title> + <para>Measures the amount of bits received since the last <link linkend="DTV-QOS-BIT-ERROR-COUNT"><constant>DTV_QOS_BIT_ERROR_COUNT</constant></link> reset.</para> + </section> + <section id="DTV-QOS-ERROR-BLOCK-COUNT"> + <title><constant>DTV_QOS_ERROR_BLOCK_COUNT</constant></title> + <para>Measures the number of block errors since the last counter reset.</para> + </section> + <section id="DTV-QOS-TOTAL-BLOCKS-COUNT"> + <title><constant>DTV-QOS_TOTAL_BLOCKS_COUNT</constant></title> + <para>Measures the total number of blocks since the last + <link linkend="DTV-QOS-ERROR-BLOCK-COUNT"><constant>DTV_QOS_ERROR_BLOCK_COUNT</constant></link> reset.</para> + <para>It can be used to calculate the PER indicator, by dividing + <link linkend="DTV-QOS-ERROR-BLOCK-COUNT"><constant>DTV_QOS_ERROR_BLOCK_COUNT</constant></link> + by <link linkend="DTV-QOS-TOTAL-BLOCKS-COUNT"><constant>DTV-QOS-TOTAL-BLOCKS-COUNT</constant></link>.</para> + </section> + </section> + <section id="frontend-property-terrestrial-systems"> <title>Properties used on terrestrial delivery systems</title> <section id="dvbt-params"> @@ -871,6 +956,7 @@ enum fe_interleaving { <listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem> <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> </itemizedlist> + <para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para> </section> <section id="dvbt2-params"> <title>DVB-T2 delivery system</title> @@ -895,6 +981,7 @@ enum fe_interleaving { <listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem> <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> </itemizedlist> + <para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para> </section> <section id="isdbt"> <title>ISDB-T delivery system</title> @@ -948,6 +1035,7 @@ enum fe_interleaving { <listitem><para><link linkend="DTV-ISDBT-LAYER-SEGMENT-COUNT"><constant>DTV_ISDBT_LAYERC_SEGMENT_COUNT</constant></link></para></listitem> <listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem> </itemizedlist> + <para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para> </section> <section id="atsc-params"> <title>ATSC delivery system</title> @@ -961,6 +1049,7 @@ enum fe_interleaving { <listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem> <listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem> </itemizedlist> + <para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para> </section> <section id="atscmh-params"> <title>ATSC-MH delivery system</title> @@ -988,6 +1077,7 @@ enum fe_interleaving { <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem> <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem> </itemizedlist> + <para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para> </section> <section id="dtmb-params"> <title>DTMB delivery system</title> @@ -1007,6 +1097,7 @@ enum fe_interleaving { <listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem> <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> </itemizedlist> + <para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para> </section> </section> <section id="frontend-property-cable-systems"> @@ -1028,6 +1119,7 @@ enum fe_interleaving { <listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem> <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> </itemizedlist> + <para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para> </section> <section id="dvbc-annex-b-params"> <title>DVB-C Annex B delivery system</title> @@ -1043,6 +1135,7 @@ enum fe_interleaving { <listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem> <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> </itemizedlist> + <para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para> </section> </section> <section id="frontend-property-satellital-systems"> @@ -1062,6 +1155,7 @@ enum fe_interleaving { <listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem> <listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem> </itemizedlist> + <para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para> <para>Future implementations might add those two missing parameters:</para> <itemizedlist mark='opencircle'> <listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem> @@ -1077,6 +1171,7 @@ enum fe_interleaving { <listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem> <listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem> </itemizedlist> + <para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para> </section> <section id="turbo-params"> <title>Turbo code delivery system</title> diff --git a/include/uapi/linux/dvb/frontend.h b/include/uapi/linux/dvb/frontend.h index c12d452..39e3321 100644 --- a/include/uapi/linux/dvb/frontend.h +++ b/include/uapi/linux/dvb/frontend.h @@ -365,7 +365,16 @@ struct dvb_frontend_event { #define DTV_INTERLEAVING 60 #define DTV_LNA 61 -#define DTV_MAX_COMMAND DTV_LNA +/* Quality parameters */ +#define DTV_QOS_ENUM 62 +#define DTV_QOS_SIGNAL_STRENGTH 63 +#define DTV_QOS_CNR 64 +#define DTV_QOS_BIT_ERROR_COUNT 65 +#define DTV_QOS_TOTAL_BITS_COUNT 66 +#define DTV_QOS_ERROR_BLOCK_COUNT 67 +#define DTV_QOS_TOTAL_BLOCKS_COUNT 68 + +#define DTV_MAX_COMMAND DTV_QOS_TOTAL_BLOCKS_COUNT typedef enum fe_pilot { PILOT_ON, @@ -452,13 +461,84 @@ struct dtv_cmds_h { __u32 reserved:30; /* Align */ }; +/** + * Scale types for the quality parameters. + * @FE_SCALE_NOT_AVAILABLE: That QoS measure is not available. That + * could indicate a temporary or a permanent + * condition. + * @FE_SCALE_DECIBEL: The scale is measured in 0.1 dB steps, typically + * used on signal measures. + * @FE_SCALE_RELATIVE: The scale is a relative percentual measure, + * ranging from 0 (0%) to 0xffff (100%). + * @FE_SCALE_COUNTER: The scale counts the occurrence of an event, like + * bit error, block error, lapsed time. + */ +enum fecap_scale_params { + FE_SCALE_NOT_AVAILABLE, + FE_SCALE_DECIBEL, + FE_SCALE_RELATIVE, + FE_SCALE_COUNTER +}; + +/** + * struct dtv_stats - Used for reading a DTV status property + * + * @value: value of the measure. Should range from 0 to 0xffff; + * @scale: Filled with enum fecap_scale_params - the scale + * in usage for that parameter + * + * For most delivery systems, this will return a single value for each + * parameter. + * It should be noticed, however, that new OFDM delivery systems like + * ISDB can use different modulation types for each group of carriers. + * On such standards, up to 8 groups of statistics can be provided, one + * for each carrier group (called "layer" on ISDB). + * In order to be consistent with other delivery systems, the first + * value refers to the entire set of carriers ("global"). + * dtv_status:scale should use the value FE_SCALE_NOT_AVAILABLE when + * the value for the entire group of carriers or from one specific layer + * is not provided by the hardware. + * st.len should be filled with the latest filled status + 1. + * + * In other words, for ISDB, those values should be filled like: + * u.st.stat.svalue[0] = global statistics; + * u.st.stat.scale[0] = FE_SCALE_DECIBELS; + * u.st.stat.value[1] = layer A statistics; + * u.st.stat.scale[1] = FE_SCALE_NOT_AVAILABLE (if not available); + * u.st.stat.svalue[2] = layer B statistics; + * u.st.stat.scale[2] = FE_SCALE_DECIBELS; + * u.st.stat.svalue[3] = layer C statistics; + * u.st.stat.scale[3] = FE_SCALE_DECIBELS; + * u.st.len = 4; + */ +struct dtv_stats { + __u8 scale; /* enum fecap_scale_params type */ + union { + __u32 uvalue; /* for counters and relative scales */ + __s32 svalue; /* for 0.1 dB measures */ + }; +} __attribute__ ((packed)); + + +#define MAX_QOS_STATS 4 + +struct dtv_fe_stats { + __u8 len; + __u8 scale; + struct dtv_stats stat[MAX_QOS_STATS]; +} __attribute__ ((packed)); + struct dtv_property { __u32 cmd; __u32 reserved[3]; union { __u32 data; + struct dtv_fe_stats st; struct { - __u8 data[32]; + union { + __u8 data[32]; + __u16 data16[16]; + }; __u32 len; __u32 reserved1[3]; void *reserved2;
The DVBv3 quality parameters are limited on several ways: - Doesn't provide any way to indicate the used measure, so userspace need to guess how to calculate the measure; - Only a limited set of stats are supported; - 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. To address the above issues, adding a new DVBv5-based stats API. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> --- v6: Add DocBook documentation. v7: Some fixes as suggested by Antti v8: Documentation fix, compilation fix and name the stats struct, for its reusage inside the core v9: counters need 32 bits. So, change the return data types to s32/u32 types --- Documentation/DocBook/media/dvb/dvbproperty.xml | 97 ++++++++++++++++++++++++- include/uapi/linux/dvb/frontend.h | 84 ++++++++++++++++++++- 2 files changed, 178 insertions(+), 3 deletions(-)