| Message ID | 49C96A37.4020905@gmail.com (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
>>> That said, the solution takes the approach of "revolutionary" as >>> opposed to "evolutionary", which always worries me. While providing a >>> much more powerful interface, it also means all of the applications >>> will have to properly support all of the various possible >>> representations of the data, increasing the responsibility in userland >>> considerably. > > Not necessarily, the application can simply chose to support what > the driver provides as is, thereby doing no translations at all. From the end user point of view it is not very usefull if he has 2 different cards and application can not show any usefull signal goodness info in a way that would be easy to compare. So I think the attempt to standardize to db is good. Maybe there could then in addition be some other optional method for also getting data in some hw specific format in a way that Manu suggested. But there should anyway be mandatory to have this one "standard goodness value" in a way that does not require apps to make any complicate comparisons... (I bet half of those apps would be broken for years) Mika -- 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
Mika Laitio wrote: >>>> That said, the solution takes the approach of "revolutionary" as >>>> opposed to "evolutionary", which always worries me. While providing a >>>> much more powerful interface, it also means all of the applications >>>> will have to properly support all of the various possible >>>> representations of the data, increasing the responsibility in userland >>>> considerably. >> >> Not necessarily, the application can simply chose to support what >> the driver provides as is, thereby doing no translations at all. > >> From the end user point of view it is not very usefull if he has 2 > different cards and application can not show any usefull signal goodness > info in a way that would be easy to compare. So I think the attempt to > standardize to db is good. The first part: For comparison having a standardized value is good. True. But the problem that surrounds it: To do this, a driver should support statistics in dB. For a device which doesn't show statistics in dB, for reasons (a) device uses a different format (b) enough information is not available to do a conversion (too less information, or a reverse engineered driver) (c) the conversion to be done makes things too complex in kernel land. So you have very less devices to do a comparison between. The other way to do this: Suppose, the driver that doesn't support a dB format (relative doesn't mean unknown) provides the information in a relative format. And the driver that provides the information in dB format, but that information you get, can be converted in to a relative floor - ceiling format (conversion handled by application, or by a library) This is a quick way. Now, which all devices do provide a scale in dB, which is really comparable ? There are many different parameters, quickly hacked together to be called SNR. In the terms you mention, you will be comparing things like SNR to CNR etc based on the device type. So eventually your comparison is wrong. > Maybe there could then in addition be some other optional method for > also getting data in some hw specific format in a way that Manu suggested. > But there should anyway be mandatory to have this one "standard goodness > value" in a way that does not require apps to make any complicate > comparisons... (I bet half of those apps would be broken for years) In the way i mentioned, it leaves to the application to choose from different styles such as (1) display parameters from the drivers, in their own native format (This is a completely human readable format, in which you can see the real scales) (2) convert parameters to a specific format. (The very important part here is that the application is free to convert from format A with driver X and format B with driver Y, to get it into a unified format. if you really need the feature what you mentioned, you need this feature, rather than have all drivers being modified to provide one standard format) To make things look simple, i have a sample application which does (1) to make things look simple. If you choose to do (2) It will be just doing the conversion one time in a library or application, once rather than doing it multiple times in unknown ways and formats. Regards, Manu -- 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
Mika Laitio wrote: > But there should anyway be mandatory to have this one "standard goodness > value" in a way that does not require apps to make any complicate > comparisons... (I bet half of those apps would be broken for years) That said, the conversion functions can be added into libdvb, how we have added support for EN50221 CAM support. Apps that use the library can simply use the builtin functions and forget about all those conversions. That might help some of the applciations which are not conversant in conversions. Regards, Manu -- 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 Tue, Mar 24, 2009 at 4:46 PM, Manu Abraham <abraham.manu@gmail.com> wrote: >>> From the end user point of view it is not very usefull if he has 2 >> different cards and application can not show any usefull signal goodness >> info in a way that would be easy to compare. So I think the attempt to >> standardize to db is good. > > The first part: For comparison having a standardized value is good. > > True. > > But the problem that surrounds it: > > To do this, a driver should support statistics in dB. For a device > which doesn't show statistics in dB, for reasons > (a) device uses a different format > > (b) enough information is not available to do a conversion >   (too less information, or a reverse engineered driver) > > (c) the conversion to be done makes things too complex in kernel land. > > So you have very less devices to do a comparison between. Those are strong points you're making and more then enough reason to maintain the values in their native form and deal with it elsewhere. > The other way to do this: > > Suppose, the driver that doesn't support a dB format (relative > doesn't mean unknown) provides the information in a relative format. > And the driver that provides the information in dB format, but that > information you get, can be converted in to a relative floor - > ceiling format (conversion handled by application, or by a library) > > This is a quick way. > > Now, which all devices do provide a scale in dB, which is really > comparable ? There are many different parameters, quickly hacked > together to be called SNR. In the terms you mention, you will be > comparing things like > > SNR to CNR etc based on the device type. > > So eventually your comparison is wrong. Another good point. And a quick comment that I like the idea of a library. This takes the burden off the app while leaving options available instead of just forcing everything to dB whether it's compatible or not. >> Maybe there could then in addition be some other optional method for >> also getting data in some hw specific format in a way that Manu suggested. >> But there should anyway be mandatory to have this one "standard goodness >> value" in a way that does not require apps to make any complicate >> comparisons... (I bet half of those apps would be broken for years) > > In the way i mentioned, it leaves to the application to choose from > different styles such as > > (1) display parameters from the drivers, in their own native format > (This is a completely human readable format, in which you can see > the real scales) > > (2) convert parameters to a specific format. > (The very important part here is that the application is free to > convert from format A with driver X and  format B with driver Y, to > get it into a unified format. if you really need the feature what > you mentioned, you need this feature, rather than have all drivers > being modified to provide one standard format) > > To make things look simple, i have a sample application which does > (1) to make things look simple. > > If you choose to do (2) It will be just doing the conversion one > time in a library or application, once rather than doing it multiple > times in unknown ways and formats. Makes sense. One of my concerns was that this would just be slapped together and rushed like some other things were and finding out how bad of an idea that was after the fact. This doesn't need to take forever to reach a majority opinion, but it should have enough thought behind it to not cut people off at the knees. It sounds to me that preserving the native format is certainly a good idea for the numerous reasons that have been pointed out, and providing converting via library is the most sane approach. Trying to force a square into a circle never seems to work out very well. Best regards, Derek -- 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 Tue, Mar 24, 2009 at 7:46 PM, Manu Abraham <abraham.manu@gmail.com> wrote: > Mika Laitio wrote: >>>>> That said, the solution takes the approach of "revolutionary" as >>>>> opposed to "evolutionary", which always worries me.  While providing a >>>>> much more powerful interface, it also means all of the applications >>>>> will have to properly support all of the various possible >>>>> representations of the data, increasing the responsibility in userland >>>>> considerably. >>> >>> Not necessarily, the application can simply chose to support what >>> the driver provides as is, thereby doing no translations at all. >> >>> From the end user point of view it is not very usefull if he has 2 >> different cards and application can not show any usefull signal goodness >> info in a way that would be easy to compare. So I think the attempt to >> standardize to db is good. > > The first part: For comparison having a standardized value is good. > > True. > > But the problem that surrounds it: > > To do this, a driver should support statistics in dB. For a device > which doesn't show statistics in dB, for reasons > (a) device uses a different format > > (b) enough information is not available to do a conversion >   (too less information, or a reverse engineered driver) > > (c) the conversion to be done makes things too complex in kernel land. > > So you have very less devices to do a comparison between. > > The other way to do this: > > Suppose, the driver that doesn't support a dB format (relative > doesn't mean unknown) provides the information in a relative format. > And the driver that provides the information in dB format, but that > information you get, can be converted in to a relative floor - > ceiling format (conversion handled by application, or by a library) > > This is a quick way. > > Now, which all devices do provide a scale in dB, which is really > comparable ? There are many different parameters, quickly hacked > together to be called SNR. In the terms you mention, you will be > comparing things like > > SNR to CNR etc based on the device type. > > So eventually your comparison is wrong. > > >> Maybe there could then in addition be some other optional method for >> also getting data in some hw specific format in a way that Manu suggested. >> But there should anyway be mandatory to have this one "standard goodness >> value" in a way that does not require apps to make any complicate >> comparisons... (I bet half of those apps would be broken for years) > > > In the way i mentioned, it leaves to the application to choose from > different styles such as > > (1) display parameters from the drivers, in their own native format > (This is a completely human readable format, in which you can see > the real scales) > > (2) convert parameters to a specific format. > (The very important part here is that the application is free to > convert from format A with driver X and  format B with driver Y, to > get it into a unified format. if you really need the feature what > you mentioned, you need this feature, rather than have all drivers > being modified to provide one standard format) > > To make things look simple, i have a sample application which does > (1) to make things look simple. > > If you choose to do (2) It will be just doing the conversion one > time in a library or application, once rather than doing it multiple > times in unknown ways and formats. Hello Manu, First off, a large part of your argument lies in the notion that many of the devices do not support representing the SNR in dB. However, when I sent around the list in an attempt to do an inventory of what formats were used by different demods, you didn't provide any actual information. Could you please look at the following list, and if you know of how "unknown" demods do their SNR, provide the information? http://www.devinheitmueller.com/snr.txt My argument for doing it in dB was based on the inventory suggesting that the vast majority of *known* devices do it that way. If this is incorrect, then how about providing some actual data so we have better decision making? I do agree that people should not be putting CNR data into the SNR field. If there are known cases where that happens, they should be removed. The CNR can be used to represent the "strength" field, but it is not the same as the SNR and shouldn't be treated as such. Also, things like putting AGC feedback in that field should be removed as well (or moved to the strength field). I haven't raised this argument yet, but I also believe that once we make this change, all the cases where the format for the SNR is "unknown" should be "#ifdef 0" and return ENOSYS. If nobody can tell us what the format is, it's better to return nothing at all then mislead users with garbage data. Devin
Devin Heitmueller wrote: > On Tue, Mar 24, 2009 at 7:46 PM, Manu Abraham <abraham.manu@gmail.com> wrote: >> Mika Laitio wrote: >>>>>> That said, the solution takes the approach of "revolutionary" as >>>>>> opposed to "evolutionary", which always worries me. While providing a >>>>>> much more powerful interface, it also means all of the applications >>>>>> will have to properly support all of the various possible >>>>>> representations of the data, increasing the responsibility in userland >>>>>> considerably. >>>> Not necessarily, the application can simply chose to support what >>>> the driver provides as is, thereby doing no translations at all. >>>> From the end user point of view it is not very usefull if he has 2 >>> different cards and application can not show any usefull signal goodness >>> info in a way that would be easy to compare. So I think the attempt to >>> standardize to db is good. >> The first part: For comparison having a standardized value is good. >> >> True. >> >> But the problem that surrounds it: >> >> To do this, a driver should support statistics in dB. For a device >> which doesn't show statistics in dB, for reasons >> (a) device uses a different format >> >> (b) enough information is not available to do a conversion >> (too less information, or a reverse engineered driver) >> >> (c) the conversion to be done makes things too complex in kernel land. >> >> So you have very less devices to do a comparison between. >> >> The other way to do this: >> >> Suppose, the driver that doesn't support a dB format (relative >> doesn't mean unknown) provides the information in a relative format. >> And the driver that provides the information in dB format, but that >> information you get, can be converted in to a relative floor - >> ceiling format (conversion handled by application, or by a library) >> >> This is a quick way. >> >> Now, which all devices do provide a scale in dB, which is really >> comparable ? There are many different parameters, quickly hacked >> together to be called SNR. In the terms you mention, you will be >> comparing things like >> >> SNR to CNR etc based on the device type. >> >> So eventually your comparison is wrong. >> >> >>> Maybe there could then in addition be some other optional method for >>> also getting data in some hw specific format in a way that Manu suggested. >>> But there should anyway be mandatory to have this one "standard goodness >>> value" in a way that does not require apps to make any complicate >>> comparisons... (I bet half of those apps would be broken for years) >> >> In the way i mentioned, it leaves to the application to choose from >> different styles such as >> >> (1) display parameters from the drivers, in their own native format >> (This is a completely human readable format, in which you can see >> the real scales) >> >> (2) convert parameters to a specific format. >> (The very important part here is that the application is free to >> convert from format A with driver X and format B with driver Y, to >> get it into a unified format. if you really need the feature what >> you mentioned, you need this feature, rather than have all drivers >> being modified to provide one standard format) >> >> To make things look simple, i have a sample application which does >> (1) to make things look simple. >> >> If you choose to do (2) It will be just doing the conversion one >> time in a library or application, once rather than doing it multiple >> times in unknown ways and formats. > > Hello Manu, > Hi Devin, > First off, a large part of your argument lies in the notion that many > of the devices do not support representing the SNR in dB. My comment has some few points, of which the dB scale thing is just one among them. It could be a major aspect, depending on how you perceive it. > However, > when I sent around the list in an attempt to do an inventory of what > formats were used by different demods, you didn't provide any actual > information. Being on the lists for quite a while and following the developments with some amount of information, i was under the belief that it would have been obvious and did not give much importance to the same. > Could you please look at the following list, and if you > know of how "unknown" demods do their SNR, provide the information? > > http://www.devinheitmueller.com/snr.txt Sure, of course. Here is an updated list based on the information that you accumulated. I have corrected some of them, which were not accurate. af9013.c 0.1 dB at76c651.c unknown au8522.c 0.1 dB bcm3510.c unknown (vals > 1000) cinergyT2.c dB * 256 cx22700.c unknown cx22702.c unknown cx24110.c ESN0 cx24116.c percent scaled to 0-0xffff, support for ESN0 cx24123.c Inverted ESN0 dib3000mb.c unknown dib3000mc.c always zero (0.1dB possible [pboettch]) dib7000m.c always zero (0.1dB possible [pboettch]) dib7000p.c always zero (0.1dB possible [pboettch]) drx397xD.c always zero dst(s/c/t) (Inverted relative, if scaled confirms to API) dvb_dummy_fe.c always zero l64781.c (Relative, confirms to API) lgdt330x.c dB * 256 lgdt3304.c always zero lgdt3305.c 0.1 dB lgs8gl5.c unknown mt312.c (Relative, confirms to API3.3) mt352.c (Relative, confirms to API) (0.1dB possible in hardware) nxt200x.c approximated to dB (uC provides some 4 - 5 steps) nxt6000.c unknown or51132.c dB * 256 or51211.c dB * 256 s5h1409.c 0.1 dB s5h1411.c 0.1 dB s5h1420.c unsupported si21xx.c CNR Relative (scaled to 0-0xffff) sp8870.c unsupported sp887x.c unknown stv0299 (Relative, confirms to API) stv0288.c (Relative, confirms to API) stv0297.c (Relative, confirms to API, floor/ceiling undefined) stv0299.c unknown tda10021.c (Relative, confirms to API) tda10023.c (Relative, confirms to API) tda10048.c 0.1 dB tda1004x.c (Relative, confirms to API) tda10086.c (Relative, confirms to API) tda8083.c (Relative, confirms to API, floor ceiling undefined) tda80xx.c unknown ves1820.c unknown ves1x93.c unknown zl10353.c (Relative, confirms to API) (0.1dB possible in hardware) stb0899_drv.c CNR, Es/No mb86a16 CNR (approximated) > My argument for doing it in dB was based on the inventory suggesting > that the vast majority of *known* devices do it that way. If this is > incorrect, then how about providing some actual data so we have better > decision making? Sure. > I do agree that people should not be putting CNR data into the SNR > field. If there are known cases where that happens, they should be > removed. Hmm.. (scratching head and pulls out a few hairs)... > The CNR can be used to represent the "strength" field, but > it is not the same as the SNR and shouldn't be treated as such. A bit of signal theory, here: The Carrier in this case is the modulated signal. In some cases it can be an IQ modulated signal, or in another case it could be a QPSK demodulation. Eventually, Carrier is "the Signal", at a certain stage in the whole pipeline. In fact, CNR (aka Carrier to Noise Ratio) is very similar to SNR (Signal to Noise Ratio) except that CNR is obtained just before demodulation stage and that is the only one difference between them. Both are Signal ratios with respect to Noise, SNR is proportional and smaller compared to CNR for the same reasons, that the "actual Signal" might be much "smaller" in comparison to the carrier, which is used for modulation. In such a case you can't use CNR to represent strength, but in fact can be used to used to represent SNR in some proportional way. http://en.wikipedia.org/wiki/Signal-to-noise_ratio http://en.wikipedia.org/wiki/Carrier_to_Noise_Ratio > Also, > things like putting AGC feedback in that field should be removed as > well (or moved to the strength field). > > I haven't raised this argument yet, but I also believe that once we > make this change, all the cases where the format for the SNR is > "unknown" should be "#ifdef 0" and return ENOSYS. If nobody can tell > us what the format is, it's better to return nothing at all then > mislead users with garbage data. Though it looks like a purist's approach, this would just remove whatever feature that a driver is having currently. If you can't add features into a driver, it's not a big deal. But it is not really a cool thing to remove a feature which is even partially working to some extent: a way in which it is documented a considered working to many users. Just telling users that what statistics what they have been seeing are going to be removed, just because it is not a dB scale might not sound really attractive or useful. In fact most of the drivers use that parameter scaled to what the API currently state. Some recent drivers have been using different formats than what the API described and hence the whole confusion. As i mentioned earlier, the API doesn't export units for these parameters for teh same mentioned reasons, that there are much different units and things to be considered which would make things too complex for a driver author and hence it has such a definition. Regards, Manu -- 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 Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham <abraham.manu@gmail.com> wrote: > Sure, of course. Here is an updated list based on the information > that you accumulated. I have corrected some of them, which were not > accurate. Before I comment any further on your email, could you please clarify what you mean by "Relative, confirms to API". The current DVB API specification does not specify any units of measure for the content of the field, so I am not sure what you mean by this. Thanks, Devin
On Wed, Mar 25, 2009 at 6:27 PM, Devin Heitmueller <devin.heitmueller@gmail.com> wrote: > Before I comment any further on your email, could you please clarify > what you mean by "Relative, confirms to API". Â The current DVB API > specification does not specify any units of measure for the content of > the field, so I am not sure what you mean by this. <ping> Devin
Devin Heitmueller wrote: > On Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham <abraham.manu@gmail.com> wrote: >> Sure, of course. Here is an updated list based on the information >> that you accumulated. I have corrected some of them, which were not >> accurate. > > Before I comment any further on your email, could you please clarify > what you mean by "Relative, confirms to API". The current DVB API > specification does not specify any units of measure for the content of > the field, so I am not sure what you mean by this. Sorry about not responding earlier, wasn't feeling well at all and hence. By Relative, i meant dimensionless, but still it makes some sense based on some documented references. What i mean "relative" is that the API expects something like this. http://linuxtv.org/hg/dvb-apps/file/5fbdd3f898b1/util/szap/README Regards, Manu -- 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 -r 421de709288e linux/drivers/media/dvb/dvb-core/dvb_frontend.c --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Mar 18 23:42:34 2009 +0400 +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Mar 25 01:22:31 2009 +0400 -1607,6 +1607,13 @@ break; } + case FE_STATISTICS_CAPS: { + struct fecap_statistics *stats_cap = parg; + memcpy(stats_cap, &fe->ops.statistics_caps, sizeof (struct fecap_statistics)); + err = 0; + break; + } + case FE_READ_STATUS: { fe_status_t* status = parg; -1622,6 +1629,17 @@ err = fe->ops.read_status(fe, status); break; } + + case FE_SIGNAL_LEVEL: + if (fe->ops.read_level) + err = fe->ops.read_level(fe, (__u32 *) parg); + break; + + case FE_SIGNAL_STATS: + if (fe->ops.read_stats) + err = fe->ops.read_stats(fe, (struct fesignal_stat *) parg); + break; + case FE_READ_BER: if (fe->ops.read_ber) err = fe->ops.read_ber(fe, (__u32*) parg); diff -r 421de709288e linux/drivers/media/dvb/dvb-core/dvb_frontend.h --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Mar 18 23:42:34 2009 +0400 +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Mar 25 01:22:31 2009 +0400 -252,6 +252,7 @@ struct dvb_frontend_ops { struct dvb_frontend_info info; + struct fecap_statistics statistics_caps; void (*release)(struct dvb_frontend* fe); void (*release_sec)(struct dvb_frontend* fe); -298,6 +299,9 @@ */ enum dvbfe_search (*search)(struct dvb_frontend *fe, struct dvb_frontend_parameters *p); int (*track)(struct dvb_frontend *fe, struct dvb_frontend_parameters *p); + + int (*read_level)(struct dvb_frontend *fe, u32 *signal); /* Raw AGC level */ + int (*read_stats)(struct dvb_frontend *fe, struct fesignal_stat *stat); struct dvb_tuner_ops tuner_ops; struct analog_demod_ops analog_ops; diff -r 421de709288e linux/drivers/media/dvb/frontends/stb0899_drv.c --- a/linux/drivers/media/dvb/frontends/stb0899_drv.c Wed Mar 18 23:42:34 2009 +0400 +++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c Wed Mar 25 01:22:31 2009 +0400 -1226,6 +1226,29 @@ return 0; } +static int stb0899_read_level(struct dvb_frontend *fe, u32 *signal) +{ + /* TODO! */ + return 0; +} + +static int stb0899_read_stats(struct dvb_frontend *fe, struct fesignal_stat *stats) +{ + u16 snr, strength; + u32 ber; + + stb0899_read_snr(fe, &snr); + stb0899_read_signal_strength(fe, &strength); + stb0899_read_ber(fe, &ber); + + stats->quality = snr; + stats->strength = strength; + stats->error = ber; + stats->unc = 0; + + return 0; +} + static int stb0899_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage) { struct stb0899_state *state = fe->demodulator_priv; -1917,6 +1940,27 @@ FE_CAN_QPSK }, + .statistics_caps = { + .quality = { + .params = FE_QUALITY_CNR, + .scale = FE_SCALE_dB, + .exponent = -4, + }, + + .strength = { + .params = FE_SCALE_dB, + .exponent = -4, + }, + + .error = { + .params = FE_ERROR_BER, + .exponent = 7, + }, + + .unc = FE_UNC_UNKNOWN, + + }, + .release = stb0899_release, .init = stb0899_init, .sleep = stb0899_sleep, -1934,6 +1978,9 @@ .read_snr = stb0899_read_snr, .read_signal_strength = stb0899_read_signal_strength, .read_ber = stb0899_read_ber, + + .read_level = stb0899_read_level, + .read_stats = stb0899_read_stats, .set_voltage = stb0899_set_voltage, .set_tone = stb0899_set_tone, diff -r 421de709288e linux/include/linux/dvb/frontend.h --- a/linux/include/linux/dvb/frontend.h Wed Mar 18 23:42:34 2009 +0400 +++ b/linux/include/linux/dvb/frontend.h Wed Mar 25 01:22:31 2009 +0400 -413,4 +413,120 @@ #define FE_DISHNETWORK_SEND_LEGACY_CMD _IO('o', 80) /* unsigned int */ + +/* Frontend General Statistics + * General parameters + * FE_*_UNKNOWN: + * Parameter is unknown to the frontend and doesn't really + * make any sense for an application. + * + * FE_*_RELATIVE: + * Parameter is relative on the basis of a ceil - floor basis + * Format is based on empirical test to determine + * the floor and ceiling values. This format is exactly the + * same format as the existing statistics implementation. + */ +enum fecap_quality_params { + FE_QUALITY_UNKNOWN = 0, + FE_QUALITY_SNR = (1 << 0), + FE_QUALITY_CNR = (1 << 1), + FE_QUALITY_EsNo = (1 << 2), + FE_QUALITY_EbNo = (1 << 3), + FE_QUALITY_RELATIVE = (1 << 31), +}; + +enum fecap_scale_params { + FE_SCALE_UNKNOWN = 0, + FE_SCALE_dB = (1 << 0), + FE_SCALE_RELATIVE = (1 << 31), +}; + +enum fecap_error_params { + FE_ERROR_UNKNOWN = 0, + FE_ERROR_BER = (1 << 0), + FE_ERROR_PER = (1 << 1), + FE_ERROR_RELATIVE = (1 << 31), +}; + +enum fecap_unc_params { + FE_UNC_UNKNOWN = 0, + FE_UNC_RELATIVE = (1 << 31), +}; + +/* General parameters + * width: + * Specifies the width of the field + * + * exponent: + * Specifies the multiplier for the respective field + * MSB:1bit indicates the signdness of the parameter + */ +struct fecap_quality { + enum fecap_quality_params params; + enum fecap_scale_params scale; + + __u32 width; + __s32 exponent; +}; + +struct fecap_strength { + enum fecap_scale_params params; + __u32 width; + __s32 exponent; +}; + +struct fecap_error { + enum fecap_error_params params; + __u32 width; + __s32 exponent; +}; + +struct fecap_statistics { + struct fecap_quality quality; + struct fecap_strength strength; + struct fecap_error error; + enum fecap_unc_params unc; +}; + +/* FE_STATISTICS_CAPS + * Userspace query for frontend signal statistics capabilities + */ +#define FE_STATISTICS_CAPS _IOR('o', 84, struct fecap_statistics) + + +/* FE_SIGNAL_LEVEL + * This system call provides a direct monitor of the signal, without + * passing through the relevant processing chains. In many cases, it + * is simply considered as direct AGC1 scaled values. This parameter + * can generally be used to position an antenna to while looking at + * a peak of this value. This parameter can be read back, even when + * a frontend LOCK has not been achieved. Some microntroller based + * demodulators do not provide a direct access to the AGC on the + * demodulator, hence this parameter will be Unsupported for such + * devices. + */ +#define FE_SIGNAL_LEVEL _IOR('o', 85, __u32) + + +struct fesignal_stat { + __u32 quality; + __u32 strength; + __u32 error; + __u32 unc; +}; + +/* FE_SIGNAL_STATS + * This system call provides a snapshot of all the receiver system + * at any given point of time. System signal statistics are always + * computed with respect to time and is best obtained the nearest + * to each of the individual parameters in a time domain. + * Signal statistics are assumed, "at any given instance of time". + * It is not possible to get a snapshot at the exact single instance + * and hence we look at the nearest instance, in the time domain. + * The statistics are described by the FE_STATISTICS_CAPS ioctl, + * ie. based on the device capabilities. + */ +#define FE_SIGNAL_STATS _IOR('o', 86, struct fesignal_stat) + + #endif /*_DVBFRONTEND_H_*/