The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Ang Way Chuang]

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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[VDR User]

On Thu, Mar 12, 2009 at 6:53 PM, Ang Way Chuang <wcang@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.

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Ang Way Chuang]

VDR User wrote:
> On Thu, Mar 12, 2009 at 6:53 PM, Ang Way Chuang <wcang@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 majordomo@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]

On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang <wcang@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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Trent Piepho]

On Fri, 13 Mar 2009, Devin Heitmueller wrote:
> On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang <wcang@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.

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.

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Devin Heitmueller]

On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho <xyzzy@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
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 0xffff".  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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Michael Krufky]

On Fri, Mar 13, 2009 at 5:32 PM, Devin Heitmueller
<devin.heitmueller@gmail.com> wrote:
> On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho <xyzzy@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
> 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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[VDR User]

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?

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Devin Heitmueller]

On Fri, Mar 13, 2009 at 6:27 PM, VDR User <user.vdr@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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[wk]

Devin Heitmueller schrieb:
> On Fri, Mar 13, 2009 at 6:27 PM, VDR User <user.vdr@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
EBADF            no valid fi\x02le 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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Devin Heitmueller]

On Sun, Mar 15, 2009 at 9:20 AM, wk <handygewinnspiel@gmx.de> 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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Trent Piepho]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1351 bytes --]

On Fri, 13 Mar 2009, Devin Heitmueller wrote:
> On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho <xyzzy@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.

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Mauro Carvalho Chehab]

On Fri, 13 Mar 2009 16:55:40 -0700 (PDT)
Trent Piepho <xyzzy@speakeasy.org> wrote:

> On Fri, 13 Mar 2009, Devin Heitmueller wrote:
> > On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho <xyzzy@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 precision

The computer math representation inside the non-math CPU circuits on
almost all architectures assume that numbers are represented as fractions,
instead of decimal numbers. So, using a fixed number of bits to represent the
fractional part means faster calculus, and minimizes imprecision caused by
rounding the numbers.

4) Comparison with other APIs

It is a good idea to see what other API's are doing on such cases. 

In the case of the analog V4L2 API, control values like bright, contrast, etc
are represented as a fraction, where there's an ioctl to provide the value range
(max, min and step values).

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
userspace apps know how to handle, and this is not a problem at all. On all
places where this is used, the values are correctly and quickly converted.

Cheers,
Mauro

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Trent Piepho]

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.

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Trent Piepho]

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.400002 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) & 0x7fffff) | ((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) & 0x7fffff) | (150 - e) << 23 : 0;
}

You'd use the function like this:

	float f;
	*(u32 *)&f = snr_to_float(snr);

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Devin Heitmueller]

On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho <xyzzy@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.400002 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) & 0x7fffff) | ((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) & 0x7fffff) | (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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Trent Piepho]

On Thu, 19 Mar 2009, Devin Heitmueller wrote:
> On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho <xyzzy@speakeasy.org> 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.

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Devin Heitmueller]

On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho <xyzzy@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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Trent Piepho]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 3041 bytes --]

On Fri, 20 Mar 2009, Devin Heitmueller wrote:
> On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho <xyzzy@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.

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Manu Abraham]

Devin Heitmueller wrote:
> On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho <xyzzy@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.400002 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) & 0x7fffff) | ((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) & 0x7fffff) | (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 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		= 0xffffffff
};

/* 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 	= 0xffffffff,
};

/* Strength format
 * FE_STRENGTH_dB_100		:Strength in dB/100
 * FE_STRENGTH_dB_10		:Strength in dB/10
 * FE_STRENGTH_dB		:Strength in dB
 * FE_STRENGTH_dBmV_100		:Strength in dBmV/100
 * FE_STRENGTH_dBmV_10		:Strength in dBmV/10
 * FE_STRENGTH_dBmV		:Strength in dBmV
 * FE_STRENGTH_dBuV_100		:Strength in dBuV/100
 * FE_STRENGTH_dBuV_10		:Strength in dBuV/10
 * FE_STRENGTH_dBuV		:Strength in dBuV
 */
enum fecap_strength {
	FE_STRENGTH_UNKNOWN	= 0,
	FE_STRENGTH_dB_100,
	FE_STRENGTH_dB_10,
	FE_STRENGTH_dB,

	/* Relative */
	FE_STRENGTH_RELATIVE	= 0xffffffff,
};

/* Error Rate format
 * FE_ERROR_BER_ex (x = e-10 - 30)
 * FE_ERROR_PER_ex (x = e-10 - 30)
 */
enum fecap_errors {
	FE_ERROR_UNKNOWN	= 0,
	FE_ERROR_BER_e10,
	FE_ERROR_BER_e11,
	FE_ERROR_BER_e12,
	FE_ERROR_BER_e13,
	FE_ERROR_BER_e14,
	FE_ERROR_BER_e15,
	FE_ERROR_BER_e16,
	FE_ERROR_BER_e17,
	FE_ERROR_BER_e18,
	FE_ERROR_BER_e19,
	FE_ERROR_BER_e20,
	FE_ERROR_BER_e21,
	FE_ERROR_BER_e22,
	FE_ERROR_BER_e23,
	FE_ERROR_BER_e24,
	FE_ERROR_BER_e25,
	FE_ERROR_BER_e26,
	FE_ERROR_BER_e27,
	FE_ERROR_BER_e28,
	FE_ERROR_BER_e29,
	FE_ERROR_BER_e30,
	FE_ERROR_PER_e10,
	FE_ERROR_PER_e11,
	FE_ERROR_PER_e12,
	FE_ERROR_PER_e13,
	FE_ERROR_PER_e14,
	FE_ERROR_PER_e15,
	FE_ERROR_PER_e16,
	FE_ERROR_PER_e17,
	FE_ERROR_PER_e18,
	FE_ERROR_PER_e19,
	FE_ERROR_PER_e20,
	FE_ERROR_PER_e21,
	FE_ERROR_PER_e22,
	FE_ERROR_PER_e23,
	FE_ERROR_PER_e24,
	FE_ERROR_PER_e25,
	FE_ERROR_PER_e26,
	FE_ERROR_PER_e27,
	FE_ERROR_PER_e28,
	FE_ERROR_PER_e29,
	FE_ERROR_PER_e30,

	FE_ERROR_RELATIVE	= 0xffffffff,
};

struct fecap {
	/* current SNR */
	enum fecap_format	quality_format;
	enum fecap_quality	quality;

	/* current strength */
	enum fecap_format	strength_format;
	enum fecap_strength	strength;

	/* current BER */
	enum fecap_format	error_format;
	enum fecap_errors	error;
};

/* FE_STATISTICS_CAPS
 * Userspace query for frontend signal statistics capabilities
 * Application uses extracted data from existing "legacy" ioctls
 * in conjunction with capability definition to describe the
 * exact signal statistics.
 */
#define FE_STATISTICS_CAPS		_IOR('o', 84, struct fecap)


Regards,
Manu

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Manu Abraham]

Manu Abraham wrote:
> Devin Heitmueller wrote:
>> On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho <xyzzy@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.400002 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) & 0x7fffff) | ((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) & 0x7fffff) | (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 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		= 0xffffffff
> };
> 
> /* 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 	= 0xffffffff,
> };
> 
> /* Strength format
>  * FE_STRENGTH_dB_100		:Strength in dB/100
>  * FE_STRENGTH_dB_10		:Strength in dB/10
>  * FE_STRENGTH_dB		:Strength in dB
>  * FE_STRENGTH_dBmV_100		:Strength in dBmV/100
>  * FE_STRENGTH_dBmV_10		:Strength in dBmV/10
>  * FE_STRENGTH_dBmV		:Strength in dBmV
>  * FE_STRENGTH_dBuV_100		:Strength in dBuV/100
>  * FE_STRENGTH_dBuV_10		:Strength in dBuV/10
>  * FE_STRENGTH_dBuV		:Strength in dBuV
>  */
> enum fecap_strength {
> 	FE_STRENGTH_UNKNOWN	= 0,
> 	FE_STRENGTH_dB_100,
> 	FE_STRENGTH_dB_10,
> 	FE_STRENGTH_dB,
> 
> 	/* Relative */
> 	FE_STRENGTH_RELATIVE	= 0xffffffff,
> };
> 
> /* Error Rate format
>  * FE_ERROR_BER_ex (x = e-10 - 30)
>  * FE_ERROR_PER_ex (x = e-10 - 30)
>  */
> enum fecap_errors {
> 	FE_ERROR_UNKNOWN	= 0,
> 	FE_ERROR_BER_e10,
> 	FE_ERROR_BER_e11,
> 	FE_ERROR_BER_e12,
> 	FE_ERROR_BER_e13,
> 	FE_ERROR_BER_e14,
> 	FE_ERROR_BER_e15,
> 	FE_ERROR_BER_e16,
> 	FE_ERROR_BER_e17,
> 	FE_ERROR_BER_e18,
> 	FE_ERROR_BER_e19,
> 	FE_ERROR_BER_e20,
> 	FE_ERROR_BER_e21,
> 	FE_ERROR_BER_e22,
> 	FE_ERROR_BER_e23,
> 	FE_ERROR_BER_e24,
> 	FE_ERROR_BER_e25,
> 	FE_ERROR_BER_e26,
> 	FE_ERROR_BER_e27,
> 	FE_ERROR_BER_e28,
> 	FE_ERROR_BER_e29,
> 	FE_ERROR_BER_e30,
> 	FE_ERROR_PER_e10,
> 	FE_ERROR_PER_e11,
> 	FE_ERROR_PER_e12,
> 	FE_ERROR_PER_e13,
> 	FE_ERROR_PER_e14,
> 	FE_ERROR_PER_e15,
> 	FE_ERROR_PER_e16,
> 	FE_ERROR_PER_e17,
> 	FE_ERROR_PER_e18,
> 	FE_ERROR_PER_e19,
> 	FE_ERROR_PER_e20,
> 	FE_ERROR_PER_e21,
> 	FE_ERROR_PER_e22,
> 	FE_ERROR_PER_e23,
> 	FE_ERROR_PER_e24,
> 	FE_ERROR_PER_e25,
> 	FE_ERROR_PER_e26,
> 	FE_ERROR_PER_e27,
> 	FE_ERROR_PER_e28,
> 	FE_ERROR_PER_e29,
> 	FE_ERROR_PER_e30,
> 
> 	FE_ERROR_RELATIVE	= 0xffffffff,
> };
> 
> struct fecap {
> 	/* current SNR */
> 	enum fecap_format	quality_format;
> 	enum fecap_quality	quality;
> 
> 	/* current strength */
> 	enum fecap_format	strength_format;
> 	enum fecap_strength	strength;
> 
> 	/* current BER */
> 	enum fecap_format	error_format;
> 	enum fecap_errors	error;
> };
> 
> /* FE_STATISTICS_CAPS
>  * Userspace query for frontend signal statistics capabilities
>  * Application uses extracted data from existing "legacy" ioctls
>  * in conjunction with capability definition to describe the
>  * exact signal statistics.
>  */
> #define FE_STATISTICS_CAPS		_IOR('o', 84, struct fecap)

Ok, that will give a 1:1 representation of what the hardware can
provide to the user space and the application can do at will for
the relevant "necessary resolution".

Now, some more thoughts.
1) As someone mentioned in this thread, having a higher precision
for positioning an antenna.

This is not true. Why ?

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.

2) Currently we do get 1 parameter precisely. The rest do not make
sense. Why ?

When you request statistics, it needs to be at any given point of
time. Even if user space requests the parameters consecutively, it
won't have the nearest calls depending on the state of a system, the
calls might not be near in many cases.

So, one would be forced to think what is a good way to get
statistics for antenna positioning.


Here are some probable thoughts.

For positioning an antenna, generally a raw AGC value is employed
from the demodulator rather than SNR or Strength whatever, since the
SNR, Strength, xER are all valid only after the frontend has
acquired a LOCK. Useless parameters otherwise.

Other than that all the parameters needs to be snapshotted at any
given point of time, for fine tuning the position of the antenna,
once the frontend can LOCK, with a coarse position. This is how you
do it manually.

That said the implementation could look thus:

/* FE_SIGNAL_LEVEL
 * This system call provides a direct monitor of the signal, without
 * passing through the relevant processing chains. In many cases, it
 * is simply considered as direct AGC1 scaled values. This parameter
 * can generally be used to position an antenna to while looking at
 * a peak of this value. This parameter can be read back, even when
 * a frontend LOCK has not been achieved. Some microntroller based
 * demodulators do not provide a direct access to the AGC on the
 * demodulator, hence this parameter will be Unsupported for such
 * devices.
 */
#define FE_SIGNAL_LEVEL		_IOR('o', 85, u32 signal)

struct fesignal_stat {
        u32 quality;
	u32 strength;
	u32 error;
	u32 unc;
};

/* FE_SIGNAL_STATS
 * This system call provides a snapshot of all the receiver system

 * at any given point of time. System signal statistics are always
 * computed with respect to time and is best obtained the nearest
 * to each of the individual parameters in a time domain.
 * Signal statistics are assumed, "at any given instance of time".
 * It is not possible to get a snapshot at the exact single instance
 * and hence we look at the nearest instance, in the time domain.
 * The statistics are described by the FE_STATISTICS_CAPS ioctl,
 * ie. based on the device capabilities.
 */
#define FE_SIGNAL_STATS		_IOR('o', 86, struct fesignal_stat)


That would be more or less, what it would require to position an
antenna fairly well, without much knowledge.

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.

Regards,
Manu

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Devin Heitmueller]

On Fri, Mar 20, 2009 at 2:55 AM, Manu Abraham <abraham.manu@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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[VDR User]

On Thu, Mar 19, 2009 at 11:55 PM, Manu Abraham <abraham.manu@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.

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Roberto Ragusa]

VDR User wrote:
> On Thu, Mar 19, 2009 at 11:55 PM, Manu Abraham <abraham.manu@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. :-)
Hmmmm, feeds...

Best regards.
-- 
   Roberto Ragusa    mail at robertoragusa.it

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Andy Walls]

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		= 0xffffffff
> > };
> > 
> > /* 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 	= 0xffffffff,
> > };
> > 
> > /* Strength format
> >  * FE_STRENGTH_dB_100		:Strength in dB/100
> >  * FE_STRENGTH_dB_10		:Strength in dB/10
> >  * FE_STRENGTH_dB		:Strength in dB
> >  * FE_STRENGTH_dBmV_100		:Strength in dBmV/100
> >  * FE_STRENGTH_dBmV_10		:Strength in dBmV/10
> >  * FE_STRENGTH_dBmV		:Strength in dBmV
> >  * FE_STRENGTH_dBuV_100		:Strength in dBuV/100
> >  * FE_STRENGTH_dBuV_10		:Strength in dBuV/10
> >  * FE_STRENGTH_dBuV		:Strength in dBuV
> >  */
> > enum fecap_strength {
> > 	FE_STRENGTH_UNKNOWN	= 0,
> > 	FE_STRENGTH_dB_100,
> > 	FE_STRENGTH_dB_10,
> > 	FE_STRENGTH_dB,
> > 
> > 	/* Relative */
> > 	FE_STRENGTH_RELATIVE	= 0xffffffff,
> > };
> > 
> > /* Error Rate format
> >  * FE_ERROR_BER_ex (x = e-10 - 30)
> >  * FE_ERROR_PER_ex (x = e-10 - 30)
> >  */
> > enum fecap_errors {
> > 	FE_ERROR_UNKNOWN	= 0,
> > 	FE_ERROR_BER_e10,
> > 	FE_ERROR_BER_e11,
> > 	FE_ERROR_BER_e12,
> > 	FE_ERROR_BER_e13,
> > 	FE_ERROR_BER_e14,
> > 	FE_ERROR_BER_e15,
> > 	FE_ERROR_BER_e16,
> > 	FE_ERROR_BER_e17,
> > 	FE_ERROR_BER_e18,
> > 	FE_ERROR_BER_e19,
> > 	FE_ERROR_BER_e20,
> > 	FE_ERROR_BER_e21,
> > 	FE_ERROR_BER_e22,
> > 	FE_ERROR_BER_e23,
> > 	FE_ERROR_BER_e24,
> > 	FE_ERROR_BER_e25,
> > 	FE_ERROR_BER_e26,
> > 	FE_ERROR_BER_e27,
> > 	FE_ERROR_BER_e28,
> > 	FE_ERROR_BER_e29,
> > 	FE_ERROR_BER_e30,
> > 	FE_ERROR_PER_e10,
> > 	FE_ERROR_PER_e11,
> > 	FE_ERROR_PER_e12,
> > 	FE_ERROR_PER_e13,
> > 	FE_ERROR_PER_e14,
> > 	FE_ERROR_PER_e15,
> > 	FE_ERROR_PER_e16,
> > 	FE_ERROR_PER_e17,
> > 	FE_ERROR_PER_e18,
> > 	FE_ERROR_PER_e19,
> > 	FE_ERROR_PER_e20,
> > 	FE_ERROR_PER_e21,
> > 	FE_ERROR_PER_e22,
> > 	FE_ERROR_PER_e23,
> > 	FE_ERROR_PER_e24,
> > 	FE_ERROR_PER_e25,
> > 	FE_ERROR_PER_e26,
> > 	FE_ERROR_PER_e27,
> > 	FE_ERROR_PER_e28,
> > 	FE_ERROR_PER_e29,
> > 	FE_ERROR_PER_e30,
> > 
> > 	FE_ERROR_RELATIVE	= 0xffffffff,
> > };
> > 
> > struct fecap {
> > 	/* current SNR */
> > 	enum fecap_format	quality_format;
> > 	enum fecap_quality	quality;
> > 
> > 	/* current strength */
> > 	enum fecap_format	strength_format;
> > 	enum fecap_strength	strength;
> > 
> > 	/* current BER */
> > 	enum fecap_format	error_format;
> > 	enum fecap_errors	error;
> > };
> > 
> > /* FE_STATISTICS_CAPS
> >  * Userspace query for frontend signal statistics capabilities
> >  * Application uses extracted data from existing "legacy" ioctls
> >  * in conjunction with capability definition to describe the
> >  * exact signal statistics.
> >  */
> > #define FE_STATISTICS_CAPS		_IOR('o', 84, struct fecap)
> 
> Ok, that will give a 1:1 representation of what the hardware can
> provide to the user space and the application can do at will for
> the relevant "necessary resolution".
> 
> Now, some more thoughts.
> 1) As someone mentioned in this thread, having a higher precision
> for positioning an antenna.
> 
> This is not true. Why ?
> 
> 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.
> 
> 2) Currently we do get 1 parameter precisely. The rest do not make
> sense. Why ?
> 
> When you request statistics, it needs to be at any given point of
> time. Even if user space requests the parameters consecutively, it
> won't have the nearest calls depending on the state of a system, the
> calls might not be near in many cases.
> 
> So, one would be forced to think what is a good way to get
> statistics for antenna positioning.
> 
> 
> Here are some probable thoughts.
> 
> For positioning an antenna, generally a raw AGC value is employed
> from the demodulator rather than SNR or Strength whatever, since the
> SNR, Strength, xER are all valid only after the frontend has
> acquired a LOCK. Useless parameters otherwise.
> 
> Other than that all the parameters needs to be snapshotted at any
> given point of time, for fine tuning the position of the antenna,
> once the frontend can LOCK, with a coarse position. This is how you
> do it manually.
> 
> That said the implementation could look thus:
> 
> /* FE_SIGNAL_LEVEL
>  * This system call provides a direct monitor of the signal, without
>  * passing through the relevant processing chains. In many cases, it
>  * is simply considered as direct AGC1 scaled values. This parameter
>  * can generally be used to position an antenna to while looking at
>  * a peak of this value. This parameter can be read back, even when
>  * a frontend LOCK has not been achieved. Some microntroller based
>  * demodulators do not provide a direct access to the AGC on the
>  * demodulator, hence this parameter will be Unsupported for such
>  * devices.
>  */
> #define FE_SIGNAL_LEVEL		_IOR('o', 85, u32 signal)
> 
> struct fesignal_stat {
>         u32 quality;
> 	u32 strength;
> 	u32 error;
> 	u32 unc;
> };
> 
> /* FE_SIGNAL_STATS
>  * This system call provides a snapshot of all the receiver system
> 
>  * at any given point of time. System signal statistics are always
>  * computed with respect to time and is best obtained the nearest
>  * to each of the individual parameters in a time domain.
>  * Signal statistics are assumed, "at any given instance of time".
>  * It is not possible to get a snapshot at the exact single instance
>  * and hence we look at the nearest instance, in the time domain.
>  * The statistics are described by the FE_STATISTICS_CAPS ioctl,
>  * ie. based on the device capabilities.
>  */
> #define FE_SIGNAL_STATS		_IOR('o', 86, struct fesignal_stat)
> 
> 
> That would be more or less, what it would require to position an
> antenna fairly well, without much knowledge.

[snip]

> Regards,
> Manu



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_UNKOWN
	FE_QUALITY_SNR_dB,
	FE_QUALITY_CNR_dB,
	FE_QUALITY_EsNo,
	FE_QUALITY_EbNo,
	FE_QUALITY_RELATIVE,
};

Exponent is now separated out and sent as a signed integer value.
FE_QUALITY_UNKOWN isn't really needed (I think) as the "result" value in
the returned struct dtv_property can be set to -1 to indicate not
available.


I have *not* done an impact assessment on kernel internal interface
changes for the implementation form Manu presented, nor for the form I
have suggested here.  I'll leave that work to the guy who's thinking of
implementing something - *cough* Devin *cough*. :)

Regards,
Andy

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Manu Abraham]

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		= 0xffffffff
>>> };
>>>
>>> /* 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 	= 0xffffffff,
>>> };
>>>
>>> /* Strength format
>>>  * FE_STRENGTH_dB_100		:Strength in dB/100
>>>  * FE_STRENGTH_dB_10		:Strength in dB/10
>>>  * FE_STRENGTH_dB		:Strength in dB
>>>  * FE_STRENGTH_dBmV_100		:Strength in dBmV/100
>>>  * FE_STRENGTH_dBmV_10		:Strength in dBmV/10
>>>  * FE_STRENGTH_dBmV		:Strength in dBmV
>>>  * FE_STRENGTH_dBuV_100		:Strength in dBuV/100
>>>  * FE_STRENGTH_dBuV_10		:Strength in dBuV/10
>>>  * FE_STRENGTH_dBuV		:Strength in dBuV
>>>  */
>>> enum fecap_strength {
>>> 	FE_STRENGTH_UNKNOWN	= 0,
>>> 	FE_STRENGTH_dB_100,
>>> 	FE_STRENGTH_dB_10,
>>> 	FE_STRENGTH_dB,
>>>
>>> 	/* Relative */
>>> 	FE_STRENGTH_RELATIVE	= 0xffffffff,
>>> };
>>>
>>> /* Error Rate format
>>>  * FE_ERROR_BER_ex (x = e-10 - 30)
>>>  * FE_ERROR_PER_ex (x = e-10 - 30)
>>>  */
>>> enum fecap_errors {
>>> 	FE_ERROR_UNKNOWN	= 0,
>>> 	FE_ERROR_BER_e10,
>>> 	FE_ERROR_BER_e11,
>>> 	FE_ERROR_BER_e12,
>>> 	FE_ERROR_BER_e13,
>>> 	FE_ERROR_BER_e14,
>>> 	FE_ERROR_BER_e15,
>>> 	FE_ERROR_BER_e16,
>>> 	FE_ERROR_BER_e17,
>>> 	FE_ERROR_BER_e18,
>>> 	FE_ERROR_BER_e19,
>>> 	FE_ERROR_BER_e20,
>>> 	FE_ERROR_BER_e21,
>>> 	FE_ERROR_BER_e22,
>>> 	FE_ERROR_BER_e23,
>>> 	FE_ERROR_BER_e24,
>>> 	FE_ERROR_BER_e25,
>>> 	FE_ERROR_BER_e26,
>>> 	FE_ERROR_BER_e27,
>>> 	FE_ERROR_BER_e28,
>>> 	FE_ERROR_BER_e29,
>>> 	FE_ERROR_BER_e30,
>>> 	FE_ERROR_PER_e10,
>>> 	FE_ERROR_PER_e11,
>>> 	FE_ERROR_PER_e12,
>>> 	FE_ERROR_PER_e13,
>>> 	FE_ERROR_PER_e14,
>>> 	FE_ERROR_PER_e15,
>>> 	FE_ERROR_PER_e16,
>>> 	FE_ERROR_PER_e17,
>>> 	FE_ERROR_PER_e18,
>>> 	FE_ERROR_PER_e19,
>>> 	FE_ERROR_PER_e20,
>>> 	FE_ERROR_PER_e21,
>>> 	FE_ERROR_PER_e22,
>>> 	FE_ERROR_PER_e23,
>>> 	FE_ERROR_PER_e24,
>>> 	FE_ERROR_PER_e25,
>>> 	FE_ERROR_PER_e26,
>>> 	FE_ERROR_PER_e27,
>>> 	FE_ERROR_PER_e28,
>>> 	FE_ERROR_PER_e29,
>>> 	FE_ERROR_PER_e30,
>>>
>>> 	FE_ERROR_RELATIVE	= 0xffffffff,
>>> };
>>>
>>> struct fecap {
>>> 	/* current SNR */
>>> 	enum fecap_format	quality_format;
>>> 	enum fecap_quality	quality;
>>>
>>> 	/* current strength */
>>> 	enum fecap_format	strength_format;
>>> 	enum fecap_strength	strength;
>>>
>>> 	/* current BER */
>>> 	enum fecap_format	error_format;
>>> 	enum fecap_errors	error;
>>> };
>>>
>>> /* FE_STATISTICS_CAPS
>>>  * Userspace query for frontend signal statistics capabilities
>>>  * Application uses extracted data from existing "legacy" ioctls
>>>  * in conjunction with capability definition to describe the
>>>  * exact signal statistics.
>>>  */
>>> #define FE_STATISTICS_CAPS		_IOR('o', 84, struct fecap)
>> Ok, that will give a 1:1 representation of what the hardware can
>> provide to the user space and the application can do at will for
>> the relevant "necessary resolution".
>>
>> Now, some more thoughts.
>> 1) As someone mentioned in this thread, having a higher precision
>> for positioning an antenna.
>>
>> This is not true. Why ?
>>
>> 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.
>>
>> 2) Currently we do get 1 parameter precisely. The rest do not make
>> sense. Why ?
>>
>> When you request statistics, it needs to be at any given point of
>> time. Even if user space requests the parameters consecutively, it
>> won't have the nearest calls depending on the state of a system, the
>> calls might not be near in many cases.
>>
>> So, one would be forced to think what is a good way to get
>> statistics for antenna positioning.
>>
>>
>> Here are some probable thoughts.
>>
>> For positioning an antenna, generally a raw AGC value is employed
>> from the demodulator rather than SNR or Strength whatever, since the
>> SNR, Strength, xER are all valid only after the frontend has
>> acquired a LOCK. Useless parameters otherwise.
>>
>> Other than that all the parameters needs to be snapshotted at any
>> given point of time, for fine tuning the position of the antenna,
>> once the frontend can LOCK, with a coarse position. This is how you
>> do it manually.
>>
>> That said the implementation could look thus:
>>
>> /* FE_SIGNAL_LEVEL
>>  * This system call provides a direct monitor of the signal, without
>>  * passing through the relevant processing chains. In many cases, it
>>  * is simply considered as direct AGC1 scaled values. This parameter
>>  * can generally be used to position an antenna to while looking at
>>  * a peak of this value. This parameter can be read back, even when
>>  * a frontend LOCK has not been achieved. Some microntroller based
>>  * demodulators do not provide a direct access to the AGC on the
>>  * demodulator, hence this parameter will be Unsupported for such
>>  * devices.
>>  */
>> #define FE_SIGNAL_LEVEL		_IOR('o', 85, u32 signal)
>>
>> struct fesignal_stat {
>>         u32 quality;
>> 	u32 strength;
>> 	u32 error;
>> 	u32 unc;
>> };
>>
>> /* FE_SIGNAL_STATS
>>  * This system call provides a snapshot of all the receiver system
>>
>>  * at any given point of time. System signal statistics are always
>>  * computed with respect to time and is best obtained the nearest
>>  * to each of the individual parameters in a time domain.
>>  * Signal statistics are assumed, "at any given instance of time".
>>  * It is not possible to get a snapshot at the exact single instance
>>  * and hence we look at the nearest instance, in the time domain.
>>  * The statistics are described by the FE_STATISTICS_CAPS ioctl,
>>  * ie. based on the device capabilities.
>>  */
>> #define FE_SIGNAL_STATS		_IOR('o', 86, struct fesignal_stat)
>>
>>
>> That would be more or less, what it would require to position an
>> antenna fairly well, without much knowledge.
> 
> [snip]
> 
>> Regards,
>> Manu
> 
> 
> 
> 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.


An application can chose to remain with the least complexity, if
they don't try to re-interpret the format, but display it on a 1:1
scale that the driver provides.

It would be a "luxurious" application that's going to do format
translation. In such a case, the so called "complexity" in format
translation is "justified", which in other case you are going to
handle within the kernel driver. You need to handle the translation
some place, unless the application provides the information as is,
with no modifications.

In many cases this implementation is going to be broken, as it
brings a large unknown translation.

In any cases, it is not in the kernel that you should be doing
translations or protocol conversions. In many cases, one ends up in
having bad interpretations in doing such conversions in kernel.

It is of course much better to leave it to the application, that
conversion, to be handled in a generic way, "iff" it is necessary,
rather than forcing an application to have another broken
implementation for some devices.

Application authors are much smart at it, rather than to have dumb
hacks in the kernel drivers. Also it allows people to have their own
way that is thought to be better, giving rise to innovation and
flexibility, rather than forcing something broken down the throat of
 the users. Also it give the applications the freedom to implement a
certain feature as and when necessary.

> 
> 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.
> 


Believe me or not, not many users are going to be conversant with
this direct decibels approach and is going to cause much ridicule even.

In the "rigid approach", are you going to force an upward or a
downward scale to the user ? How many driver authors are well
conversant with such scaling ? And do the Linux driver authors who
spend free time on the drivers do understand all these concepts ?
Is it possible for even card manufacturers who provide drivers to
understand all these ?

Maybe "some" chip vendors are capable of stating that, that's what i
do believe in, since it requires to have and understanding what
happens within a certain chip.

In my experience, even a chip manufacturer has to dig a lot into
their internal resources to provide precise and consistent details
on such concepts on the how and why. Just forget about drivers from
"cut and pasted" sample code from the chip manufacturer.

So as i would term this, each and every person will have an idea of
his/her own, on such rigid approaches and hence such rigid
approaches are considered broken in most situations.

As an example: in a very professional use case, i do have a very
setup that uses one specific chip and my application is specific to
that family of chips. In such a case it makes sense for me to have
such a feature, which i think is useless for the home user, as it is
not a generic one and that which the home user is never going to face.

OTOH, as an example to calculate real Signal Strengths etc, you need
to calculate on the basis of the down-link margin, LNA/LNB/LNC noise
figure/gain, Dish size etc to get a real useful figure on this.

Information like this is never available to the kernel driver, but
is very much available to the user application as a whole, with even
more information available.

Real life applications do things like these, but when it comes to
the Linux community, due to the never ending discussions and the
politics leading to nowhere, such implementations never do see
light, even if an application author is capable to do all these.
He/She would be better off writing a closed source application and
selling it for $$$$$$ for those features, with a public patch to
whatever GPL'd headers as necessary, rather than wasting his/her
energy explaining things to people who are very unlikely to
understand even the basics. For the very same reason it lags beyond
very much in terms of hardware capabilities for decades.

That said, information like this always belong at the application
side, not the kernel driver. The kernel driver should simply do so
I/O, some normalization, and some basic calculations which are very
much extremely specific to that chip. If we were not to have such a
generic framework, it would be much still better to have a driver
which does only I/O operations in the kernel, such as a specific Bus
operation and let all those calculations be used in the user-space.

Just for information sake: there are even drivers that are better
implemented in user-space than in the kernel, due to the very same
reasons. That what looks different "today" might be a reality
"tomorrow" looking at industry trends.



That said, there are very specific useful use cases for what's being
discussed, but this is "definitely not" for the home user.

> 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.


It is delivery system dependent.

So, you don't need that "large" switch statement. The large
enumeration came from the bad design that was added on top of the v3
API, where everything was made to use a flat topology. You only need
to apply part of that enumeration into a switch which is delivery
dependent.

The drawbacks of the flat topology, have been seen in the form of
complaints from users and applications having a hard time to make
use of the driver in a sane way.


> 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.


3 new ioctl's is not a problem at all, that i must say. Just look at
all the redundant and useless code in dvb-core and useless
parameters in the API, without any thought or design. Anyone cares ?
Anyway, that's not the thing i want to point out.


> 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:


As Klaus pointed out earlier, in another thread, about delivery
system capabilities, this is definitely broken, for exactly the same
reason and for newer devices.

Any multi-standard device using this approach is definitely broken,
for the same reasons, the level of breakage will depend upon the
type of the device. For exactly the same reasons this ioctl
shouldn't be used in here.

I guess these days quite some people like to have broken devices for
others, than the hardware that they are likely to use (with a touch
of sarcasm).


> #define DTV_QUALITY_SIGNEDNESS 41
> #define DTV_QUALITY_WIDTH 42 (or DTV_QUALITY_SIGN_WIDTH with values like -32 meaning 32 bit signed)


Defining width as a whole sounds slightly more efficient, but
definitely it doesn't make much of a difference, as that enumeration
is 32 bits wide, You can either use it as a width variable directly,
even in that case. In fact even in the form right now it is exactly
that way. In any case the enumerations do provide better
documentation directly to the user than they guessing what it is. An
API should be understandable without reading too much.

Thinking again, maybe representing width just as a u32 bits
parameter is not bad either.

Instead of enum fecap_format, it could simply be u32 fecap_width.

> #define DTV_QUALITY_UNIT 43
> #define DTV_QUALITY_EXPONENT 44


This would be just ugly, for implementing within the driver, just
adding useless callbacks. These are basically static information and
do not need an additional callback, such as get_properties

The point here is to have little modifications to existing drivers.
Else you end up having more broken drivers as well, adding crap to
the way the DVB API/Core is screwed up by now.


> #define DTV_QUALITY_TOP_OF_SCALE 45
> #define DTV_QUALITY_BOTTOM_OF_SCALE 46


You wouldn't need this, as most of the drivers provides values
clamped to floor and ceiling. This is how DVB devices have generally
done till now.

But that said, maybe some devices could have provided
a broken implementation as well.

Floor and Ceiling wouldn't be necessary again, unless you loose
those already clamped information, which would mean that common code
is making things inefficient for other devices on the whole and it
really raises the question whether it makes sense to have common
code at all!

The point here, is to fix drivers that do not provide a floor and
ceiling, rather than to workaround them and break working ones to
the format of the broken ones.

> 
> #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_UNKOWN
> 	FE_QUALITY_SNR_dB,
> 	FE_QUALITY_CNR_dB,
> 	FE_QUALITY_EsNo,
> 	FE_QUALITY_EbNo,
> 	FE_QUALITY_RELATIVE,
> };
> 
> Exponent is now separated out and sent as a signed integer value.
> FE_QUALITY_UNKOWN isn't really needed (I think) as the "result" value in
> the returned struct dtv_property can be set to -1 to indicate not
> available.


It is indeed required. The question is not whether this is available
or not, but it is a question whether the unit is UNKNOWN. When it is
not implemented, it is supposed to return -ENOSYS or Unsupported as
described in the specification.

Regards,
Manu

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Devin Heitmueller]

On Sat, Mar 21, 2009 at 10:45 PM, Andy Walls <awalls@radix.net> 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_UNKOWN
>        FE_QUALITY_SNR_dB,
>        FE_QUALITY_CNR_dB,
>        FE_QUALITY_EsNo,
>        FE_QUALITY_EbNo,
>        FE_QUALITY_RELATIVE,
> };
>
> Exponent is now separated out and sent as a signed integer value.
> FE_QUALITY_UNKOWN isn't really needed (I think) as the "result" value in
> the returned struct dtv_property can be set to -1 to indicate not
> available.
>
>
> I have *not* done an impact assessment on kernel internal interface
> changes for the implementation form Manu presented, nor for the form I
> have suggested here.  I'll leave that work to the guy who's thinking of
> implementing something - *cough* Devin *cough*. :)
>
> Regards,
> Andy

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

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Devin Heitmueller]

On Sun, Mar 22, 2009 at 9:00 PM, Devin Heitmueller
<devin.heitmueller@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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Steven Toth]

>> 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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Andy Walls]

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
> 

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Manu Abraham]

[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

Devin Heitmueller wrote:
> On Sun, Mar 22, 2009 at 9:00 PM, Devin Heitmueller
> <devin.heitmueller@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

[-- Attachment #2: statistics.diff --]
[-- Type: text/x-patch, Size: 7024 bytes --]

diff -r 421de709288e linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c	Wed Mar 18 23:42:34 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c	Wed Mar 25 01:22:31 2009 +0400
 -1607,6 +1607,13 @@
 		break;
 	}

+	case FE_STATISTICS_CAPS: {
+		struct fecap_statistics *stats_cap = parg;
+		memcpy(stats_cap, &fe->ops.statistics_caps, sizeof (struct fecap_statistics));
+		err = 0;
+		break;
+	}
+
 	case FE_READ_STATUS: {
 		fe_status_t* status = parg;

 -1622,6 +1629,17 @@
 			err = fe->ops.read_status(fe, status);
 		break;
 	}
+
+	case FE_SIGNAL_LEVEL:
+		if (fe->ops.read_level)
+			err = fe->ops.read_level(fe, (__u32 *) parg);
+		break;
+
+	case FE_SIGNAL_STATS:
+		if (fe->ops.read_stats)
+			err = fe->ops.read_stats(fe, (struct fesignal_stat *) parg);
+		break;
+
 	case FE_READ_BER:
 		if (fe->ops.read_ber)
 			err = fe->ops.read_ber(fe, (__u32*) parg);
diff -r 421de709288e linux/drivers/media/dvb/dvb-core/dvb_frontend.h
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h	Wed Mar 18 23:42:34 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h	Wed Mar 25 01:22:31 2009 +0400
 -252,6 +252,7 @@
 struct dvb_frontend_ops {

 	struct dvb_frontend_info info;
+	struct fecap_statistics statistics_caps;

 	void (*release)(struct dvb_frontend* fe);
 	void (*release_sec)(struct dvb_frontend* fe);
 -298,6 +299,9 @@
 	 */
 	enum dvbfe_search (*search)(struct dvb_frontend *fe, struct dvb_frontend_parameters *p);
 	int (*track)(struct dvb_frontend *fe, struct dvb_frontend_parameters *p);
+
+	int (*read_level)(struct dvb_frontend *fe, u32 *signal); /* Raw AGC level */
+	int (*read_stats)(struct dvb_frontend *fe, struct fesignal_stat *stat);

 	struct dvb_tuner_ops tuner_ops;
 	struct analog_demod_ops analog_ops;
diff -r 421de709288e linux/drivers/media/dvb/frontends/stb0899_drv.c
--- a/linux/drivers/media/dvb/frontends/stb0899_drv.c	Wed Mar 18 23:42:34 2009 +0400
+++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c	Wed Mar 25 01:22:31 2009 +0400
 -1226,6 +1226,29 @@
 	return 0;
 }

+static int stb0899_read_level(struct dvb_frontend *fe, u32 *signal)
+{
+	/* TODO! */
+	return 0;
+}
+
+static int stb0899_read_stats(struct dvb_frontend *fe, struct fesignal_stat *stats)
+{
+	u16 snr, strength;
+	u32 ber;
+
+	stb0899_read_snr(fe, &snr);
+	stb0899_read_signal_strength(fe, &strength);
+	stb0899_read_ber(fe, &ber);
+
+	stats->quality = snr;
+	stats->strength = strength;
+	stats->error = ber;
+	stats->unc = 0;
+
+	return 0;
+}
+
 static int stb0899_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
 {
 	struct stb0899_state *state = fe->demodulator_priv;
 -1917,6 +1940,27 @@
 					  FE_CAN_QPSK
 	},

+	.statistics_caps = {
+		.quality = {
+			.params		= FE_QUALITY_CNR,
+			.scale		= FE_SCALE_dB,
+			.exponent	= -4,
+		},
+
+		.strength = {
+			.params		= FE_SCALE_dB,
+			.exponent	= -4,
+		},
+
+		.error = {
+			.params		= FE_ERROR_BER,
+			.exponent	= 7,
+		},
+
+		.unc = FE_UNC_UNKNOWN,
+
+	},
+
 	.release			= stb0899_release,
 	.init				= stb0899_init,
 	.sleep				= stb0899_sleep,
 -1934,6 +1978,9 @@
 	.read_snr			= stb0899_read_snr,
 	.read_signal_strength		= stb0899_read_signal_strength,
 	.read_ber			= stb0899_read_ber,
+
+	.read_level			= stb0899_read_level,
+	.read_stats			= stb0899_read_stats,

 	.set_voltage			= stb0899_set_voltage,
 	.set_tone			= stb0899_set_tone,
diff -r 421de709288e linux/include/linux/dvb/frontend.h
--- a/linux/include/linux/dvb/frontend.h	Wed Mar 18 23:42:34 2009 +0400
+++ b/linux/include/linux/dvb/frontend.h	Wed Mar 25 01:22:31 2009 +0400
 -413,4 +413,120 @@

 #define FE_DISHNETWORK_SEND_LEGACY_CMD _IO('o', 80) /* unsigned int */

+
+/* Frontend General Statistics
+ * General parameters
+ * FE_*_UNKNOWN:
+ *	Parameter is unknown to the frontend and doesn't really
+ *	make any sense for an application.
+ *
+ * FE_*_RELATIVE:
+ *	Parameter is relative on the basis of a ceil - floor basis
+ *	Format is based on empirical test to determine
+ *	the floor and ceiling values. This format is exactly the
+ *	same format as the existing statistics implementation.
+ */
+enum fecap_quality_params {
+	FE_QUALITY_UNKNOWN		= 0,
+	FE_QUALITY_SNR			= (1 <<  0),
+	FE_QUALITY_CNR			= (1 <<  1),
+	FE_QUALITY_EsNo			= (1 <<  2),
+	FE_QUALITY_EbNo			= (1 <<  3),
+	FE_QUALITY_RELATIVE		= (1 << 31),
+};
+
+enum fecap_scale_params {
+	FE_SCALE_UNKNOWN		= 0,
+	FE_SCALE_dB			= (1 <<  0),
+	FE_SCALE_RELATIVE		= (1 << 31),
+};
+
+enum fecap_error_params {
+	FE_ERROR_UNKNOWN		= 0,
+	FE_ERROR_BER			= (1 <<  0),
+	FE_ERROR_PER			= (1 <<  1),
+	FE_ERROR_RELATIVE		= (1 << 31),
+};
+
+enum fecap_unc_params {
+	FE_UNC_UNKNOWN			= 0,
+	FE_UNC_RELATIVE			= (1 << 31),
+};
+
+/* General parameters
+ * width:
+ * 	Specifies the width of the field
+ *
+ * exponent:
+ *	Specifies the multiplier for the respective field
+ *	MSB:1bit indicates the signdness of the parameter
+ */
+struct fecap_quality {
+	enum fecap_quality_params	params;
+	enum fecap_scale_params		scale;
+
+	__u32				width;
+	__s32				exponent;
+};
+
+struct fecap_strength {
+	enum fecap_scale_params		params;
+	__u32				width;
+	__s32				exponent;
+};
+
+struct fecap_error {
+	enum fecap_error_params		params;
+	__u32 				width;
+	__s32 				exponent;
+};
+
+struct fecap_statistics {
+	struct fecap_quality		quality;
+	struct fecap_strength		strength;
+	struct fecap_error		error;
+	enum fecap_unc_params		unc;
+};
+
+/* FE_STATISTICS_CAPS
+ * Userspace query for frontend signal statistics capabilities
+ */
+#define FE_STATISTICS_CAPS		_IOR('o', 84, struct fecap_statistics)
+
+
+/* FE_SIGNAL_LEVEL
+ * This system call provides a direct monitor of the signal, without
+ * passing through the relevant processing chains. In many cases, it
+ * is simply considered as direct AGC1 scaled values. This parameter
+ * can generally be used to position an antenna to while looking at
+ * a peak of this value. This parameter can be read back, even when
+ * a frontend LOCK has not been achieved. Some microntroller based
+ * demodulators do not provide a direct access to the AGC on the
+ * demodulator, hence this parameter will be Unsupported for such
+ * devices.
+ */
+#define FE_SIGNAL_LEVEL			_IOR('o', 85, __u32)
+
+
+struct fesignal_stat {
+	__u32 quality;
+	__u32 strength;
+	__u32 error;
+	__u32 unc;
+};
+
+/* FE_SIGNAL_STATS
+ * This system call provides a snapshot of all the receiver system
+ * at any given point of time. System signal statistics are always
+ * computed with respect to time and is best obtained the nearest
+ * to each of the individual parameters in a time domain.
+ * Signal statistics are assumed, "at any given instance of time".
+ * It is not possible to get a snapshot at the exact single instance
+ * and hence we look at the nearest instance, in the time domain.
+ * The statistics are described by the FE_STATISTICS_CAPS ioctl,
+ * ie. based on the device capabilities.
+ */
+#define FE_SIGNAL_STATS			_IOR('o', 86, struct fesignal_stat)
+
+
 #endif /*_DVBFRONTEND_H_*/

[-- Attachment #3: femon-ng.c --]
[-- Type: text/x-csrc, Size: 10924 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdint.h>

#include <sys/param.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/poll.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>

#include <string.h>

#include "frontend.h"

enum fetype {
	FETYPE_DVBS,
	FETYPE_DVBC,
	FETYPE_DVBT,
	FETYPE_ATSC,
};

struct fehandle {
	int fd;
	enum fetype type;
	char *name;
};

#define MAX_LEN	256

enum feinfo_mask {
	FEINFO_LOCKSTATUS		= 0x001,
	FEINFO_FEPARAMS			= 0x002,
	FEINFO_BER			= 0x004,
	FEINFO_SIGNAL_STRENGTH		= 0x008,
	FEINFO_SNR			= 0x010,
	FEINFO_UNCORRECTED_BLOCKS	= 0x020,
	FEINFO_SIGNAL_LEVEL		= 0x040,
	FEINFO_STATISTICS_CAPS		= 0x080,
	FEINFO_STATISTICS		= 0x100,
};


enum dvbfe_spectral_inversion {
	DVBFE_INVERSION_OFF,
	DVBFE_INVERSION_ON,
	DVBFE_INVERSION_AUTO
};

enum dvbfe_code_rate {
	DVBFE_FEC_NONE,
	DVBFE_FEC_1_2,
	DVBFE_FEC_2_3,
	DVBFE_FEC_3_4,
	DVBFE_FEC_4_5,
	DVBFE_FEC_5_6,
	DVBFE_FEC_6_7,
	DVBFE_FEC_7_8,
	DVBFE_FEC_8_9,
	DVBFE_FEC_AUTO
};

enum dvbfe_dvbt_const {
	DVBFE_DVBT_CONST_QPSK,
	DVBFE_DVBT_CONST_QAM_16,
	DVBFE_DVBT_CONST_QAM_32,
	DVBFE_DVBT_CONST_QAM_64,
	DVBFE_DVBT_CONST_QAM_128,
	DVBFE_DVBT_CONST_QAM_256,
	DVBFE_DVBT_CONST_AUTO
};

enum dvbfe_dvbc_mod {
	DVBFE_DVBC_MOD_QAM_16,
	DVBFE_DVBC_MOD_QAM_32,
	DVBFE_DVBC_MOD_QAM_64,
	DVBFE_DVBC_MOD_QAM_128,
	DVBFE_DVBC_MOD_QAM_256,
	DVBFE_DVBC_MOD_AUTO,
};

enum dvbfe_atsc_mod {
	DVBFE_ATSC_MOD_QAM_64,
	DVBFE_ATSC_MOD_QAM_256,
	DVBFE_ATSC_MOD_VSB_8,
	DVBFE_ATSC_MOD_VSB_16,
	DVBFE_ATSC_MOD_AUTO
};

enum dvbfe_dvbt_transmit_mode {
	DVBFE_DVBT_TRANSMISSION_MODE_2K,
	DVBFE_DVBT_TRANSMISSION_MODE_8K,
	DVBFE_DVBT_TRANSMISSION_MODE_AUTO
};

enum dvbfe_dvbt_bandwidth {
	DVBFE_DVBT_BANDWIDTH_8_MHZ,
	DVBFE_DVBT_BANDWIDTH_7_MHZ,
	DVBFE_DVBT_BANDWIDTH_6_MHZ,
	DVBFE_DVBT_BANDWIDTH_AUTO
};

enum dvbfe_dvbt_guard_interval {
	DVBFE_DVBT_GUARD_INTERVAL_1_32,
	DVBFE_DVBT_GUARD_INTERVAL_1_16,
	DVBFE_DVBT_GUARD_INTERVAL_1_8,
	DVBFE_DVBT_GUARD_INTERVAL_1_4,
	DVBFE_DVBT_GUARD_INTERVAL_AUTO
};

enum dvbfe_dvbt_hierarchy {
	DVBFE_DVBT_HIERARCHY_NONE,
	DVBFE_DVBT_HIERARCHY_1,
	DVBFE_DVBT_HIERARCHY_2,
	DVBFE_DVBT_HIERARCHY_4,
	DVBFE_DVBT_HIERARCHY_AUTO
};

struct dvbfe_parameters {
	uint32_t frequency;
	enum dvbfe_spectral_inversion inversion;
	union {
		struct {
			uint32_t			symbol_rate;
			enum dvbfe_code_rate		fec_inner;
		} dvbs;

		struct {
			uint32_t			symbol_rate;
			enum dvbfe_code_rate		fec_inner;
			enum dvbfe_dvbc_mod		modulation;
		} dvbc;

		struct {
			enum dvbfe_dvbt_bandwidth	bandwidth;
			enum dvbfe_code_rate		code_rate_HP;
			enum dvbfe_code_rate		code_rate_LP;
			enum dvbfe_dvbt_const		constellation;
			enum dvbfe_dvbt_transmit_mode	transmission_mode;
			enum dvbfe_dvbt_guard_interval	guard_interval;
			enum dvbfe_dvbt_hierarchy	hierarchy_information;
		} dvbt;

		struct {
			enum dvbfe_atsc_mod		modulation;
		} atsc;
	} u;
};

struct dvbfe_info {
	enum fetype type;			/* always retrieved */
	const char *name;			/* always retrieved */
	unsigned int signal     : 1;		/* } DVBFE_INFO_LOCKSTATUS */
	unsigned int carrier    : 1;		/* } */
	unsigned int viterbi    : 1;		/* } */
	unsigned int sync       : 1;		/* } */
	unsigned int lock       : 1;		/* } */

	/* old */
	struct dvbfe_parameters feparams;	/* DVBFE_INFO_FEPARAMS */
	uint32_t ber;				/* DVBFE_INFO_BER */
	uint16_t signal_strength;		/* DVBFE_INFO_SIGNAL_STRENGTH */
	uint16_t snr;				/* DVBFE_INFO_SNR */
	uint32_t ucblocks;			/* DVBFE_INFO_UNCORRECTED_BLOCKS */

	/* extended */
	uint32_t level;				/* FEINFO_SIGNAL_LEVEL */
						/* FEINFO_STATISTICS_CAPS */
	float quality;				/* FEINFO_STATISTICS */
	float strength;
	float error;
	uint32_t unc;

	enum fecap_quality_params	qparams;
	enum fecap_scale_params		qscale;
	enum fecap_scale_params		sscale;
	enum fecap_error_params		eparams;

	/* Exponents */
	int32_t qexp;
	int32_t sexp;
	int32_t eexp;
};

static char *usage_str =
    "\nusage: femon-ng [options]\n"
    "     -a number : use given adapter (default 0)\n"
    "     -f number : use given frontend (default 0)\n"
    "     -c number : samples to take (default 0 = infinite)\n\n";

static void usage(void)
{
	fprintf(stderr, usage_str);
	exit(1);
}

static int dvbfe_get_info(struct fehandle *handle,
			  enum feinfo_mask mask,
			  struct dvbfe_info *result,
			  int timeout)
{
	int returnval = 0;
	struct dvb_frontend_event event;
	struct fecap_statistics caps;
	struct fesignal_stat stats;

	uint32_t signal;

	result->name = handle->name;
	result->type = handle->type;

	/* Signal level without LOCK */
	if (mask & FEINFO_SIGNAL_LEVEL) {
		if (!ioctl(handle->fd, FE_SIGNAL_LEVEL, &signal))
			return -1;

		result->level = signal;
	}

	/* Frontend Signal statistics capability */
	if (mask & FEINFO_STATISTICS_CAPS) {
		if (!ioctl(handle->fd, FE_STATISTICS_CAPS, &caps))
			return -1;

		result->qparams = caps.quality.params;
		result->qscale = caps.quality.scale;
		result->qexp = caps.quality.exponent;
		result->sscale = caps.strength.params;
		result->sexp = caps.strength.exponent;
		result->eparams = caps.error.params;
		result->eexp = caps.error.exponent;
	}

	/* Useful signal statistics after LOCK */
	if (mask & FEINFO_STATISTICS) {
		if (!ioctl(handle->fd, FE_SIGNAL_STATS, &stats))
			return -1;

		result->quality		= stats.quality;
		result->strength	= stats.strength;
		result->error		= stats.error;
		result->unc		= stats.unc;
	}

	if (mask & FEINFO_LOCKSTATUS) {
		if (!ioctl(handle->fd, FE_READ_STATUS, &event.status))
			return -1;

		result->signal		= event.status & FE_HAS_SIGNAL ? 1 : 0;
		result->carrier		= event.status & FE_HAS_CARRIER ? 1 : 0;
		result->viterbi		= event.status & FE_HAS_VITERBI ? 1 : 0;
		result->viterbi		= event.status & FE_HAS_LOCK ? 1 : 0;
	}

	if (mask & FEINFO_FEPARAMS) {
		if (!ioctl(handle->fd, FE_GET_FRONTEND, &event.parameters))
			return -1;

		result->feparams.frequency = event.parameters.frequency;
		result->feparams.inversion = event.parameters.inversion;

		switch (handle->type) {
		case FE_QPSK:
			result->feparams.u.dvbs.symbol_rate = event.parameters.u.qpsk.symbol_rate;
			result->feparams.u.dvbs.fec_inner = event.parameters.u.qpsk.fec_inner;
			break;

		case FE_QAM:
			result->feparams.u.dvbc.symbol_rate = event.parameters.u.qpsk.symbol_rate;
			result->feparams.u.dvbc.fec_inner = event.parameters.u.qam.fec_inner;
			result->feparams.u.dvbc.modulation = event.parameters.u.qam.modulation;
			break;

		case FE_OFDM:
			result->feparams.u.dvbt.bandwidth = event.parameters.u.ofdm.bandwidth;
			result->feparams.u.dvbt.code_rate_HP = event.parameters.u.ofdm.code_rate_HP;
			result->feparams.u.dvbt.code_rate_LP = event.parameters.u.ofdm.code_rate_LP;
			result->feparams.u.dvbt.constellation = event.parameters.u.ofdm.constellation;
			result->feparams.u.dvbt.transmission_mode = event.parameters.u.ofdm.transmission_mode;
			result->feparams.u.dvbt.guard_interval = event.parameters.u.ofdm.guard_interval;
			result->feparams.u.dvbt.hierarchy_information = event.parameters.u.ofdm.hierarchy_information;
			break;

		case FE_ATSC:
			result->feparams.u.atsc.modulation = event.parameters.u.vsb.modulation;
			break;
		}

	}

	if (mask & FEINFO_BER) {
		if (!ioctl(handle->fd, FE_READ_BER, &result->ber))
			return-1;
	}

	if (mask & FEINFO_SIGNAL_STRENGTH) {
		if (!ioctl(handle->fd, FE_READ_SIGNAL_STRENGTH, &result->signal_strength))
			return -1;
	}

	if (mask & FEINFO_SNR) {
		if (!ioctl(handle->fd, FE_READ_SNR, &result->snr))
			return -1;
	}

	if (mask & FEINFO_UNCORRECTED_BLOCKS) {
		if (!ioctl(handle->fd, FE_READ_UNCORRECTED_BLOCKS, &result->ucblocks))
			return -1;
	}

	return 0;
}


static int check_frontend(struct fehandle *handle, unsigned int count)
{
	struct dvbfe_info fe_info;
	unsigned int samples = 0;

	char *qparams_txt[]	= {"?", "SNR", "CNR", "Es/No", "Eb/No", "REL"};
	char *qscale_txt[]	= {"?", "dB", "%"};
	char *strength_txt[]	= {"?", "dB", "%"};
	char *error_txt[]	= {"?", "BER", "PER"};

	if (dvbfe_get_info(handle, FEINFO_STATISTICS_CAPS, &fe_info, 0)) {
		fprintf(stderr, "Extended signal operation not supported\n");
		return -1;
	}

	do {
		if (dvbfe_get_info(handle, FEINFO_STATISTICS, &fe_info, 0)) {
			fprintf(stderr, "Error retrieving statistics\n");
			return -1;
		}

		printf("Quality %d (%s) %s ^%d | Strength %d (%s) ^%d | Errors %d %s e^%d | UNC %d | FE_HAS_LOCK",
		       fe_info.quality,
		       qparams_txt[fe_info.qparams],
		       qscale_txt[fe_info.qscale],
		       fe_info.qexp,
		       fe_info.strength,
		       strength_txt[fe_info.sscale],
		       fe_info.sexp,
		       fe_info.error,
		       error_txt[fe_info.eparams],
		       fe_info.unc,
		       fe_info.eexp);

		fflush(stdout);
		usleep(1000000);
		samples++;
	} while ((!count) || (count - samples));

	return 0;
}

struct fehandle *fe_open(int adapter, int frontend, int readonly)
{
	char filename[MAX_LEN + 1];
	struct fehandle *handle;
	int fd;
	struct dvb_frontend_info info;

	/* flags */
	int flags = O_RDWR;
	if (readonly)
		flags = O_RDONLY;

	/* open */
	sprintf(filename, "/dev/dvb/adapter%i/frontend%i", adapter, frontend);
	if ((fd = open(filename, flags)) < 0)
			return NULL;

	/* determine frontend type */
	if (ioctl(fd, FE_GET_INFO, &info)) {
		close(fd);
		return NULL;
	}

	handle = (struct fehandle *) malloc(sizeof (struct fehandle));
	memset(handle, 0, sizeof (struct fehandle));
	handle->fd = fd;

	switch(info.type) {
	case FE_QPSK:
		handle->type = FETYPE_DVBS;
		break;

	case FE_QAM:
		handle->type = FETYPE_DVBC;
		break;

	case FE_OFDM:
		handle->type = FETYPE_DVBT;
		break;

	case FE_ATSC:
		handle->type = FETYPE_ATSC;
		break;
	}

	handle->name = strndup(info.name, sizeof (info.name));
	return handle;
}

void fe_close(struct fehandle *handle)
{
	close(handle->fd);
	free(handle->name);
	free(handle);
}

static int monitor(unsigned int adapter,
		   unsigned int frontend,
		   unsigned int count)
{
	int result;

	struct fehandle *handle;
	struct dvbfe_info fe_info;
	char *fe_type = "UNKNOWN";

	handle = fe_open(adapter, frontend, 1);
	if (handle == NULL) {
		perror("opening frontend failed");
		return 0;
	}

	dvbfe_get_info(handle, 0, &fe_info, 0);

	switch(fe_info.type) {
	case FETYPE_DVBS:
		fe_type = "DVBS";
		break;
	case FETYPE_DVBC:
		fe_type = "DVBC";
		break;
	case FETYPE_DVBT:
		fe_type = "DVBT";
		break;
	case FETYPE_ATSC:
		fe_type = "ATSC";
		break;
	}
	printf("FE: %s (%s)\n", fe_info.name, fe_type);
	result = check_frontend(handle, count);
	fe_close(handle);

	return result;
}

int main(int argc, char *argv[])
{
	unsigned int adapter = 0, frontend = 0, count = 0;
	int opt;

	while ((opt = getopt(argc, argv, "a:f:c")) != -1) {
		switch (opt) {
		default:
			usage();
			break;
		case 'a':
			adapter = strtoul(optarg, NULL, 0);
			break;
		case 'f':
			frontend = strtoul(optarg, NULL, 0);
			break;
		case 'c':
			count = strtoul(optarg, NULL, 0);
			break;
		}
	}

	monitor(adapter, frontend, count);

	return 0;
}

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Mika Laitio]

>>> 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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Manu Abraham]

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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[VDR User]

On Tue, Mar 24, 2009 at 4:46 PM, Manu Abraham <abraham.manu@gmail.com> wrote:
>>> From the end user point of view it is not very usefull if he has 2
>> different cards and application can not show any usefull signal goodness
>> info in a way that would be easy to compare. So I think the attempt to
>> standardize to db is good.
>
> The first part: For comparison having a standardized value is good.
>
> True.
>
> But the problem that surrounds it:
>
> To do this, a driver should support statistics in dB. For a device
> which doesn't show statistics in dB, for reasons
> (a) device uses a different format
>
> (b) enough information is not available to do a conversion
>    (too less information, or a reverse engineered driver)
>
> (c) the conversion to be done makes things too complex in kernel land.
>
> So you have very less devices to do a comparison between.

Those are strong points you're making and more then enough reason to
maintain the values in their native form and deal with it elsewhere.

> The other way to do this:
>
> Suppose, the driver that doesn't support a dB format (relative
> doesn't mean unknown) provides the information in a relative format.
> And the driver that provides the information in dB format, but that
> information you get, can be converted in to a relative floor -
> ceiling format (conversion handled by application, or by a library)
>
> This is a quick way.
>
> Now, which all devices do provide a scale in dB, which is really
> comparable ? There are many different parameters, quickly hacked
> together to be called SNR. In the terms you mention, you will be
> comparing things like
>
> SNR to CNR etc based on the device type.
>
> So eventually your comparison is wrong.

Another good point.  And a quick comment that I like the idea of a
library.  This takes the burden off the app while leaving options
available instead of just forcing everything to dB whether it's
compatible or not.

>> Maybe there could then in addition be some other optional method for
>> also getting data in some hw specific format in a way that Manu suggested.
>> But there should anyway be mandatory to have this one "standard goodness
>> value" in a way that does not require apps to make any complicate
>> comparisons... (I bet half of those apps would be broken for years)
>
> In the way i mentioned, it leaves to the application to choose from
> different styles such as
>
> (1) display parameters from the drivers, in their own native format
> (This is a completely human readable format, in which you can see
> the real scales)
>
> (2) convert parameters to a specific format.
> (The very important part here is that the application is free to
> convert from format A with driver X and  format B with driver Y, to
> get it into a unified format. if you really need the feature what
> you mentioned, you need this feature, rather than have all drivers
> being modified to provide one standard format)
>
> To make things look simple, i have a sample application which does
> (1) to make things look simple.
>
> If you choose to do (2) It will be just doing the conversion one
> time in a library or application, once rather than doing it multiple
> times in unknown ways and formats.

Makes sense.  One of my concerns was that this would just be slapped
together and rushed like some other things were and finding out how
bad of an idea that was after the fact.  This doesn't need to take
forever to reach a majority opinion, but it should have enough thought
behind it to not cut people off at the knees.

It sounds to me that preserving the native format is certainly a good
idea for the numerous reasons that have been pointed out, and
providing converting via library is the most sane approach.  Trying to
force a square into a circle never seems to work out very well.

Best regards,
Derek

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Devin Heitmueller]

On Tue, Mar 24, 2009 at 7:46 PM, Manu Abraham <abraham.manu@gmail.com> wrote:
> Mika Laitio wrote:
>>>>> That said, the solution takes the approach of "revolutionary" as
>>>>> opposed to "evolutionary", which always worries me.  While providing a
>>>>> much more powerful interface, it also means all of the applications
>>>>> will have to properly support all of the various possible
>>>>> representations of the data, increasing the responsibility in userland
>>>>> considerably.
>>>
>>> Not necessarily, the application can simply chose to support what
>>> the driver provides as is, thereby doing no translations at all.
>>
>>> From the end user point of view it is not very usefull if he has 2
>> different cards and application can not show any usefull signal goodness
>> info in a way that would be easy to compare. So I think the attempt to
>> standardize to db is good.
>
> The first part: For comparison having a standardized value is good.
>
> True.
>
> But the problem that surrounds it:
>
> To do this, a driver should support statistics in dB. For a device
> which doesn't show statistics in dB, for reasons
> (a) device uses a different format
>
> (b) enough information is not available to do a conversion
>    (too less information, or a reverse engineered driver)
>
> (c) the conversion to be done makes things too complex in kernel land.
>
> So you have very less devices to do a comparison between.
>
> The other way to do this:
>
> Suppose, the driver that doesn't support a dB format (relative
> doesn't mean unknown) provides the information in a relative format.
> And the driver that provides the information in dB format, but that
> information you get, can be converted in to a relative floor -
> ceiling format (conversion handled by application, or by a library)
>
> This is a quick way.
>
> Now, which all devices do provide a scale in dB, which is really
> comparable ? There are many different parameters, quickly hacked
> together to be called SNR. In the terms you mention, you will be
> comparing things like
>
> SNR to CNR etc based on the device type.
>
> So eventually your comparison is wrong.
>
>
>> Maybe there could then in addition be some other optional method for
>> also getting data in some hw specific format in a way that Manu suggested.
>> But there should anyway be mandatory to have this one "standard goodness
>> value" in a way that does not require apps to make any complicate
>> comparisons... (I bet half of those apps would be broken for years)
>
>
> In the way i mentioned, it leaves to the application to choose from
> different styles such as
>
> (1) display parameters from the drivers, in their own native format
> (This is a completely human readable format, in which you can see
> the real scales)
>
> (2) convert parameters to a specific format.
> (The very important part here is that the application is free to
> convert from format A with driver X and  format B with driver Y, to
> get it into a unified format. if you really need the feature what
> you mentioned, you need this feature, rather than have all drivers
> being modified to provide one standard format)
>
> To make things look simple, i have a sample application which does
> (1) to make things look simple.
>
> If you choose to do (2) It will be just doing the conversion one
> time in a library or application, once rather than doing it multiple
> times in unknown ways and formats.

Hello Manu,

First off, a large part of your argument lies in the notion that many
of the devices do not support representing the SNR in dB.  However,
when I sent around the list in an attempt to do an inventory of what
formats were used by different demods, you didn't provide any actual
information.  Could you please look at the following list, and if you
know of how "unknown" demods do their SNR, provide the information?

http://www.devinheitmueller.com/snr.txt

My argument for doing it in dB was based on the inventory suggesting
that the vast majority of *known* devices do it that way.  If this is
incorrect, then how about providing some actual data so we have better
decision making?

I do agree that people should not be putting CNR data into the SNR
field.  If there are known cases where that happens, they should be
removed.  The CNR can be used to represent the "strength" field, but
it is not the same as the SNR and shouldn't be treated as such.  Also,
things like putting AGC feedback in that field should be removed as
well (or moved to the strength field).

I haven't raised this argument yet, but I also believe that once we
make this change, all the cases where the format for the SNR is
"unknown" should be "#ifdef 0" and return ENOSYS.  If nobody can tell
us what the format is, it's better to return nothing at all then
mislead users with garbage data.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Manu Abraham]

Devin Heitmueller wrote:
> On Tue, Mar 24, 2009 at 7:46 PM, Manu Abraham <abraham.manu@gmail.com> wrote:
>> Mika Laitio wrote:
>>>>>> That said, the solution takes the approach of "revolutionary" as
>>>>>> opposed to "evolutionary", which always worries me.  While providing a
>>>>>> much more powerful interface, it also means all of the applications
>>>>>> will have to properly support all of the various possible
>>>>>> representations of the data, increasing the responsibility in userland
>>>>>> considerably.
>>>> Not necessarily, the application can simply chose to support what
>>>> the driver provides as is, thereby doing no translations at all.
>>>> From the end user point of view it is not very usefull if he has 2
>>> different cards and application can not show any usefull signal goodness
>>> info in a way that would be easy to compare. So I think the attempt to
>>> standardize to db is good.
>> The first part: For comparison having a standardized value is good.
>>
>> True.
>>
>> But the problem that surrounds it:
>>
>> To do this, a driver should support statistics in dB. For a device
>> which doesn't show statistics in dB, for reasons
>> (a) device uses a different format
>>
>> (b) enough information is not available to do a conversion
>>    (too less information, or a reverse engineered driver)
>>
>> (c) the conversion to be done makes things too complex in kernel land.
>>
>> So you have very less devices to do a comparison between.
>>
>> The other way to do this:
>>
>> Suppose, the driver that doesn't support a dB format (relative
>> doesn't mean unknown) provides the information in a relative format.
>> And the driver that provides the information in dB format, but that
>> information you get, can be converted in to a relative floor -
>> ceiling format (conversion handled by application, or by a library)
>>
>> This is a quick way.
>>
>> Now, which all devices do provide a scale in dB, which is really
>> comparable ? There are many different parameters, quickly hacked
>> together to be called SNR. In the terms you mention, you will be
>> comparing things like
>>
>> SNR to CNR etc based on the device type.
>>
>> So eventually your comparison is wrong.
>>
>>
>>> Maybe there could then in addition be some other optional method for
>>> also getting data in some hw specific format in a way that Manu suggested.
>>> But there should anyway be mandatory to have this one "standard goodness
>>> value" in a way that does not require apps to make any complicate
>>> comparisons... (I bet half of those apps would be broken for years)
>>
>> In the way i mentioned, it leaves to the application to choose from
>> different styles such as
>>
>> (1) display parameters from the drivers, in their own native format
>> (This is a completely human readable format, in which you can see
>> the real scales)
>>
>> (2) convert parameters to a specific format.
>> (The very important part here is that the application is free to
>> convert from format A with driver X and  format B with driver Y, to
>> get it into a unified format. if you really need the feature what
>> you mentioned, you need this feature, rather than have all drivers
>> being modified to provide one standard format)
>>
>> To make things look simple, i have a sample application which does
>> (1) to make things look simple.
>>
>> If you choose to do (2) It will be just doing the conversion one
>> time in a library or application, once rather than doing it multiple
>> times in unknown ways and formats.
> 
> Hello Manu,
> 


Hi Devin,

> First off, a large part of your argument lies in the notion that many
> of the devices do not support representing the SNR in dB.


My comment has some few points, of which the dB scale thing is just
one among them. It could be a major aspect, depending on how you
perceive it.

> However,
> when I sent around the list in an attempt to do an inventory of what
> formats were used by different demods, you didn't provide any actual
> information.


Being on the lists for quite a while and following the developments
with some amount of information, i was under the belief that it
would have been obvious and did not give much importance to the same.

> Could you please look at the following list, and if you
> know of how "unknown" demods do their SNR, provide the information?
> 
> http://www.devinheitmueller.com/snr.txt


Sure, of course. Here is an updated list based on the information
that you accumulated. I have corrected some of them, which were not
accurate.


af9013.c	0.1 dB
at76c651.c      unknown
au8522.c        0.1 dB
bcm3510.c       unknown (vals > 1000)
cinergyT2.c	dB * 256
cx22700.c       unknown
cx22702.c       unknown
cx24110.c       ESN0
cx24116.c       percent scaled to 0-0xffff, support for ESN0
cx24123.c       Inverted ESN0
dib3000mb.c     unknown
dib3000mc.c     always zero (0.1dB possible [pboettch])
dib7000m.c      always zero (0.1dB possible [pboettch])
dib7000p.c      always zero (0.1dB possible [pboettch])
drx397xD.c      always zero
dst(s/c/t)	(Inverted relative, if scaled confirms to API)
dvb_dummy_fe.c  always zero
l64781.c        (Relative, confirms to API)
lgdt330x.c      dB * 256
lgdt3304.c	always zero
lgdt3305.c      0.1 dB
lgs8gl5.c       unknown
mt312.c         (Relative, confirms to API3.3)
mt352.c         (Relative, confirms to API) (0.1dB possible in hardware)
nxt200x.c       approximated to dB (uC provides some 4 - 5 steps)
nxt6000.c       unknown
or51132.c       dB * 256
or51211.c       dB * 256
s5h1409.c	0.1 dB
s5h1411.c       0.1 dB
s5h1420.c       unsupported
si21xx.c        CNR Relative (scaled to 0-0xffff)
sp8870.c        unsupported
sp887x.c        unknown
stv0299		(Relative, confirms to API)
stv0288.c       (Relative, confirms to API)
stv0297.c       (Relative, confirms to API, floor/ceiling undefined)
stv0299.c       unknown
tda10021.c      (Relative, confirms to API)
tda10023.c      (Relative, confirms to API)
tda10048.c      0.1 dB
tda1004x.c      (Relative, confirms to API)
tda10086.c      (Relative, confirms to API)
tda8083.c       (Relative, confirms to API, floor ceiling undefined)
tda80xx.c       unknown
ves1820.c       unknown
ves1x93.c       unknown
zl10353.c       (Relative, confirms to API) (0.1dB possible in hardware)
stb0899_drv.c	CNR, Es/No
mb86a16		CNR (approximated)


> My argument for doing it in dB was based on the inventory suggesting
> that the vast majority of *known* devices do it that way.  If this is
> incorrect, then how about providing some actual data so we have better
> decision making?


Sure.


> I do agree that people should not be putting CNR data into the SNR
> field.  If there are known cases where that happens, they should be
> removed.

Hmm.. (scratching head and pulls out a few hairs)...


> The CNR can be used to represent the "strength" field, but
> it is not the same as the SNR and shouldn't be treated as such.


A bit of signal theory, here:

The Carrier in this case is the modulated signal. In some cases it
can be an IQ modulated signal, or in another case it could be a QPSK
demodulation.


Eventually, Carrier is "the Signal", at a certain stage in the whole
pipeline.

In fact, CNR (aka Carrier to Noise Ratio) is very similar to SNR
(Signal to Noise Ratio) except that CNR is obtained just before
demodulation stage and that is the only one difference between them.

Both are Signal ratios with respect to Noise, SNR is proportional
and smaller compared to CNR for the same reasons, that the "actual
Signal" might be much "smaller" in comparison to the carrier, which
is used for modulation.

In such a case you can't use CNR to represent strength, but in fact
can be used to used to represent SNR in some proportional way.

http://en.wikipedia.org/wiki/Signal-to-noise_ratio
http://en.wikipedia.org/wiki/Carrier_to_Noise_Ratio


> Also,
> things like putting AGC feedback in that field should be removed as
> well (or moved to the strength field).
> 
> I haven't raised this argument yet, but I also believe that once we
> make this change, all the cases where the format for the SNR is
> "unknown" should be "#ifdef 0" and return ENOSYS.  If nobody can tell
> us what the format is, it's better to return nothing at all then
> mislead users with garbage data.


Though it looks like a purist's approach, this would just remove
whatever feature that a driver is having currently. If you can't add
features into a driver, it's not a big deal. But it is not really a
cool thing to remove a feature which is even partially working to
some extent: a way in which it is documented a considered working to
many users. Just telling users that what statistics what they have
been seeing are going to be removed, just because it is not a dB
scale might not sound really attractive or useful.


In fact most of the drivers use that parameter scaled to what the
API currently state. Some recent drivers have been using different
formats than what the API described and hence the whole confusion.

As i mentioned earlier, the API doesn't export units for these
parameters for teh same mentioned reasons, that there are much
different units and things to be considered which would make things
too complex for a driver author and hence it has such a definition.

Regards,
Manu

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Devin Heitmueller]

On Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham <abraham.manu@gmail.com> wrote:
> Sure, of course. Here is an updated list based on the information
> that you accumulated. I have corrected some of them, which were not
> accurate.

Before I comment any further on your email, could you please clarify
what you mean by "Relative, confirms to API".  The current DVB API
specification does not specify any units of measure for the content of
the field, so I am not sure what you mean by this.

Thanks,

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Devin Heitmueller]

On Wed, Mar 25, 2009 at 6:27 PM, Devin Heitmueller
<devin.heitmueller@gmail.com> wrote:
> Before I comment any further on your email, could you please clarify
> what you mean by "Relative, confirms to API".  The current DVB API
> specification does not specify any units of measure for the content of
> the field, so I am not sure what you mean by this.

<ping>

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Manu Abraham]

Devin Heitmueller wrote:
> On Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham <abraham.manu@gmail.com> wrote:
>> Sure, of course. Here is an updated list based on the information
>> that you accumulated. I have corrected some of them, which were not
>> accurate.
> 
> Before I comment any further on your email, could you please clarify
> what you mean by "Relative, confirms to API".  The current DVB API
> specification does not specify any units of measure for the content of
> the field, so I am not sure what you mean by this.

Sorry about not responding earlier, wasn't feeling well at all and
hence.

By Relative, i meant dimensionless, but still it makes some sense
based on some documented references.

What i mean "relative" is that the API expects something like this.
http://linuxtv.org/hg/dvb-apps/file/5fbdd3f898b1/util/szap/README

Regards,
Manu

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Manu Abraham]

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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Andy Walls]

On Fri, 2009-03-13 at 10:27 -0400, Devin Heitmueller wrote:
> On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang <wcang@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

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Trent Piepho]

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 <wcang@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?

Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[Andy Walls]

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 <wcang@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