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. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
