On Fri, Oct 23, 2009 at 4:12 AM, Markus Rechberger
<mrechber...@gmail.com> wrote:
> On Thu, Oct 22, 2009 at 10:29 PM, Manu Abraham <abraham.m...@gmail.com> wrote:
>> On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
>> <mche...@infradead.org> wrote:
>>> Em Thu, 22 Oct 2009 21:13:30 +0200
>>> Jean Delvare <kh...@linux-fr.org> 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,
>>>> 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:
> 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 ?

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

Reply via email to