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 abraham.m...@gmail.com 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
Devin Heitmueller wrote: On Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham abraham.m...@gmail.com wrote: Sure, of course. Here is an updated list based on the information that you accumulated. I have corrected some of them, which were not accurate. Before I comment any further on your email, could you please clarify what you mean by Relative, confirms to API. The current DVB API specification does not specify any units of measure for the content of the field, so I am not sure what you mean by this. Sorry about not responding earlier, wasn't feeling well at all and hence. By Relative, i meant dimensionless, but still it makes some sense based on some documented references. What i mean relative is that the API expects something like this. http://linuxtv.org/hg/dvb-apps/file/5fbdd3f898b1/util/szap/README Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to 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 7:46 PM, Manu Abraham abraham.m...@gmail.com wrote: Mika Laitio wrote: That said, the solution takes the approach of revolutionary as opposed to evolutionary, which always worries me. While providing a much more powerful interface, it also means all of the applications will have to properly support all of the various possible representations of the data, increasing the responsibility in userland considerably. Not necessarily, the application can simply chose to support what the driver provides as is, thereby doing no translations at all. From the end user point of view it is not very usefull if he has 2 different cards and application can not show any usefull signal goodness info in a way that would be easy to compare. So I think the attempt to standardize to db is good. The first part: For comparison having a standardized value is good. True. But the problem that surrounds it: To do this, a driver should support statistics in dB. For a device which doesn't show statistics in dB, for reasons (a) device uses a different format (b) enough information is not available to do a conversion (too less information, or a reverse engineered driver) (c) the conversion to be done makes things too complex in kernel land. So you have very less devices to do a comparison between. The other way to do this: Suppose, the driver that doesn't support a dB format (relative doesn't mean unknown) provides the information in a relative format. And the driver that provides the information in dB format, but that information you get, can be converted in to a relative floor - ceiling format (conversion handled by application, or by a library) This is a quick way. Now, which all devices do provide a scale in dB, which is really comparable ? There are many different parameters, quickly hacked together to be called SNR. In the terms you mention, you will be comparing things like SNR to CNR etc based on the device type. So eventually your comparison is wrong. Maybe there could then in addition be some other optional method for also getting data in some hw specific format in a way that Manu suggested. But there should anyway be mandatory to have this one standard goodness value in a way that does not require apps to make any complicate comparisons... (I bet half of those apps would be broken for years) In the way i mentioned, it leaves to the application to choose from different styles such as (1) display parameters from the drivers, in their own native format (This is a completely human readable format, in which you can see the real scales) (2) convert parameters to a specific format. (The very important part here is that the application is free to convert from format A with driver X and format B with driver Y, to get it into a unified format. if you really need the feature what you mentioned, you need this feature, rather than have all drivers being modified to provide one standard format) To make things look simple, i have a sample application which does (1) to make things look simple. If you choose to do (2) It will be just doing the conversion one time in a library or application, once rather than doing it multiple times in unknown ways and formats. Hello Manu, First off, a large part of your argument lies in the notion that many of the devices do not support representing the SNR in dB. However, when I sent around the list in an attempt to do an inventory of what formats were used by different demods, you didn't provide any actual information. Could you please look at the following list, and if you know of how unknown demods do their SNR, provide the information? http://www.devinheitmueller.com/snr.txt My argument for doing it in dB was based on the inventory suggesting that the vast majority of *known* devices do it that way. If this is incorrect, then how about providing some actual data so we have better decision making? I do agree that people should not be putting CNR data into the SNR field. If there are known cases where that happens, they should be removed. The CNR can be used to represent the strength field, but it is not the same as the SNR and shouldn't be treated as such. Also, things like putting AGC feedback in that field should be removed as well (or moved to the strength field). I haven't raised this argument yet, but I also believe that once we make this change, all the cases where the format for the SNR is unknown should be #ifdef 0 and return ENOSYS. If nobody can tell us what the format is, it's better to return nothing at all then mislead users with garbage data. Devin -- Devin 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 abraham.m...@gmail.com wrote: Mika Laitio wrote: That said, the solution takes the approach of revolutionary as opposed to evolutionary, which always worries me. While providing a much more powerful interface, it also means all of the applications will have to properly support all of the various possible representations of the data, increasing the responsibility in userland considerably. Not necessarily, the application can simply chose to support what the driver provides as is, thereby doing no translations at all. From the end user point of view it is not very usefull if he has 2 different cards and application can not show any usefull signal goodness info in a way that would be easy to compare. So I think the attempt to standardize to db is good. The first part: For comparison having a standardized value is good. True. But the problem that surrounds it: To do this, a driver should support statistics in dB. For a device which doesn't show statistics in dB, for reasons (a) device uses a different format (b) enough information is not available to do a conversion (too less information, or a reverse engineered driver) (c) the conversion to be done makes things too complex in kernel land. So you have very less devices to do a comparison between. The other way to do this: Suppose, the driver that doesn't support a dB format (relative doesn't mean unknown) provides the information in a relative format. And the driver that provides the information in dB format, but that information you get, can be converted in to a relative floor - ceiling format (conversion handled by application, or by a library) This is a quick way. Now, which all devices do provide a scale in dB, which is really comparable ? There are many different parameters, quickly hacked together to be called SNR. In the terms you mention, you will be comparing things like SNR to CNR etc based on the device type. So eventually your comparison is wrong. Maybe there could then in addition be some other optional method for also getting data in some hw specific format in a way that Manu suggested. But there should anyway be mandatory to have this one standard goodness value in a way that does not require apps to make any complicate comparisons... (I bet half of those apps would be broken for years) In the way i mentioned, it leaves to the application to choose from different styles such as (1) display parameters from the drivers, in their own native format (This is a completely human readable format, in which you can see the real scales) (2) convert parameters to a specific format. (The very important part here is that the application is free to convert from format A with driver X and format B with driver Y, to get it into a unified format. if you really need the feature what you mentioned, you need this feature, rather than have all drivers being modified to provide one standard format) To make things look simple, i have a sample application which does (1) to make things look simple. If you choose to do (2) It will be just doing the conversion one time in a library or application, once rather than doing it multiple times in unknown ways and formats. Hello Manu, Hi Devin, First off, a large part of your argument lies in the notion that many of the devices do not support representing the SNR in dB. My comment has some few points, of which the dB scale thing is just one among them. It could be a major aspect, depending on how you perceive it. However, when I sent around the list in an attempt to do an inventory of what formats were used by different demods, you didn't provide any actual information. Being on the lists for quite a while and following the developments with some amount of information, i was under the belief that it would have been obvious and did not give much importance to the same. Could you please look at the following list, and if you know of how unknown demods do their SNR, provide the information? http://www.devinheitmueller.com/snr.txt Sure, of course. Here is an updated list based on the information that you accumulated. I have corrected some of them, which were not accurate. af9013.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 always zero dst(s/c/t) (Inverted relative, if scaled confirms to API) dvb_dummy_fe.c always zero l64781.c(Relative, confirms to API) lgdt330x.c dB * 256 lgdt3304.c always
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 abraham.m...@gmail.com wrote: Sure, of course. Here is an updated list based on the information that you accumulated. I have corrected some of them, which were not accurate. Before I comment any further on your email, could you please clarify what you mean by Relative, confirms to API. The current DVB API specification does not specify any units of measure for the content of the field, so I am not sure what you mean by this. Thanks, Devin -- 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 Sun, Mar 22, 2009 at 9:00 PM, Devin Heitmueller devin.heitmuel...@gmail.com 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
Devin Heitmueller wrote:
On Sun, Mar 22, 2009 at 9:00 PM, Devin Heitmueller
devin.heitmuel...@gmail.com 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,
+ },
+
+ .error = {
+ .params =
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
On Tue, Mar 24, 2009 at 4:46 PM, Manu Abraham abraham.m...@gmail.com wrote: From the end user point of view it is not very usefull if he has 2 different cards and application can not show any usefull signal goodness info in a way that would be easy to compare. So I think the attempt to standardize to db is good. The first part: For comparison having a standardized value is good. True. But the problem that surrounds it: To do this, a driver should support statistics in dB. For a device which doesn't show statistics in dB, for reasons (a) device uses a different format (b) enough information is not available to do a conversion (too less information, or a reverse engineered driver) (c) the conversion to be done makes things too complex in kernel land. So you have very less devices to do a comparison between. Those are strong points you're making and more then enough reason to maintain the values in their native form and deal with it elsewhere. The other way to do this: Suppose, the driver that doesn't support a dB format (relative doesn't mean unknown) provides the information in a relative format. And the driver that provides the information in dB format, but that information you get, can be converted in to a relative floor - ceiling format (conversion handled by application, or by a library) This is a quick way. Now, which all devices do provide a scale in dB, which is really comparable ? There are many different parameters, quickly hacked together to be called SNR. In the terms you mention, you will be comparing things like SNR to CNR etc based on the device type. So eventually your comparison is wrong. Another good point. And a quick comment that I like the idea of a library. This takes the burden off the app while leaving options available instead of just forcing everything to dB whether it's compatible or not. Maybe there could then in addition be some other optional method for also getting data in some hw specific format in a way that Manu suggested. But there should anyway be mandatory to have this one standard goodness value in a way that does not require apps to make any complicate comparisons... (I bet half of those apps would be broken for years) In the way i mentioned, it leaves to the application to choose from different styles such as (1) display parameters from the drivers, in their own native format (This is a completely human readable format, in which you can see the real scales) (2) convert parameters to a specific format. (The very important part here is that the application is free to convert from format A with driver X and format B with driver Y, to get it into a unified format. if you really need the feature what you mentioned, you need this feature, rather than have all drivers being modified to provide one standard format) To make things look simple, i have a sample application which does (1) to make things look simple. If you choose to do (2) It will be just doing the conversion one time in a library or application, once rather than doing it multiple times in unknown ways and formats. Makes sense. One of my concerns was that this would just be slapped together and rushed like some other things were and finding out how bad of an idea that was after the fact. This doesn't need to take forever to reach a majority opinion, but it should have enough thought behind it to not cut people off at the knees. It sounds to me that preserving the native format is certainly a good idea for the numerous reasons that have been pointed out, and providing converting via library is the most sane approach. Trying to force a square into a circle never seems to work out very well. Best regards, Derek -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to 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
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_quality {
/* Unknown */
FE_QUALITY_UNKNOWN = 0,
/* SNR */
FE_QUALITY_SNR_dB_100,
FE_QUALITY_SNR_dB_10,
FE_QUALITY_SNR_dB,
/* CNR */
FE_QUALITY_CNR_dB_100,
FE_QUALITY_CNR_dB_10,
FE_QUALITY_CNR_dB,
/* Es/No */
FE_QUALITY_EsNo,
/* Eb/No */
FE_QUALITY_EbNo,
/* Relative */
FE_QUALITY_RELATIVE = 0x,
};
/* Strength
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 fecap_quality {
/* Unknown */
FE_QUALITY_UNKNOWN = 0,
/* SNR */
FE_QUALITY_SNR_dB_100,
FE_QUALITY_SNR_dB_10,
FE_QUALITY_SNR_dB,
/* CNR */
FE_QUALITY_CNR_dB_100,
FE_QUALITY_CNR_dB_10,
FE_QUALITY_CNR_dB,
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 xy...@speakeasy.org 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 choose whether it wants to display the statistics
in a specific way the
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 abraham.m...@gmail.com 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
On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho xy...@speakeasy.org 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 Thu, Mar 19, 2009 at 11:55 PM, Manu Abraham abraham.m...@gmail.com 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 Fri, 20 Mar 2009, Devin Heitmueller wrote: On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho xy...@speakeasy.org 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 Fri, 13 Mar 2009 16:55:40 -0700 (PDT) Trent Piepho xy...@speakeasy.org wrote: On Fri, 13 Mar 2009, Devin Heitmueller wrote: On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho xy...@speakeasy.org 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
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 xy...@speakeasy.org 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
Devin Heitmueller wrote:
On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho xy...@speakeasy.org 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 choose whether it wants to display the statistics
in a specific way the application would like
* Application can also choose what format the driver
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 user@gmail.com 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, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wc...@nav6.org 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
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 6:27 PM, VDR User user@gmail.com 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
On Fri, 13 Mar 2009, Devin Heitmueller wrote: On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho xy...@speakeasy.org 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, 2009-03-13 at 10:27 -0400, Devin Heitmueller wrote: On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wc...@nav6.org 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, 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 wc...@nav6.org 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 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 wc...@nav6.org 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
VDR User wrote: On Thu, Mar 12, 2009 at 6:53 PM, Ang Way Chuang wc...@nav6.org 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
