Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote: > On Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Wed, Mar 25, 2009 at 6:27 PM, Devin Heitmueller 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. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
VDR User wrote: > On Thu, Mar 19, 2009 at 11:55 PM, Manu Abraham wrote: >> * At the peak, you will get the maximum quality >> * falling down the slope to the left and right you will get falling >> signal strengths >> * Still rolling down, you will get increasing ERROR's, with still >> UNCORRECTABLES being steady. >> * Still falling down at the thresholds where you are about to loose >> frontend LOCK, you will see UNCORRECTABLE's getting incremented. >> >> Couple this logic into a program, with a feedback to the ROTOR and >> you get an automated satellite positioner, with a good fine tuned >> position. > > This would make for a very very useful tool to have. I can't count > the number of times I've seen people inquire about tools to help them > aim their dish and this sounds like the perfect solution to that long > standing problem. Especially if it returned the network id once it's > achieve a lock so the user can see if he's pointed to the correct > satellite. If you have a motor and you are able to automatically peak satellites, the only thing missing is a program to find all the signals automatically, including the ones which are turned on and off in a matter of minutes. Just google for *blindscan* (and maybe my name) to find a utility I wrote years ago and abandoned after failing to get the corresponding mt312-autosymbolrate kernel patch integrated. Next step, automatically upload found signals on some site, maybe including a frame from the received video stream and let users comment/moderate interesting ones on a sort of forum. :-) H, feeds... Best regards. -- Roberto Ragusamail at robertoragusa.it -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham 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 -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote: > On Tue, Mar 24, 2009 at 7:46 PM, Manu Abraham 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.c0.1 dB at76c651.c unknown au8522.c0.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-0x, 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 alway
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Tue, Mar 24, 2009 at 7:46 PM, Manu Abraham 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 J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More major
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Tue, 2009-03-24 at 18:08 -0400, Steven Toth wrote: > >> Let me ask this rhetorical question: if we did nothing more than just > >> normalize the SNR to provide a consistent value in dB, and did nothing > >> more than normalize the existing strength field to be 0-100%, leaving > >> it up to the driver author to decide the actual heuristic, what > >> percentage of user's needs would be fulfilled? > > We don't need a new API and more complexity and/or code confusion, just > standardize on the unit values for the existing APIs. > > 1) SNR in either units of db or units of .1 db (I don't care which, although > I > prefer the later). Devin, ETSI TR 101 290 v1.2.1 can provide some guidance and information on conversion of measurement quantities. For example, as part of a conversion from Es/No to S/N, Annex G, G.2 and G.3 tells you the right factor to use to convert from No to N. Here's where to go to download the document: http://pda.etsi.org/pda/queryform.asp (Free registration required. Downloads of DVB docs are free.) The list of DVB standards is here: http://www.dvb.org/technology/standards/index.xml Regards, Andy > 2) Strength as a percentage. > > The approach Devin outlined above has my support. > > - Steve > -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Tue, Mar 24, 2009 at 4:46 PM, Manu Abraham 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote:
> On Sun, Mar 22, 2009 at 9:00 PM, Devin Heitmueller
> wrote:
>> Wow, well this literally kept me up all night pondering the various options.
>>
>> Manu's idea has alot of merit - providing a completely new API that
>> provides the "raw data without translation" as well as a way to query
>> for what that format is for the raw data, provides a great deal more
>> flexibility for applications that want to perform advanced analysis
>> and interpretation of the data.
>>
>> 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.
The change to the application is rather quite small, as you can see
from the quick patch and a modified femon.
>From what you see, it should be that simple.
>> Let me ask this rhetorical question: if we did nothing more than just
>> normalize the SNR to provide a consistent value in dB, and did nothing
>> more than normalize the existing strength field to be 0-100%, leaving
>> it up to the driver author to decide the actual heuristic, what
>> percentage of user's needs would be fulfilled?
>>
>> I bet the answer would be something like 99%.
You can really scale values to dB only if it is in some dB scale.
Looking at the drivers there are hardly a few drivers that do in dB.
If it were to be standardized in to "one standard format" i would
rather prefer to have the format what the API currently suggests:
That is to have a floor - ceiling value, without any units, rather
than one which forces all drivers to dB (in this case the drivers
which do not will be considered broken), the reason being this
hardly helps a few drivers, while the reverse holds true for all.
Regards,
Manu
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,
+ },
+
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Let me ask this rhetorical question: if we did nothing more than just normalize the SNR to provide a consistent value in dB, and did nothing more than normalize the existing strength field to be 0-100%, leaving it up to the driver author to decide the actual heuristic, what percentage of user's needs would be fulfilled? We don't need a new API and more complexity and/or code confusion, just standardize on the unit values for the existing APIs. 1) SNR in either units of db or units of .1 db (I don't care which, although I prefer the later). 2) Strength as a percentage. The approach Devin outlined above has my support. - Steve -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Sun, Mar 22, 2009 at 9:00 PM, Devin Heitmueller wrote: > Wow, well this literally kept me up all night pondering the various options. > > Manu's idea has alot of merit - providing a completely new API that > provides the "raw data without translation" as well as a way to query > for what that format is for the raw data, provides a great deal more > flexibility for applications that want to perform advanced analysis > and interpretation of the data. > > 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. > > Let me ask this rhetorical question: if we did nothing more than just > normalize the SNR to provide a consistent value in dB, and did nothing > more than normalize the existing strength field to be 0-100%, leaving > it up to the driver author to decide the actual heuristic, what > percentage of user's needs would be fulfilled? > > I bet the answer would be something like 99%. > > I can see the value in an "advanced API" that could provide the > underlying raw data, but I feel like this could be provided in the > future at any point that someone cares enough to do the work. > > We can spend weeks debating and trying to design the "perfect > interface" (and possibly never come to an agreement as has gone on for > years), or we can just make a decision on how to represent the two > values that is "good enough", and we can have 99% of the population > satisfied virtually overnight (with the ability to provide an advanced > API to get the raw data in the future if there is ever sufficient > need). > > I'm willing to submit the patches for all the ATSC demods to conform > to the final API if the experts can just decide on what the format > should be. > > Devin Any other demod authors want to weigh in on this matter? Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Sat, Mar 21, 2009 at 10:45 PM, Andy Walls wrote:
> There are lots of interesting ideas here. From the implementation Manu
> has presented to explain his ideas, let me separate out the problem
> statement, concept, content, and form from each other and comment on
> those separately.
>
>
>
> 1. Problem (re-)statement:
>
> My understanding of what Manu is saying is, that there is a larger
> problem of getting useful statistics out of the drivers to userspace in
> a form applications can *understand in general* and then present to the
> user in their preferred format.
>
> This restatement raises the problem up a level from the original
> discussion threads.
>
> I think Manu's restatement of the problem, as I understand it, is a
> better way to look at the problem, and hence for solutions.
>
>
>
> 2. Concept:
>
> The essential elements of Manu's concept, as I understand it, are to
> provide to userspace
>
> a) Measurement values in their "native form" from the hardware, without
> manipulation into another form.
>
> b) Meta-data about the various measurement values (including as to
> whether or not they are supported at all), so that the application can
> know exaclty how to process the measurement values that are provided in
> "native form" from the hardware.
>
>
> I'm OK with this concept. It is easy to understand from the kernel side
> of things. It provides flexibility to do more in userspace, which may
> come with some complexity to applications unfortunately.
>
> What seemed most interesting about this concept is, per the examples
> Manu discussed and Trent provided, the ability to perform userspace
> control/tracking loops using a) the values directly in an automated
> process or b) the values converted into human readable form in a manual
> process.
>
>
>
> 3. Content:
>
> In the presented implmentation, I saw the following data items
> identified as going from kernel space to userspace:
>
> a) Measurement values
> "raw" signal level
> quality (SNR, CNR, Eb/No, etc.)
> strength (dB, dBuV, etc.)
> error rate (BER, PER)
> uncorrectable blocks
>
> b) Meta-data about the measurment values
> Signedness (signed or unsigned)
> Width (8, 16, 24, or 32 bits)
> Units (SNR_dB, CNR_dB, PER, MER, relative/dimensionless, etc.)
> Exponent (base 10, scales the measurement value for the unit.)
>
>
> The types of measurment values in the above, I'm assuming, come from
> Manu's fairly complete survey or knowledge of what's currently available
> in devices. They look OK to me.
>
> For the meta-data, I'll make the following suggestions:
>
> a) It may be possible to just cast everything to a 32 bit width on the
> way out of the kernel and thus dispense with the "width" meta-data.
>
> b) It may be useful for the driver to provide as meta-data the possible
> bottom of scale and top of scale values for the measurement values.
>
>
>
> 4. Form:
>
> The form of the solution presented in the small implementation has 3 new
> ioctls, 2 new data structures, and 4 new enumerations. I think that
> this small implementation was excellent for presenting the concept and
> communicating the ideas.
>
> I'm not so sure it the best final form for such an interface. Possible
> drawbacks are:
>
> a. Meta-data information is combined, creating larger enumerations
> (case:s in a switch() statement) that applications have to deal with.
> Signedness is combined with Width; that's not so bad. Units is combined
> with Exponent, making 'enum fecap_errors' rather large. This is likely
> fixable with modification to the presented implementation.
>
> b. A new type of measurment in a new hardware device means a change in
> the message structure. In the presented implementation, I'm not sure
> there's a good way to fix this. (I'm not sure how much of a drawback
> this is in reality, my crystal ball is broken...)
>
> c. It makes 3 allocations from the space of possible ioctl values. I am
> under the impression using new ioctls is to be avoided. I don't know if
> that impression is justified. For perspective, currently about 93 of
> the 256 type 'o' ioctl numbers are in use by dvb and 73 of the 256 type
> 'V' ioctl numbers are in use by v4l.
>
>
>
> As an alternative form for the interface between the kernel and
> userspace, I can suggest
>
> a. using the FE_GET_PROPERTY ioctl
>
> b. new defines to use for getting the measurment values and metadata
> with FE_GET_PROPERTY. For example, for the quality measurment and
> meta-data:
>
> #define DTV_QUALITY_SIGNEDNESS 41
> #define DTV_QUALITY_WIDTH 42 (or DTV_QUALITY_SIGN_WIDTH with values like -32
> meaning 32 bit signed)
> #define DTV_QUALITY_UNIT 43
> #define DTV_QUALITY_EXPONENT 44
> #define DTV_QUALITY_TOP_OF_SCALE 45
> #define DTV_QUALITY_BOTTOM_OF_SCALE 46
>
> #define DTV_QUALITY 47
>
>
> c. Variaitons of the enums Manu presented for the meta-data. For
> example for quality:
>
> enum fe_quality_unit {
> FE_QUALITY_UNKOW
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Andy Walls wrote:
> On Fri, 2009-03-20 at 10:55 +0400, Manu Abraham wrote:
>> Manu Abraham wrote:
>
>>> I have been going through this thread with much interest to see
>>> where it was going.
>>>
>>> In fact, what i found after reading the emails in this thread:
>>>
>>> People would like to see standardized Signal stats in whatever apps
>>> they like.
>>>
>>> * Some users prefer a dB scale
>>> * Some users prefer a percent scale
>>> * Some prefer a relative scale.
>>>
>>> Some need a signal monitor to do specific activity.
>>>
>>> All this needs one to require the existing format into one common
>>> format as required, which needs all drivers to be converted.
>>>
>>> The Pros:
>>>
>>> * Application can just read the value from the IOCTL and be happy
>>> dispalying the value.
>>>
>>> The Cons:
>>>
>>> * Converting all drivers is no joke. Many drivers are Reverse
>>> Engineered, Some are written from specs, Some are written from
>>> sample code.
>>>
>>> * Assuming that everything is alright, many do think that statistics
>>> can be just used in a 1:1 proportion depending on some sample code.
>>> But it has to be borne in mind that it is for a very specific
>>> reference platform that it is. Lot of things do affect it directly.
>>> Eventually what you consider statistics from a demod driver, from
>>> where you get statistics, depends on other frontend components.
>>>
>>> * Now assume that it is correct for the reference platform too..
>>> Just think how many users are really conversant with all those units
>>> and how to interpret it .. ? I would say hardly few ...
>>>
>>> * Doing format/protocol conversions in kernel is not something
>>> that's appreciated.
>>>
>>> * Different types of conversions would be needed. All the conersions
>>> need to be foolproof, else you shoot your foot, with some odd values
>>> as well..
>>>
>>> * This concept provides a single format with little or no flexibility.
>>>
>>>
>>> I had been thinking a bit on this in the large view. My idea was
>>> that it would be better not not to modify any driver as it is, but
>>> get that value out to userspace with that exact representation.
>>>
>>> The current existing API does the statistics correctly, but all it
>>> needs is that the user/application needs to be told what units it
>>> expects the statistics in.
>>>
>>> That said, i did a small implementation, with almost all parctical
>>> possible combinations.
>>>
>>> The Pros:
>>>
>>> * Application can choose whether it wants to display the statistics
>>> in a specific way the application would like
>>>
>>> * Application can also choose what format the driver provides too..
>>>
>>> * Format conversions are simple at userspace
>>>
>>> * The driver just mentions what format it is using and sends out the
>>> values are being read and calculated for the hardware requirements.
>>> No conversions are done in the driver.
>>>
>>>
>>> The Cons:
>>>
>>> * The application has to do the format conversion. ie the driver
>>> does not force the application to use a specific format. In other
>>> words, it is more flexibility to the application.
>>>
>>> That said, my thoughts follow thus. I guess it hardly needs any
>>> explanation. But if any queries, i am here around.
>>>
>>>
>>>
>>> /* 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.
>>> *
>>> * FE_*_PAD:
>>> * Parameter is used as a Pad variable, not of any use to the
>>> * userspace world.
>>> */
>>>
>>> /* Statistics format
>>> * FE_FORMAT_S32:Signed 32 bits
>>> * FE_FORMAT_U32:Unsigned 32 bits
>>> * FE_FORMAT_U24:Unsigned 24 bits
>>> * FE_FORMAT_S24:Signed 24 bits
>>> * FE_FORMAT_S16:Signed 16 bits
>>> * FE_FORMAT_U16:Unsigned 16 bits
>>> * FE_FORMAT_S08:Signed 8 bits
>>> * FE_FORMAT_U08:Unsigned 8 bits
>>> */
>>> enum fecap_format {
>>> FE_FORMAT_UNKNOWN = 0,
>>> FE_FORMAT_S32,
>>> FE_FORMAT_S24,
>>> FE_FORMAT_S16,
>>> FE_FORMAT_S08,
>>> FE_FORMAT_U32,
>>> FE_FORMAT_U24,
>>> FE_FORMAT_U16,
>>> FE_FORMAT_U08,
>>>
>>> FE_FORMAT_PAD = 0x
>>> };
>>>
>>> /* Quality format
>>> * FE_QUALITY_SNR_dB_100:SNR in dB/100
>>> * FE_QUALITY_SNR_dB_10 :SNR in dB/10
>>> * FE_QUALITY_SNR_dB:SNR in dB
>>> * FE_QUALITY_CNR_dB_100:CNR in dB/100
>>> * FE_QUALITY_CNR_dB_10 :CNR in dB/10
>>> * FE_QUALITY_CNR_dB:CNR in dB
>>> * FE_QUALITY_EsNo :Es/No
>>> * FE_QUALITY_EbNo :Eb/No
>>> */
>>> enum fecap_qual
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, 2009-03-20 at 10:55 +0400, Manu Abraham wrote:
> Manu Abraham wrote:
> > I have been going through this thread with much interest to see
> > where it was going.
> >
> > In fact, what i found after reading the emails in this thread:
> >
> > People would like to see standardized Signal stats in whatever apps
> > they like.
> >
> > * Some users prefer a dB scale
> > * Some users prefer a percent scale
> > * Some prefer a relative scale.
> >
> > Some need a signal monitor to do specific activity.
> >
> > All this needs one to require the existing format into one common
> > format as required, which needs all drivers to be converted.
> >
> > The Pros:
> >
> > * Application can just read the value from the IOCTL and be happy
> > dispalying the value.
> >
> > The Cons:
> >
> > * Converting all drivers is no joke. Many drivers are Reverse
> > Engineered, Some are written from specs, Some are written from
> > sample code.
> >
> > * Assuming that everything is alright, many do think that statistics
> > can be just used in a 1:1 proportion depending on some sample code.
> > But it has to be borne in mind that it is for a very specific
> > reference platform that it is. Lot of things do affect it directly.
> > Eventually what you consider statistics from a demod driver, from
> > where you get statistics, depends on other frontend components.
> >
> > * Now assume that it is correct for the reference platform too..
> > Just think how many users are really conversant with all those units
> > and how to interpret it .. ? I would say hardly few ...
> >
> > * Doing format/protocol conversions in kernel is not something
> > that's appreciated.
> >
> > * Different types of conversions would be needed. All the conersions
> > need to be foolproof, else you shoot your foot, with some odd values
> > as well..
> >
> > * This concept provides a single format with little or no flexibility.
> >
> >
> > I had been thinking a bit on this in the large view. My idea was
> > that it would be better not not to modify any driver as it is, but
> > get that value out to userspace with that exact representation.
> >
> > The current existing API does the statistics correctly, but all it
> > needs is that the user/application needs to be told what units it
> > expects the statistics in.
> >
> > That said, i did a small implementation, with almost all parctical
> > possible combinations.
> >
> > The Pros:
> >
> > * Application can choose whether it wants to display the statistics
> > in a specific way the application would like
> >
> > * Application can also choose what format the driver provides too..
> >
> > * Format conversions are simple at userspace
> >
> > * The driver just mentions what format it is using and sends out the
> > values are being read and calculated for the hardware requirements.
> > No conversions are done in the driver.
> >
> >
> > The Cons:
> >
> > * The application has to do the format conversion. ie the driver
> > does not force the application to use a specific format. In other
> > words, it is more flexibility to the application.
> >
> > That said, my thoughts follow thus. I guess it hardly needs any
> > explanation. But if any queries, i am here around.
> >
> >
> >
> > /* 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.
> > *
> > * FE_*_PAD:
> > * Parameter is used as a Pad variable, not of any use to the
> > * userspace world.
> > */
> >
> > /* Statistics format
> > * FE_FORMAT_S32:Signed 32 bits
> > * FE_FORMAT_U32:Unsigned 32 bits
> > * FE_FORMAT_U24:Unsigned 24 bits
> > * FE_FORMAT_S24:Signed 24 bits
> > * FE_FORMAT_S16:Signed 16 bits
> > * FE_FORMAT_U16:Unsigned 16 bits
> > * FE_FORMAT_S08:Signed 8 bits
> > * FE_FORMAT_U08:Unsigned 8 bits
> > */
> > enum fecap_format {
> > FE_FORMAT_UNKNOWN = 0,
> > FE_FORMAT_S32,
> > FE_FORMAT_S24,
> > FE_FORMAT_S16,
> > FE_FORMAT_S08,
> > FE_FORMAT_U32,
> > FE_FORMAT_U24,
> > FE_FORMAT_U16,
> > FE_FORMAT_U08,
> >
> > FE_FORMAT_PAD = 0x
> > };
> >
> > /* Quality format
> > * FE_QUALITY_SNR_dB_100:SNR in dB/100
> > * FE_QUALITY_SNR_dB_10 :SNR in dB/10
> > * FE_QUALITY_SNR_dB:SNR in dB
> > * FE_QUALITY_CNR_dB_100:CNR in dB/100
> > * FE_QUALITY_CNR_dB_10 :CNR in dB/10
> > * FE_QUALITY_CNR_dB:CNR in dB
> > * FE_QUALITY_EsNo :Es/No
> > * FE_QUALITY_EbNo :Eb/No
> > */
> > enum
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, 20 Mar 2009, Devin Heitmueller wrote: > On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho wrote: > >> The argument being put forth is based on the relative efficiency of > >> the multiply versus divide opcodes on modern CPU architectures?? ?And > > > > Maybe I just like writing efficient code to do interesting things? > > Wow, um, ok. You realize that getting the SNR on most devices is > probably going to require an i2c call that is going to take a couple > hundred CPU instructions, not to mention I/O, right? And that you're > doing this in an expensive ioctl call? So perhaps a > micro-optimization with no visible gain, at the cost of readability > and complexity shouldn't be a overriding consideration? Did I submit a patch to modify dvb-apps? I just wanted to show how to convert fixed point numbers to IEEE 754 floating using only integer math. I think such things are interesting. > >> that you're going to be able to get an SNR with a higher level of > >> precision than 0.1 dB?? (if the hardware suggests that it can then > >> it's LYING to you) > > > > Not really. ?Absolute accuracy is not going to be that good of course. ?But > > the error measurements from which SNR is calculated do support precision of > > better than 0.1 dB. ?That precision does give you more power when fine > > tuning antenna position. > > > > Put another way, what advantage is there of less precision? > > Well, here is one disadvantage: The driver decides the SNR is 23.1. > So I convert that to your format: 0x1719. Then userland gets it back You've assumed the driver will find SNR in decimal fixed point. The lgdt demods and the oren demods all *start* with binary fixed point. So you have the opposite problem were converting to decimal fixed point changes the result. > and goes to display it. I'm going to show the user an SNR of > 23.09765625, and I have no way to know what the expected precision > (and thus I don't know where to round). So the end result is the user > sees a really stupid number in the GUI (and might actually think it is > more accurate than it really is). Or when I push patches to > applications I just round to 0.1dB anyway. It also means apps like > femon and zap are going to have to change to support a non-fixed width > result with no appreciable gain in value. Since 8 binary digits is 2.4 decimal digits, it's perfectly ok to display SNR with 3 fixed decimal digits. You could just as well round to 1 fixed decimal digit too, in which case you've got exactly what you'd get if you started with the decimal fixed point, except the extra precision is there for a situation where it is useful. > By saying explicitly there is one digit of precision - it allows for > applications to know how to round, and I continue to disagree with Binary fixed point says explicitly that there are 8 binary digits of precision. Decimal fixed point says there are 3.3219281 binary digits of precision. We stopped using BCD 30 years ago, computers do everything in binary now. -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Thu, Mar 19, 2009 at 11:55 PM, Manu Abraham wrote: > Well, that said positioning could be explained for those who on't > have an understanding on how to do it. > > Let's assume, currently at position "X" there is no signal, no > frontend LOCK. You can move the antenna to the approximate X-Y > co-ordinates for the Azimuth and Elevation for your required > transponder, while having an eye on FE_SIGNAL_LEVEL. > > While the FE_SIGNAL_LEVEL peaks for a given position, try to acquire > a frontend LOCK, with the transponder parameters. Most likely you > will get a frontend LOCK with the coarse positioning with AGC peak > values. > > Now, with the frontend LOCK, you can look for initially the peak > again, not the FE_SIGNAL_LEVEL peak in this case, but the > FE_SIGNAL_STATS peak. > > In this case you should not be looking at just the strength > parameter alone. > > * At the peak, you will get the maximum quality > * falling down the slope to the left and right you will get falling > signal strengths > * Still rolling down, you will get increasing ERROR's, with still > UNCORRECTABLES being steady. > * Still falling down at the thresholds where you are about to loose > frontend LOCK, you will see UNCORRECTABLE's getting incremented. > > Couple this logic into a program, with a feedback to the ROTOR and > you get an automated satellite positioner, with a good fine tuned > position. This would make for a very very useful tool to have. I can't count the number of times I've seen people inquire about tools to help them aim their dish and this sounds like the perfect solution to that long standing problem. Especially if it returned the network id once it's achieve a lock so the user can see if he's pointed to the correct satellite. -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho wrote: >> The argument being put forth is based on the relative efficiency of >> the multiply versus divide opcodes on modern CPU architectures?? And > > Maybe I just like writing efficient code to do interesting things? Wow, um, ok. You realize that getting the SNR on most devices is probably going to require an i2c call that is going to take a couple hundred CPU instructions, not to mention I/O, right? And that you're doing this in an expensive ioctl call? So perhaps a micro-optimization with no visible gain, at the cost of readability and complexity shouldn't be a overriding consideration? >> that you're going to be able to get an SNR with a higher level of >> precision than 0.1 dB?? (if the hardware suggests that it can then >> it's LYING to you) > > Not really. Absolute accuracy is not going to be that good of course. But > the error measurements from which SNR is calculated do support precision of > better than 0.1 dB. That precision does give you more power when fine > tuning antenna position. > > Put another way, what advantage is there of less precision? Well, here is one disadvantage: The driver decides the SNR is 23.1. So I convert that to your format: 0x1719. Then userland gets it back and goes to display it. I'm going to show the user an SNR of 23.09765625, and I have no way to know what the expected precision (and thus I don't know where to round). So the end result is the user sees a really stupid number in the GUI (and might actually think it is more accurate than it really is). Or when I push patches to applications I just round to 0.1dB anyway. It also means apps like femon and zap are going to have to change to support a non-fixed width result with no appreciable gain in value. By saying explicitly there is one digit of precision - it allows for applications to know how to round, and I continue to disagree with your assertion that you will get any better accuracy with that anyway. We could *in theory* provide a separate ioctl so the driver can know what the expected precision is, but I do not believe it is worthwhile to over-engineer the interface. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, Mar 20, 2009 at 2:55 AM, Manu Abraham wrote: > When you position an antenna, you do not get a LOCK in most cases. > The signal statistics for any demodulator are valid only with a > frontend LOCK. This is absolutely true, and a very common problem in the drivers (at least with the ATSC/QAM devices). Most of the drivers blindly return whatever value is in the register regardless of whether there is lock. One of the things I plan to do for the ATSC devices is go through each of them and make sure they properly return ENOSIGNAL when there is not a lock (this is actually already the defined behavior in the dvb v3 spec), as well as submitting patches for Kaffeine to properly reflect this state to the user. Cheers, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Manu Abraham wrote:
> Devin Heitmueller wrote:
>> On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho wrote:
>>> On Thu, 19 Mar 2009, Trent Piepho wrote:
Since the driver often needs to use a logarithm from dvb-math to find SNR,
you have code like this in the driver (from lgdt3305.c):
/* report SNR in dB * 10 */
*snr = (state->snr / ((1 << 24) / 10));
> The SNR(dB) will be given by:
> SNR(dB) = driver_SNR_measure / 256;
For the driver side, also from lgdt3305 which has both formats with an
ifdef:
/* convert from 8.24 fixed-point to 8.8 */
*snr = (state->snr) >> 16;
FWIW, converting to decimal to print using only integer math:
/* decimal fixed point */
printf("%d.%d dB\n", snr / 10, snr % 10);
/* binary fixed point */
printf("%d.%02d dB\n", snr >> 8, (snr & 0xff) * 100 >> 8);
>>> One more example, converting SNR into a 32-bit floating point number using
>>> only integer operations. These don't do negative numbers but if the SNR
>>> format used a sign bit it would be very easy to add, as IEEE 754 floating
>>> point uses a sign bit too. I would need to think about it more to do 2's
>>> complement.
>>>
>>> For binary fixed point the conversion to a float is exact. For decimal
>>> fixed point it's not. For example 334 (33.4 dB) will become 33.42 dB
>>> when converted to floating point.
>>>
>>> /* For 8.8 binary fixed point, this is the no-float version of:
>>> * float snr_to_float(u16 snr) { return snr / 256.0 } */
>>> u32 snr_to_float(u16 snr)
>>> {
>>>unsigned int e = 23 - __fls(snr);
>>>return snr ? ((snr << e) & 0x7f) | ((142 - e) << 23) : 0;
>>> }
>>>
>>> /* For .1 decimal fixed point. NOTE: This will overflow the 32-bit
>>> * intermediate value if SNR is above 1638.3 dB! This is the no-float
>>> * version of:
>>> * float snr_to_float(u16 snr) { return snr / 10.0 } */
>>> u32 snr10_to_float(u16 snr)
>>> {
>>>unsigned int e = 23 - __fls(snr / 10);
>>>return snr ? snr << e) + 5) / 10) & 0x7f) | (150 - e) << 23
>>> : 0;
>>> }
>>>
>>> You'd use the function like this:
>>>
>>>float f;
>>>*(u32 *)&f = snr_to_float(snr);
>>>
>> == rant mode on ==
>> Wow, I think we have lost our minds!
>>
>> The argument being put forth is based on the relative efficiency of
>> the multiply versus divide opcodes on modern CPU architectures?? And
>> that you're going to be able to get an SNR with a higher level of
>> precision than 0.1 dB?? (if the hardware suggests that it can then
>> it's LYING to you)
>>
>> If that is the extent of the compelling argument that can be made,
>> then so be it. But after reading this, I'm kind of dumbfounded that
>> this is the basis for proposing 8.8 format over just sending it back
>> in 0.1dB increments. We have officially entered the realm of
>> "ridiculous".
>
>
> I have been going through this thread with much interest to see
> where it was going.
>
> In fact, what i found after reading the emails in this thread:
>
> People would like to see standardized Signal stats in whatever apps
> they like.
>
> * Some users prefer a dB scale
> * Some users prefer a percent scale
> * Some prefer a relative scale.
>
> Some need a signal monitor to do specific activity.
>
> All this needs one to require the existing format into one common
> format as required, which needs all drivers to be converted.
>
> The Pros:
>
> * Application can just read the value from the IOCTL and be happy
> dispalying the value.
>
> The Cons:
>
> * Converting all drivers is no joke. Many drivers are Reverse
> Engineered, Some are written from specs, Some are written from
> sample code.
>
> * Assuming that everything is alright, many do think that statistics
> can be just used in a 1:1 proportion depending on some sample code.
> But it has to be borne in mind that it is for a very specific
> reference platform that it is. Lot of things do affect it directly.
> Eventually what you consider statistics from a demod driver, from
> where you get statistics, depends on other frontend components.
>
> * Now assume that it is correct for the reference platform too..
> Just think how many users are really conversant with all those units
> and how to interpret it .. ? I would say hardly few ...
>
> * Doing format/protocol conversions in kernel is not something
> that's appreciated.
>
> * Different types of conversions would be needed. All the conersions
> need to be foolproof, else you shoot your foot, with some odd values
> as well..
>
> * This concept provides a single format with little or no flexibility.
>
>
> I had been thinking a bit on this in the large view. My idea was
> that it would be better not not to modify any driver as it is, but
> get that value out to userspace with that exact representation.
>
> The current existing API does the statistics correctly, but all it
> needs is that the
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote:
> On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho wrote:
>> On Thu, 19 Mar 2009, Trent Piepho wrote:
>>> Since the driver often needs to use a logarithm from dvb-math to find SNR,
>>> you have code like this in the driver (from lgdt3305.c):
>>> /* report SNR in dB * 10 */
>>> *snr = (state->snr / ((1 << 24) / 10));
>>>
The SNR(dB) will be given by:
SNR(dB) = driver_SNR_measure / 256;
>>> For the driver side, also from lgdt3305 which has both formats with an
>>> ifdef:
>>> /* convert from 8.24 fixed-point to 8.8 */
>>> *snr = (state->snr) >> 16;
>>>
>>> FWIW, converting to decimal to print using only integer math:
>>>
>>> /* decimal fixed point */
>>> printf("%d.%d dB\n", snr / 10, snr % 10);
>>>
>>> /* binary fixed point */
>>> printf("%d.%02d dB\n", snr >> 8, (snr & 0xff) * 100 >> 8);
>> One more example, converting SNR into a 32-bit floating point number using
>> only integer operations. These don't do negative numbers but if the SNR
>> format used a sign bit it would be very easy to add, as IEEE 754 floating
>> point uses a sign bit too. I would need to think about it more to do 2's
>> complement.
>>
>> For binary fixed point the conversion to a float is exact. For decimal
>> fixed point it's not. For example 334 (33.4 dB) will become 33.42 dB
>> when converted to floating point.
>>
>> /* For 8.8 binary fixed point, this is the no-float version of:
>> * float snr_to_float(u16 snr) { return snr / 256.0 } */
>> u32 snr_to_float(u16 snr)
>> {
>>unsigned int e = 23 - __fls(snr);
>>return snr ? ((snr << e) & 0x7f) | ((142 - e) << 23) : 0;
>> }
>>
>> /* For .1 decimal fixed point. NOTE: This will overflow the 32-bit
>> * intermediate value if SNR is above 1638.3 dB! This is the no-float
>> * version of:
>> * float snr_to_float(u16 snr) { return snr / 10.0 } */
>> u32 snr10_to_float(u16 snr)
>> {
>>unsigned int e = 23 - __fls(snr / 10);
>>return snr ? snr << e) + 5) / 10) & 0x7f) | (150 - e) << 23 :
>> 0;
>> }
>>
>> You'd use the function like this:
>>
>>float f;
>>*(u32 *)&f = snr_to_float(snr);
>>
>
> == rant mode on ==
> Wow, I think we have lost our minds!
>
> The argument being put forth is based on the relative efficiency of
> the multiply versus divide opcodes on modern CPU architectures?? And
> that you're going to be able to get an SNR with a higher level of
> precision than 0.1 dB?? (if the hardware suggests that it can then
> it's LYING to you)
>
> If that is the extent of the compelling argument that can be made,
> then so be it. But after reading this, I'm kind of dumbfounded that
> this is the basis for proposing 8.8 format over just sending it back
> in 0.1dB increments. We have officially entered the realm of
> "ridiculous".
I have been going through this thread with much interest to see
where it was going.
In fact, what i found after reading the emails in this thread:
People would like to see standardized Signal stats in whatever apps
they like.
* Some users prefer a dB scale
* Some users prefer a percent scale
* Some prefer a relative scale.
Some need a signal monitor to do specific activity.
All this needs one to require the existing format into one common
format as required, which needs all drivers to be converted.
The Pros:
* Application can just read the value from the IOCTL and be happy
dispalying the value.
The Cons:
* Converting all drivers is no joke. Many drivers are Reverse
Engineered, Some are written from specs, Some are written from
sample code.
* Assuming that everything is alright, many do think that statistics
can be just used in a 1:1 proportion depending on some sample code.
But it has to be borne in mind that it is for a very specific
reference platform that it is. Lot of things do affect it directly.
Eventually what you consider statistics from a demod driver, from
where you get statistics, depends on other frontend components.
* Now assume that it is correct for the reference platform too..
Just think how many users are really conversant with all those units
and how to interpret it .. ? I would say hardly few ...
* Doing format/protocol conversions in kernel is not something
that's appreciated.
* Different types of conversions would be needed. All the conersions
need to be foolproof, else you shoot your foot, with some odd values
as well..
* This concept provides a single format with little or no flexibility.
I had been thinking a bit on this in the large view. My idea was
that it would be better not not to modify any driver as it is, but
get that value out to userspace with that exact representation.
The current existing API does the statistics correctly, but all it
needs is that the user/application needs to be told what units it
expects the statistics in.
That said, i did a small implementation, with almost all parctical
possible combinations.
The Pros:
* Application can cho
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Thu, 19 Mar 2009, Devin Heitmueller wrote: > On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho wrote: > > == rant mode on == > Wow, I think we have lost our minds! > > The argument being put forth is based on the relative efficiency of > the multiply versus divide opcodes on modern CPU architectures?? And Maybe I just like writing efficient code to do interesting things? > that you're going to be able to get an SNR with a higher level of > precision than 0.1 dB?? (if the hardware suggests that it can then > it's LYING to you) Not really. Absolute accuracy is not going to be that good of course. But the error measurements from which SNR is calculated do support precision of better than 0.1 dB. That precision does give you more power when fine tuning antenna position. Put another way, what advantage is there of less precision? > this is the basis for proposing 8.8 format over just sending it back > in 0.1dB increments. We have officially entered the realm of I've yet to see _any_ argument for using decimal fixed point. Just because binary fixed point isn't vastly superior to decimal doesn't make decimal better. -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho wrote:
> On Thu, 19 Mar 2009, Trent Piepho wrote:
>> Since the driver often needs to use a logarithm from dvb-math to find SNR,
>> you have code like this in the driver (from lgdt3305.c):
>> /* report SNR in dB * 10 */
>> *snr = (state->snr / ((1 << 24) / 10));
>>
>> > The SNR(dB) will be given by:
>> > SNR(dB) = driver_SNR_measure / 256;
>>
>> For the driver side, also from lgdt3305 which has both formats with an
>> ifdef:
>> /* convert from 8.24 fixed-point to 8.8 */
>> *snr = (state->snr) >> 16;
>>
>> FWIW, converting to decimal to print using only integer math:
>>
>> /* decimal fixed point */
>> printf("%d.%d dB\n", snr / 10, snr % 10);
>>
>> /* binary fixed point */
>> printf("%d.%02d dB\n", snr >> 8, (snr & 0xff) * 100 >> 8);
>
> One more example, converting SNR into a 32-bit floating point number using
> only integer operations. These don't do negative numbers but if the SNR
> format used a sign bit it would be very easy to add, as IEEE 754 floating
> point uses a sign bit too. I would need to think about it more to do 2's
> complement.
>
> For binary fixed point the conversion to a float is exact. For decimal
> fixed point it's not. For example 334 (33.4 dB) will become 33.42 dB
> when converted to floating point.
>
> /* For 8.8 binary fixed point, this is the no-float version of:
> * float snr_to_float(u16 snr) { return snr / 256.0 } */
> u32 snr_to_float(u16 snr)
> {
> unsigned int e = 23 - __fls(snr);
> return snr ? ((snr << e) & 0x7f) | ((142 - e) << 23) : 0;
> }
>
> /* For .1 decimal fixed point. NOTE: This will overflow the 32-bit
> * intermediate value if SNR is above 1638.3 dB! This is the no-float
> * version of:
> * float snr_to_float(u16 snr) { return snr / 10.0 } */
> u32 snr10_to_float(u16 snr)
> {
> unsigned int e = 23 - __fls(snr / 10);
> return snr ? snr << e) + 5) / 10) & 0x7f) | (150 - e) << 23 :
> 0;
> }
>
> You'd use the function like this:
>
> float f;
> *(u32 *)&f = snr_to_float(snr);
>
== rant mode on ==
Wow, I think we have lost our minds!
The argument being put forth is based on the relative efficiency of
the multiply versus divide opcodes on modern CPU architectures?? And
that you're going to be able to get an SNR with a higher level of
precision than 0.1 dB?? (if the hardware suggests that it can then
it's LYING to you)
If that is the extent of the compelling argument that can be made,
then so be it. But after reading this, I'm kind of dumbfounded that
this is the basis for proposing 8.8 format over just sending it back
in 0.1dB increments. We have officially entered the realm of
"ridiculous".
== rant mode off ==
Devin
--
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
--
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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Thu, 19 Mar 2009, Trent Piepho wrote:
> Since the driver often needs to use a logarithm from dvb-math to find SNR,
> you have code like this in the driver (from lgdt3305.c):
> /* report SNR in dB * 10 */
> *snr = (state->snr / ((1 << 24) / 10));
>
> > The SNR(dB) will be given by:
> > SNR(dB) = driver_SNR_measure / 256;
>
> For the driver side, also from lgdt3305 which has both formats with an
> ifdef:
> /* convert from 8.24 fixed-point to 8.8 */
> *snr = (state->snr) >> 16;
>
> FWIW, converting to decimal to print using only integer math:
>
> /* decimal fixed point */
> printf("%d.%d dB\n", snr / 10, snr % 10);
>
> /* binary fixed point */
> printf("%d.%02d dB\n", snr >> 8, (snr & 0xff) * 100 >> 8);
One more example, converting SNR into a 32-bit floating point number using
only integer operations. These don't do negative numbers but if the SNR
format used a sign bit it would be very easy to add, as IEEE 754 floating
point uses a sign bit too. I would need to think about it more to do 2's
complement.
For binary fixed point the conversion to a float is exact. For decimal
fixed point it's not. For example 334 (33.4 dB) will become 33.42 dB
when converted to floating point.
/* For 8.8 binary fixed point, this is the no-float version of:
* float snr_to_float(u16 snr) { return snr / 256.0 } */
u32 snr_to_float(u16 snr)
{
unsigned int e = 23 - __fls(snr);
return snr ? ((snr << e) & 0x7f) | ((142 - e) << 23) : 0;
}
/* For .1 decimal fixed point. NOTE: This will overflow the 32-bit
* intermediate value if SNR is above 1638.3 dB! This is the no-float
* version of:
* float snr_to_float(u16 snr) { return snr / 10.0 } */
u32 snr10_to_float(u16 snr)
{
unsigned int e = 23 - __fls(snr / 10);
return snr ? snr << e) + 5) / 10) & 0x7f) | (150 - e) << 23 : 0;
}
You'd use the function like this:
float f;
*(u32 *)&f = snr_to_float(snr);
--
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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote:
> that we should discuss about it for some time, comparing each alternatives we
> have, focused on SNR only. Later, use can use the same approach for the
> other quality measurements on DVB.
>
> In order to start such discussions, I'm summarizing both proposals under the
> same perspective.
>
> I'm also presenting some criteria that are important on this scope
>
> People are welcome to contribute and to argue in favor/against each one.
>
> So, on both proposals, we have 1 bit for signal and 15 bits to be used for
> storing the absolute numbering representation.
One could always use a normal 2's complement signed number to indicate
negative SNR. The only problem was the structure uses a u16 instead of an
s16.
> The SNR(dB) will be given by:
> SNR(dB) = driver_SNR_measure / 10;
Since the driver often needs to use a logarithm from dvb-math to find SNR,
you have code like this in the driver (from lgdt3305.c):
/* report SNR in dB * 10 */
*snr = (state->snr / ((1 << 24) / 10));
> The SNR(dB) will be given by:
> SNR(dB) = driver_SNR_measure / 256;
For the driver side, also from lgdt3305 which has both formats with an
ifdef:
/* convert from 8.24 fixed-point to 8.8 */
*snr = (state->snr) >> 16;
FWIW, converting to decimal to print using only integer math:
/* decimal fixed point */
printf("%d.%d dB\n", snr / 10, snr % 10);
/* binary fixed point */
printf("%d.%02d dB\n", snr >> 8, (snr & 0xff) * 100 >> 8);
On modern CPUs, integer division and modulus are by far the most
expensive operations, so the latter is probably faster since it replaces
two div/mod operations by a single integer multiply (cheaper than
division) and three much cheaper shifts or masks.
> Also, due to historical reasons, the frequency is represented as a 62.5 Hz
> step
> (or 62.5 kHz step, depending on a capability field), and this works fine: all
One could say the v4l1/2 use frequency in MHz in 28.4 binary fixed point.
--
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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, 13 Mar 2009 16:55:40 -0700 (PDT) Trent Piepho wrote: > On Fri, 13 Mar 2009, Devin Heitmueller wrote: > > On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho wrote: > > > I like 8.8 fixed point a lot better. It gives more precision. The range > > > is more in line with that the range of real SNRs are. Computers are > > > binary, so the math can end up faster. It's easier to read when printed > > > out in hex, since you can get the integer part of SNR just by looking at > > > the first byte. E.g., 25.3 would be 0x194C, 0x19 = 25 db, 0x4c = a little > > > more than quarter. Several drivers already use it. > > > > Wow, I know you said you like that idea alot better, but I read it and > > it made me feel sick to my stomach. Once we have a uniform format, we > > won't need to show it in hex at all. Tools like femon and scan can > > But if you do see it in hex, it's easier to understand. If it's not shown > in hex, you still have better precision and better math. What advantage is > there to using something that's 4.1 decimal fixed point on a binary > computer? It is most important to set a SNR scale (whatever it is) than to keep this decision up to each driver author. I'm sure we all agree with this. A common good practice in the community is to try to achieve a common sense on what's reasonable, when changing the API. However, sometimes this is not possible. So, if a consensus is not archived, the maintainer should take the hard decision of choosing one proposal in favor of another, after listening to arguments from both sides. I really believe that we can get a consensus in this case. So, I'm proposing that we should discuss about it for some time, comparing each alternatives we have, focused on SNR only. Later, use can use the same approach for the other quality measurements on DVB. In order to start such discussions, I'm summarizing both proposals under the same perspective. I'm also presenting some criteria that are important on this scope People are welcome to contribute and to argue in favor/against each one. Let's establish a timeframe for discussions up to Sunday, 29. It would be really great if we can go into a consensus until then. --- Being objective, we have right now 2 proposals, for using the 16 bit integer. I'll assume that we'll have one bit used by signal on either proposal, since negative SNR's can be measured as well. Yet, for the calculus bellow, I will consider only absolute numbers. So, on both proposals, we have 1 bit for signal and 15 bits to be used for storing the absolute numbering representation. Those are the proposals: 1) use a 0.1 dB in order to represent the SNR. This means that we'll range abs(SNR) from 0.0 dB to 3276.7 dB. The minimal measure step is 0.1 dB. Doing some calculus, the proposal is to use: use 3.3219 bits = log2(10) - for representing the 0.1 step fractional part; use 11.6781 bits for the decimal part (2^11.6781 ~= 3276). The SNR(dB) will be given by: SNR(dB) = driver_SNR_measure / 10; 2) The second proposal is to represent the 7-bits MSB as the integer part of the SNR, in dB, and the 8-bits LSB as the fractional part. Doing some calculus, to have the same set of values, for comparision: The minimum fractional number we can represent is 1/256 = 0.039dB. This means that we'll range abs(SNR) from 0.0 dB to 127.998 dB, with the minimal measure step is 0.039 dB. The SNR(dB) will be given by: SNR(dB) = driver_SNR_measure / 256; If I didn't make any mistake, this is what we have: ---+--++--+--+--- | Abs | Abs | Step | 16 bits usage| Formula for converting into dB |Min dB| Max dB | in dB| signal/int/fraction | ---+--++--+--+--- Proposal 1 | 0.0 | 3276.7 | 0.1 | 1 / 11.6781 / 3.3219 | SNR(dB) = driver_SNR_measure / 10 ---+--++--+--+--- Proposal 2 | 0.0 | 127.998| 0.039| 1 / 7 / 8 | SNR(dB) = driver_SNR_measure / 256 ---+--++--+--+--- In order to compare both proposals, we should establish some decision criteria. Those are the ones that seems to be relevant for such discussions, in order of relevance. 1) Max/min range analysis We should choose the number of bits for the decimal to be capable enough to represent the maximum absolute value for SNR, otherwise, we'll loose precision at the part that interests most. So, we should have enough bits to represent the maximum practical values for SNR. 2) Step analysis The minimal step size, the better precision we'll have. This will help to provide extra info for adjusting antenna, for example, or fine-tuning the frequency to the one that offers more quality. 3) Computational efforts and Math precision T
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Sun, Mar 15, 2009 at 9:20 AM, wk wrote: >> 1. Getting everyone to agree on a standard representation for the >> field, and how to represent certain error conditions (such as when a >> demod doesn't support SNR, or when it cannot return a valid value at a >> given time). >> >> > > Its just straightforward as described in DVB API, chapters > 2.2.3 FE READ STATUS > 2.2.4 FE READ BER > 2.2.5 FE READ SNR > 2.2.6 FE READ SIGNAL STRENGTH > 2.2.7 FE READ UNCORRECTED BLOCKS > > if ioctl suceeds with valid data: 0, if not one of > EBADF no valid fi le descriptor. > EFAULT error condition > ENOSIGNAL not yet, i have no signal.. > ENOSYS not supported by device. You're right, the error codes are indeed currently documented. I guess I just didn't realize that since I saw many different devices returning zero when the call was unimplemented, and returning garbage when there was no signal lock. In which case, the error codes don't need to be agreed on, they just need to be implemented across all the drivers. Of course, the bigger issue still remains to figure out what format the actual SNR should be in. >> 2. Converting all the drivers to the agreed-upon format. For some >> drivers this is relatively easy as we have specs available for how the >> SNR is represented. For others, the value displayed is entirely >> reverse engineered so the current representations are completely >> arbitrary. > > Since a lot of frontends have no proper docs, probably providing the signal > strength unit with a second ioctl could make sense here. > > a.u. arbitrary units, not exactly known or not perfectly working > dBµV comparable trough all devices, but probably not possible for all > percent technical not understandable, percent relative to what? Assumes > that there is a optimum/hard limit of 100% which is not the case. That was the very first suggestion I put out - to at least provide an ioctl indicating what unit the data was represented in, so applications would know how to show it (as opposed to trying to get every driver to unify it's return format). However, at the time the thinking was to at least get an inventory of all the different formats being used and how many drivers are impacted, and we can then assess how hard it would actually be to get them into a unified format. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller schrieb: On Fri, Mar 13, 2009 at 6:27 PM, VDR User wrote: Just wanted to comment that I'm glad there is a lot of interest in this. I've heard endless talk & confusion on the user end over the years as to the accuracy of the values, or in some cases (as with Genpix adapters for example) where you don't seem to get any useful information. Of course making it really hard for people who are trying to aim dishes and the like in the case of dvb-s*. A quick question about implimenting this though.. What's the most difficult component? Hello, There are basically two "difficult components" 1. Getting everyone to agree on a standard representation for the field, and how to represent certain error conditions (such as when a demod doesn't support SNR, or when it cannot return a valid value at a given time). Its just straightforward as described in DVB API, chapters 2.2.3 FE READ STATUS 2.2.4 FE READ BER 2.2.5 FE READ SNR 2.2.6 FE READ SIGNAL STRENGTH 2.2.7 FE READ UNCORRECTED BLOCKS if ioctl suceeds with valid data: 0, if not one of EBADFno valid file descriptor. EFAULT error condition ENOSIGNAL not yet, i have no signal.. ENOSYS not supported by device. 2. Converting all the drivers to the agreed-upon format. For some drivers this is relatively easy as we have specs available for how the SNR is represented. For others, the value displayed is entirely reverse engineered so the current representations are completely arbitrary. Devin Since a lot of frontends have no proper docs, probably providing the signal strength unit with a second ioctl could make sense here. a.u. arbitrary units, not exactly known or not perfectly working dBµV comparable trough all devices, but probably not possible for all percent technical not understandable, percent relative to what? Assumes that there is a optimum/hard limit of 100% which is not the case. Showing values as human readings is on the app side, so hex output in raw numbers are just fine here. No change needed. -- Winfried -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, 2009-03-13 at 18:34 -0700, Trent Piepho wrote: > On Fri, 13 Mar 2009, Andy Walls wrote: > > On Fri, 2009-03-13 at 10:27 -0400, Devin Heitmueller wrote: > > > On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wrote: > > > > > > > > Yes, please :) > > > > > > Yeah, Michael Krufky and I were discussing it in more detail yesterday > > > on the #linuxtv ML. Essentially there are a few issues: > > > > > > 1. Getting everyone to agree on the definition of "SNR", and what > > > units to represent it in. It seems like everybody I have talked to > > > has no issue with doing in 0.1 dB increments, so for example an SNR of > > > 25.3 would be presented as 0x00FD. > > > > +/- 0.1 dB indicates increases or decreases of about 2.3% which should > > be just fine as a step size. > > I've found that the extra precision helps when trying to align an antenna. > I turn the antenna a few degrees and then measure snr for a while. Then > make a plot of snr vs antenna rotation. With the extra precision you can > see the average snr change as you fine tune to rotation. Rounding off the > extra digit makes it harder to see. Ah good point. Peaking meters are nice. My antenna is in my attic and trusses limit rotations. :( > What is the advantage to using base 10 fixed point on binary computer? None really. From my work experience doing link budgets (i.e. predictions) going less than 0.1 dB is silly. But I wasn't thinking actual measurement. I agree, more prescision is good for measured quantities *and* acting on them. If the user isn't going to act on the measurments, then, of course, I'm not sure what good the extra precision is. Regards, Andy -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, 13 Mar 2009, Andy Walls wrote: > On Fri, 2009-03-13 at 10:27 -0400, Devin Heitmueller wrote: > > On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wrote: > > > > > > Yes, please :) > > > > Yeah, Michael Krufky and I were discussing it in more detail yesterday > > on the #linuxtv ML. Essentially there are a few issues: > > > > 1. Getting everyone to agree on the definition of "SNR", and what > > units to represent it in. It seems like everybody I have talked to > > has no issue with doing in 0.1 dB increments, so for example an SNR of > > 25.3 would be presented as 0x00FD. > > +/- 0.1 dB indicates increases or decreases of about 2.3% which should > be just fine as a step size. I've found that the extra precision helps when trying to align an antenna. I turn the antenna a few degrees and then measure snr for a while. Then make a plot of snr vs antenna rotation. With the extra precision you can see the average snr change as you fine tune to rotation. Rounding off the extra digit makes it harder to see. What is the advantage to using base 10 fixed point on binary computer? -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, 2009-03-13 at 10:27 -0400, Devin Heitmueller wrote: > On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wrote: > > > > Yes, please :) > > Yeah, Michael Krufky and I were discussing it in more detail yesterday > on the #linuxtv ML. Essentially there are a few issues: > > 1. Getting everyone to agree on the definition of "SNR", and what > units to represent it in. It seems like everybody I have talked to > has no issue with doing in 0.1 dB increments, so for example an SNR of > 25.3 would be presented as 0x00FD. +/- 0.1 dB indicates increases or decreases of about 2.3% which should be just fine as a step size. > 2. Getting everyone to agree on the definition of "Strength". Is > this the field strength? Field strength E is proportional to S^(1/2) and S is proportional to S/N, so E is proportional to (S/N)^(1/2). I wouldn't use field strength, there's really no additional information. > Is this some coefficient of the SNR compared > to an arbitrary scale? No. For digital signals what you really want is something that conveys *margin* not strength. For example: Margin = Received SNR - Threshold SNR (the above values in dB.) Where "Threshold SNR" is the required SNR for a certain block error rate with that modulation technique and FEC or a certain BER with that modulation technique. That lets the user know how close his signal is to crapping out - that's what a user cares about. (Or I suppose how far a user is from getting a useable signal in the case of negative margin.) The amount of AGC headroom you currently have can also be considered an amount of margin. That SNR margin combined with the receiver's current AGC headroom can give you composite a measure of "signal quality". One snag with this is if your AGC turns all the way down because you're overdriving the front end, then intermodulation products can degrade your SNR yet you have maximum AGC headroom, so one has to be careful about composite measures including AGC. > Is it a percentage? If it's a percentage, is > it 0-100 or 0-65535? Composite quality measures are likely best left as device specific. A device driver specific value scaled from 0 to 100 is fine, but likely still too granular. Where would the "not working threshold" be? 0, 25, 33, 50? Absolute measures (measures with no context) are typically useless, it's the realtive measures that usually have meaning. Regards, Andy > 3. Deciding on what return codes to use for "device does not support > SNR info", "device cannot provide SNR currently" (such as occurs for > some devices if there is no lock). Right now, devices return zero if > not supported, and it would be good for apps to know the difference > between "no signal" and the various reasons a chip cannot provide the > information. > > 4. Converting all the drivers to use the same representation. How > difficult this is varies by chip, since for some chips we know exactly > how SNR is represented and for some chips it is completely reverse > engineered. > > After the discussion I had yesterday, I have some renewed energy for > this. My plan is to put together a formal definition of the two API > calls (SNR and Strength) and solicit comments. If I get some > agreement, I will start converting all the ATSC devices to support the > API (and submit patches to Kaffeine). > > Devin -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, 13 Mar 2009, Devin Heitmueller wrote: > On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho wrote: > > I like 8.8 fixed point a lot better. ?It gives more precision. ?The range > > is more in line with that the range of real SNRs are. ?Computers are > > binary, so the math can end up faster. ?It's easier to read when printed > > out in hex, since you can get the integer part of SNR just by looking at > > the first byte. ?E.g., 25.3 would be 0x194C, 0x19 = 25 db, 0x4c = a little > > more than quarter. ?Several drivers already use it. > > Wow, I know you said you like that idea alot better, but I read it and > it made me feel sick to my stomach. Once we have a uniform format, we > won't need to show it in hex at all. Tools like femon and scan can But if you do see it in hex, it's easier to understand. If it's not shown in hex, you still have better precision and better math. What advantage is there to using something that's 4.1 decimal fixed point on a binary computer? > On a separate note, do you know specifically which drivers use that > format? I was putting together a table of all the various or51211, or51132, and lgdt330x at least. Don't know about the other lg demods. The dvb match code they all use makes it's easy to get the snr in 8.8 fixed point with the typical log caclulations required. -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, Mar 13, 2009 at 6:27 PM, VDR User wrote: > Just wanted to comment that I'm glad there is a lot of interest in > this. I've heard endless talk & confusion on the user end over the > years as to the accuracy of the values, or in some cases (as with > Genpix adapters for example) where you don't seem to get any useful > information. Of course making it really hard for people who are > trying to aim dishes and the like in the case of dvb-s*. > > A quick question about implimenting this though.. What's the most > difficult component? Hello, There are basically two "difficult components" 1. Getting everyone to agree on a standard representation for the field, and how to represent certain error conditions (such as when a demod doesn't support SNR, or when it cannot return a valid value at a given time). 2. Converting all the drivers to the agreed-upon format. For some drivers this is relatively easy as we have specs available for how the SNR is represented. For others, the value displayed is entirely reverse engineered so the current representations are completely arbitrary. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Just wanted to comment that I'm glad there is a lot of interest in this. I've heard endless talk & confusion on the user end over the years as to the accuracy of the values, or in some cases (as with Genpix adapters for example) where you don't seem to get any useful information. Of course making it really hard for people who are trying to aim dishes and the like in the case of dvb-s*. A quick question about implimenting this though.. What's the most difficult component? -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, Mar 13, 2009 at 5:32 PM, Devin Heitmueller wrote: > On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho wrote: >> I like 8.8 fixed point a lot better. It gives more precision. The range >> is more in line with that the range of real SNRs are. Computers are >> binary, so the math can end up faster. It's easier to read when printed >> out in hex, since you can get the integer part of SNR just by looking at >> the first byte. E.g., 25.3 would be 0x194C, 0x19 = 25 db, 0x4c = a little >> more than quarter. Several drivers already use it. > > Wow, I know you said you like that idea alot better, but I read it and > it made me feel sick to my stomach. Once we have a uniform format, we > won't need to show it in hex at all. Tools like femon and scan can > just show the value in decimal (they show it in hex because it's > definition varies by device). > > Target applications can reformat the value any way you prefer. This > is a kernel interface. > > On a separate note, do you know specifically which drivers use that > format? I was putting together a table of all the various > demodulators and which format they use, so if you have demods you know > about I would be interested in filling out that data. LGDT330X, for both the 3302 and 3303 (although the 3302 work was a guess -- its probably close enough) ...and both of the OREN demod drivers. -Mike -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho wrote: > I like 8.8 fixed point a lot better. It gives more precision. The range > is more in line with that the range of real SNRs are. Computers are > binary, so the math can end up faster. It's easier to read when printed > out in hex, since you can get the integer part of SNR just by looking at > the first byte. E.g., 25.3 would be 0x194C, 0x19 = 25 db, 0x4c = a little > more than quarter. Several drivers already use it. Wow, I know you said you like that idea alot better, but I read it and it made me feel sick to my stomach. Once we have a uniform format, we won't need to show it in hex at all. Tools like femon and scan can just show the value in decimal (they show it in hex because it's definition varies by device). Target applications can reformat the value any way you prefer. This is a kernel interface. On a separate note, do you know specifically which drivers use that format? I was putting together a table of all the various demodulators and which format they use, so if you have demods you know about I would be interested in filling out that data. >> 2. Getting everyone to agree on the definition of "Strength". Is >> this the field strength? Is this some coefficient of the SNR compared >> to an arbitrary scale? Is it a percentage? If it's a percentage, is >> it 0-100 or 0-65535? > > The problem with strength is that practically no hardware can measure true > signal strength. I'm fine being a little more flexible on the definition of "strength", as long as the resulting value is presented in a uniform format. While SNR should have a strict definition, I'm fine with having strength being something like "0-100%, scaled up to 0x". For drivers that only have SNR, they can just scale up the SNR based on a fixed maximum (some ATSC drivers for example, consider 35 dB to be 100%). Or drivers that have field strength measuring capabilities can return that value. In my mind, the goal isn't being able to compare different devices between each other, so much as being able to get a uniform way for users to know about what the signal quality is. I want users of Kaffeine to be able to go to the signal monitor section and see the "strength" indicator show a value from 0-100%, regardless of which device they are using. Certainly though, I want to get enough logic in there for devices to be able to indicate that the driver does not support returning the value (instead of returning zero), and be able to indicate that it cannot return the valid value right now (for example, many chips cannot return a valid value when there is no signal lock). Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, 13 Mar 2009, Devin Heitmueller wrote: > On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wrote: > > > > Yes, please :) > > Yeah, Michael Krufky and I were discussing it in more detail yesterday > on the #linuxtv ML. Essentially there are a few issues: > > 1. Getting everyone to agree on the definition of "SNR", and what > units to represent it in. It seems like everybody I have talked to > has no issue with doing in 0.1 dB increments, so for example an SNR of > 25.3 would be presented as 0x00FD. I like 8.8 fixed point a lot better. It gives more precision. The range is more in line with that the range of real SNRs are. Computers are binary, so the math can end up faster. It's easier to read when printed out in hex, since you can get the integer part of SNR just by looking at the first byte. E.g., 25.3 would be 0x194C, 0x19 = 25 db, 0x4c = a little more than quarter. Several drivers already use it. > 2. Getting everyone to agree on the definition of "Strength". Is > this the field strength? Is this some coefficient of the SNR compared > to an arbitrary scale? Is it a percentage? If it's a percentage, is > it 0-100 or 0-65535? The problem with strength is that practically no hardware can measure true signal strength. -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wrote: > > Yes, please :) Yeah, Michael Krufky and I were discussing it in more detail yesterday on the #linuxtv ML. Essentially there are a few issues: 1. Getting everyone to agree on the definition of "SNR", and what units to represent it in. It seems like everybody I have talked to has no issue with doing in 0.1 dB increments, so for example an SNR of 25.3 would be presented as 0x00FD. 2. Getting everyone to agree on the definition of "Strength". Is this the field strength? Is this some coefficient of the SNR compared to an arbitrary scale? Is it a percentage? If it's a percentage, is it 0-100 or 0-65535? 3. Deciding on what return codes to use for "device does not support SNR info", "device cannot provide SNR currently" (such as occurs for some devices if there is no lock). Right now, devices return zero if not supported, and it would be good for apps to know the difference between "no signal" and the various reasons a chip cannot provide the information. 4. Converting all the drivers to use the same representation. How difficult this is varies by chip, since for some chips we know exactly how SNR is represented and for some chips it is completely reverse engineered. After the discussion I had yesterday, I have some renewed energy for this. My plan is to put together a formal definition of the two API calls (SNR and Strength) and solicit comments. If I get some agreement, I will start converting all the ATSC devices to support the API (and submit patches to Kaffeine). Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
VDR User wrote: On Thu, Mar 12, 2009 at 6:53 PM, Ang Way Chuang wrote: Hi all, I've looked through the mailing list and there seems to be no standard way to interpret to content of SNR, signal strength and BER returned from the DVB API. So, I wonder if someone knows how to interpret these values at least for HVR 4000 Lite? Thanks. I've seen talk about converting everything to report SNR/STR in dB which is a great idea if it ever happens. I know a lot of guys not on the mailing list who've been waiting for that. Yes, please :) -- 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 -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Thu, Mar 12, 2009 at 6:53 PM, Ang Way Chuang wrote: > Hi all, > I've looked through the mailing list and there seems to be no > standard > way to interpret to content of SNR, signal strength and BER returned > from the DVB API. So, I wonder if someone knows how to interpret these > values at least for HVR 4000 Lite? Thanks. I've seen talk about converting everything to report SNR/STR in dB which is a great idea if it ever happens. I know a lot of guys not on the mailing list who've been waiting for that. -- 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
The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Hi all, I've looked through the mailing list and there seems to be no standard way to interpret to content of SNR, signal strength and BER returned from the DVB API. So, I wonder if someone knows how to interpret these values at least for HVR 4000 Lite? Thanks. Regards, Ang Way Chuang -- 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
