Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite

[wk <handygewinnspiel@gmx.de>]

Devin Heitmueller schrieb:
> On Fri, Mar 13, 2009 at 6:27 PM, VDR User <user.vdr@gmail.com> wrote:
>   
>> Just wanted to comment that I'm glad there is a lot of interest in
>> this.  I've heard endless talk & confusion on the user end over the
>> years as to the accuracy of the values, or in some cases (as with
>> Genpix adapters for example) where you don't seem to get any useful
>> information.  Of course making it really hard for people who are
>> trying to aim dishes and the like in the case of dvb-s*.
>>
>> A quick question about implimenting this though..  What's the most
>> difficult component?
>>     
>
> Hello,
>
> There are basically two "difficult components"
>
> 1.  Getting everyone to agree on a standard representation for the
> field, and how to represent certain error conditions (such as when a
> demod doesn't support SNR, or when it cannot return a valid value at a
> given time).
>
>   
Its just straightforward as described in DVB API, chapters
2.2.3 FE READ STATUS
2.2.4 FE READ BER
2.2.5 FE READ SNR
2.2.6 FE READ SIGNAL STRENGTH
2.2.7 FE READ UNCORRECTED BLOCKS

if ioctl suceeds with valid data: 0, if not one of
EBADF            no valid fi\x02le descriptor.
EFAULT          error condition
ENOSIGNAL  not yet, i have no signal..
ENOSYS         not supported by device.

> 2.  Converting all the drivers to the agreed-upon format.  For some
> drivers this is relatively easy as we have specs available for how the
> SNR is represented.  For others, the value displayed is entirely
> reverse engineered so the current representations are completely
> arbitrary.
>
> Devin
>
>   
Since a lot of frontends have no proper docs, probably providing the 
signal strength unit with a second ioctl could make sense here.

a.u.          arbitrary units, not exactly known or not perfectly working
dBµV       comparable trough all devices, but probably not possible for all
percent     technical not understandable, percent relative to what? 
Assumes that there is a optimum/hard limit of 100% which is not the case.

Showing values as human readings is on the app side, so hex output in 
raw numbers are just fine here. No change needed.

-- Winfried