[linux-dvb] [Proposal] Meaningful reporting of SNR

Trent Piepho xyzzy at speakeasy.org
Thu Apr 13 03:22:26 CEST 2006


On Tue, 11 Apr 2006, Rusty Scott wrote:
> It seems that a good number of digital receiver chips are capable of reporting a
> meaningful SNR number, but the current drivers don't have a standard for
> providing this meaningful data.  The current concept is a bigger value is
> better than a smaller value, but the values have no meaning and can't be used

I'd like to see this too.  The unitless bigger is better values used by some
APIs always seemed like a cop-out to me, to avoid having to worry about
details.  Datasheets usually have formulas to turn register values into real
numbers.  You could have SNR in dB, analog video sampling rate in MHz, hue
shift in degrees, and so on, instead of just some vague notion of more or
less.

Here's some suggestions I have:

Computers are binary, so don't scale by powers of 10, scale by powers of 2.
Instead returning decibels times 10^2, use decibels times 2^8.  You can use a
common fixed-point format like 8.8 or 16.16.  You end up getting more
precision with simpler operations this way.

The number of fractional bits is _maximum_ precision you can get, not the
minimum needed.  Don't want to bother with a lookup table for 1/256th of dB?
Just use a smaller one for 1/2 dB and then:  snr<<=7; and you've got 8 the
fractional bits.  Sure, maybe 4 bits is enough, but what do you gain from that
limit?

There's no advantage to using 16 bit values unless you have an array of them.
A single 16-bit value takes just as much space as a 32-bit one in a register
or on the stack, but needs larger and slower instructions to work with.

Adding a new ioctl for each parameter and unit you want to provide gets
limiting and cumbersome.  I suggest having a system where you can query the
driver for list of supported values, and it provides a table of descriptors
with what it can do.  Somewhat like the descriptors in MPEG PSIP data.  You
could have a "units" field where one could specify codes for "dB in 16.16
fixed-point", or "unitless signed 16-bit value", or whatever.

I wish I had a datasheet for an ATSC demodulator so I knew more about what
there was, but there must be more information besides SNR.  If you don't need
to add new ioctls it's a lot easier for someone with an interest and a
datasheet to take advantage of things like measures of multi-path interference
or frequency drift.



More information about the linux-dvb mailing list