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

[Manu Abraham]

Rusty Scott wrote:
> Having parsed through a number of the comments on this thread and feeling that
> many of the responses have missed the mark.  Here is my bottom line:
>
> 1)  If the only thing the end user wants is signal strength and quality then why
> doesn't the API only support these calls?  Let the driver developer decide how
> these are measured for a given card.  Value is 0 to 100% for both strength and
> quality.  (Sounds absurd when taken to extreme)
>
> 2)  Why not return BER or UCB in values from 0 to 100%?  The user is really only
> concerned about if these are high or low.  They don't care about any absolute
> number.
>
> 3)  If SNR is useless in determining signal quality why have the capability in
> the API at all?  If the capability is there to read SNR then it should be SNR
> and since the driver is where chip specific information is stored, the driver
> should know how to put that number into dB because it is different for
> different chips.  If a card doesn't have the capability to actually determine
> SNR then it shouldn't be returning one.  It should have other parameters to help
> determine signal quality.
>   

Hmm.. you didn't follow the issue with the scale in dB. The issue is 
that the demod (which the driver driver names itself as) doesn't do any 
conversion statistics. For example suppose you have a STV0299 demod 
based tuner from vendor A. vendor A will provide additional RF hardware, 
which will alter the input RF parameters of the tuner.

Now vendor B will think that he stick to the reference design. Vendor C 
will think both these guys are off track, and he will provide another 
alternate solution.

In this case, the parameters in all these cases are different.

Coming back to square one, what we thought was that instead of having 
just demod definitions alone, we will have tuner definitions too, we 
have access to information about many devices, but the current API case 
has limitations, such that we cannot fit it in.

In this aspect what we decided was that we will go to a standstill with 
the current API, since the new changes will anyway break compatibility 
for sure. In such a case, what we decided was that we will get all the 
required changes and make one change as to break the API for once, 
rather than multiple times.

and hence the situation.


Manu