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

[Simon Farnsworth <simon.farnsworth@onelan.com>]

On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote:
> On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
<snip>
> >
> > It is a common sense that the existing API is broken. If my proposal
> > requires adjustments, please comment on each specific patchset, instead
> > of filling this thread of destructive and useless complains.
> 
> 
> No, the concept of such a generalization is broken, as each new device will
> be different and trying to make more generalization is a waste of developer
> time and effort. The simplest approach would be to do a coarse approach,
> which is not a perfect world, but it will do some good results for all the
> people who use Linux-DVB. Still, repeating myself we are not dealing with
> high end professional devices. If we have such devices, then it makes sense
> to start such a discussion. Anyway professional devices will need a lot of
> other API extensions, so your arguments on the need for professional
> devices that do not exist are pointless and not agreeable to.
> 
Let's step back a bit. As a sophisticated API user, I want to be able to give
my end-users the following information:

 * Signal strength in dBm
 * Signal quality as "poor", "OK" and "good".
 * Ideally, "increase signal strength to improve things" or "attenuate signal
to improve things"

In a DVBv3 world, "poor" equates to UNC != 0, "OK" is UNC == 0, BER != 0,
and "good" is UNC == BER == 0. The idea is that a user seeing "poor" knows
that they will see glitches in the output; a user seeing "OK" knows that
there's no glitching right now, but that the setup is marginal and may
struggle if anything changes, and a user seeing "good" knows that they've got
high quality signal.

VDR wants even simpler - it just wants strength and quality on a 0 to 100
scale, where 100 is perfect, and 0 is nothing present.

In both cases, we want per-layer quality for ISDB-T, for the reasons you've
already outlined.

So, how do you provide such information? Is it enough to simply provide
strength in dBm, and quality as 0 to 100, where anything under 33 indicates
uncorrected errors, and anything under 66 indicates that quality is marginal?
-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com