Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em Thu, 17 Jan 2013 19:22:06 +0200
Antti Palosaari <crope@xxxxxx> escreveu:

> On 01/17/2013 07:16 PM, Manu Abraham wrote:
> > On Thu, Jan 17, 2013 at 3:03 PM, Antti Palosaari <crope@xxxxxx> wrote:
> >> On 01/17/2013 05:40 AM, Manu Abraham wrote:
> >>> MB86A20 is not the only demodulator driver with the Linux DVB.
> >>> And not all devices can output in dB scale proposed by you, But any device
> >>> output can be scaled in a relative way. So I don't see any reason why
> >>> userspace has to deal with cumbersome controls to deal with redundant
> >>> statistics, which is nonsense.
> >>
> >>
> >> What goes to these units in general, dB conversion is done by the driver
> >> about always. It is quite hard or even impossible to find out that formula
> >> unless you has adjustable test signal generator.
> >>
> >> Also we could not offer always dBm as signal strength. This comes to fact
> >> that only recent silicon RF-tuners are able to provide RF strength. More
> >> traditionally that estimation is done by demod from IF/RF AGC, which leads
> >> very, very, rough estimation.
> >
> > What I am saying is that, rather than sticking to a dB scale, it would be
> > better to fit it into a relative scale, ie loose dB altogether and use only the
> > relative scale. With that approach any device can be fit into that convention.
> > Even with an unknown device, it makes it pretty easy for anyone to fit
> > into that
> > scale. All you need is a few trial runs to get maxima/minima. When there
> > exists only a single convention that is simple, it makes it more easier for
> > people to stick to that convention, rather than for people to not support it.

As dB scale is never used for BER and UCB, I'm assuming that we're
talking about signal strength and S/N measures.

Get the maxima/minima for signal strength and S/N measures can be hard,
as it would require a signal generator and a noise generator that can
adjust the power levels for the signal and noise.

Also, if one has both, he/she can calibrate the scale to dB/dBm.

> That is true. I don't have really clear opinion whether to force all to 
> one scale, or return dBm those which could and that dummy scale for the 
> others. Maybe I will still vote for both relative and dBm.

>From the statistics you collected, most developers implemented dB scale,
especially with the new drivers. I also remember that most people mentioned
their preference to dB in the past.

> Shortly there is two possibilities:
> 1) support only relative scale

That doesn't solve, as a relative scale could still be logarithm or
linear. 

IMHO, a linear scale that doesn't much sense, as the effect 
of the signal power (or noise power) affects the quality
in a logarithm scale, but I'm pretty sure that some drivers 
report relative scales in a log scale, while others report
it with a linear scale.

> 2) support both dBm and relative scale (with dBm priority)

That seems to be the only choice if we want to improve from the current
status, e. g. explicitly saying what is the scale, when the developer
is able to discover it somehow (datasheets, empirical measurement,
reference drivers, etc).

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux