On Fri, Oct 23, 2009 at 4:12 AM, Markus Rechberger
<mrechberger@xxxxxxxxx> wrote:
> On Thu, Oct 22, 2009 at 10:29 PM, Manu Abraham <abraham.manu@xxxxxxxxx> wrote:
>> On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
>> <mchehab@xxxxxxxxxxxxx> wrote:
>>> Em Thu, 22 Oct 2009 21:13:30 +0200
>>> Jean Delvare <khali@xxxxxxxxxxxx> escreveu:
>>>
>>>> Hi folks,
>>>>
>>>> I am looking for details regarding the DVB frontend API. I've read
>>>> linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
>>>> FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
>>>> commands return, however it does not give any information about how the
>>>> returned values should be interpreted (or, seen from the other end, how
>>>> the frontend kernel drivers should encode these values.) If there
>>>> documentation available that would explain this?
>>>>
>>>> For example, the signal strength. All I know so far is that this is a
>>>> 16-bit value. But then what? Do greater values represent stronger
>>>> signal or weaker signal? Are 0x0000 and 0xffff special values? Is the
>>>> returned value meaningful even when FE_HAS_SIGNAL is 0? When
>>>> FE_HAS_LOCK is 0? Is the scale linear, or do some values have
>>>> well-defined meanings, or is it arbitrary and each driver can have its
>>>> own scale? What are the typical use cases by user-space application for
>>>> this value?
>>>>
>>>> That's the kind of details I'd like to know, not only for the signal
>>>> strength, but also for the SNR, BER and UB. Without this information,
>>>> it seems a little difficult to have consistent frontend drivers.
>>>
>>> We all want to know about that ;)
>>>
>>> Seriously, the lack of a description of the meaning of the ranges for those
>>> read values were already widely discussed at LMML and at the legacy dvb ML.
>>> We should return this discussion again and decide what would be the better
>>> way to describe those values.
>>>
>>> My suggestion is that someone summarize the proposals we had and give some time
>>> for people vote. After that, we just commit the most voted one, and commit the
>>> patches for it. A pending question that should also be discussed is what we will
>>> do with those dvb devices where we simply don't know what scale it uses. There
>>> are several of them.
>>
>>
>> Sometime back, (some time in April) i proposed a patch which addressed
>> the issue to scale "even those devices which have a weird scale or
>> none". Though based on an older tree of mine, here is the patch again.
>> If it looks good enough, i can port the patch to accomodate other
>> devices as well.
>>
>
> A few of our customers were requiring additional statistic
> information, so we added follwing
> command to our DVB API:
>
> FE_GET_SIGQUALITY
>
> struct media_sigquality {
> uint16_t MER; /**< in steps of 0.1 dB
> */
> uint32_t preViterbiBER ; /**< in steps of 1/scaleFactorBER
> */
> uint32_t postViterbiBER ; /**< in steps of 1/scaleFactorBER
> */
> uint32_t scaleFactorBER; /**< scale factor for BER
> */
> uint32_t packetError ; /**< number of packet errors
> */
> uint32_t postReedSolomonBER ; /**< in steps of 1/scaleFactorBER
> */
> uint32_t indicator; /**< indicative signal quality
> low=0..100=high */
> }
>
> It's a one shot request.
> it might be good to standardize this, although we can live with that
> additional command too.
Based on the above data structure, since UNC is calculated from pre -
post viterbi, any good reason why you need it explicit ? Which
otherwise is redundant. Still when simplified, it looks exactly the
same as the version 3.2 frontend statistic information alone except
for the BER scale, isn't it ?
Regards,
Manu
--
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
