On Wednesday 12 April 2006 08:22 pm, Trent Piepho wrote: > 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 returned value must be signed for SNR. Reasonable values easily fit within either 8.8 or 16.16. > 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? The returned values are log base 10 numbers not binary integers. The hard part is not formatting the returned value, but computing it from the raw number returned by the hardware. The actual precision is a function of the dB value being returned for a particular mode on a particular card. The driver writer can decide how much time and space to use. The application will be able to easily scale the returned value as needed. > 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. Another argument in favor of a 32 bit value is that some hardware returns a value that is not 16 bits long. > 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. Error rate and error counts are usually available. -- Mac _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
