SNR status for demods

SNR status for demods

[Devin Heitmueller]

Hello all,

I have updated my compiled list of the various demods and how they
currently report SNR info (including feedback from people in the last
round).

http://www.devinheitmueller.com/snr.txt

Here's how you can help out:

If you are a maintainer for a device in this list, please let me know
so I can update the document.  If you are the maintainer and somebody
else's name is listed by the device, please do not take offense to
this (it's probably just an error on my part [please email and correct
me]).

If you have specs for a device in this list where the format is
currently "unknown", please let me know as this will be helpful in
identifying which demods we can get accurate information for.

If you know something about how SNR is currently reported by the
driver, and it is not reflected in this list, please let me know and I
will update the document.

All of the above information will be helpful once a format has been
decided on, so we can pull together and finally get a consistent
interface.

Thank you for your time,

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: SNR status for demods

[Ang Way Chuang]

Thank you very much, Devin Heitmueller. This list is a god-sent :).

Devin Heitmueller wrote:
> Hello all,
> 
> I have updated my compiled list of the various demods and how they
> currently report SNR info (including feedback from people in the last
> round).
> 
> http://www.devinheitmueller.com/snr.txt
> 
> Here's how you can help out:
> 
> If you are a maintainer for a device in this list, please let me know
> so I can update the document.  If you are the maintainer and somebody
> else's name is listed by the device, please do not take offense to
> this (it's probably just an error on my part [please email and correct
> me]).
> 
> If you have specs for a device in this list where the format is
> currently "unknown", please let me know as this will be helpful in
> identifying which demods we can get accurate information for.
> 
> If you know something about how SNR is currently reported by the
> driver, and it is not reflected in this list, please let me know and I
> will update the document.
> 
> All of the above information will be helpful once a format has been
> decided on, so we can pull together and finally get a consistent
> interface.
> 
> Thank you for your time,
> 
> Devin
> 

Re: SNR status for demods

[wk]

> I have updated my compiled list of the various demods and how they
> currently report SNR info (including feedback from people in the last
> round).
>
> http://www.devinheitmueller.com/snr.txt
>
>   
What about signal strength and BER readout in parallel for each device 
listed here?
Needs the same docs and would not add too much work..

----

tda10021:  MSE[7..0] (= reg 0x18 )
"Mean Square Error of the demodulated output signal. MSE can be used as a
representation of the signal quality."

    u8 quality = ~tda10021_readreg(state, 0x18);
    *snr = (quality << 8) | quality;

ves1820:    the same.
tda10023:  seems to be the same. (no info, but chip is very close to 
tda10021)

Re: SNR status for demods

[Devin Heitmueller]

On Wed, Mar 18, 2009 at 3:05 PM, wk <handygewinnspiel@gmx.de> wrote:
> What about signal strength and BER readout in parallel for each device
> listed here?

I'm having enough trouble even getting people to agree on the format
for the SNR field.  The strength field is even more subjective.  At
this point, I think it is best to focus on the SNR and once we get
some agreement there we can look at the strength and BER fields.

Updating the DVB documentation is the *easy* part.  The problem is
figuring out what the standard should be in the first place (which
requires some agreement among the demod developers).

> Needs the same docs and would not add too much work..

I agree this would be useful.  Feel free to get started on this.

> tda10021:  MSE[7..0] (= reg 0x18 )
> "Mean Square Error of the demodulated output signal. MSE can be used as a
> representation of the signal quality."
>
>   u8 quality = ~tda10021_readreg(state, 0x18);
>   *snr = (quality << 8) | quality;
>
> ves1820:    the same.
> tda10023:  seems to be the same. (no info, but chip is very close to
> tda10021)

Thanks,

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: SNR status for demods

[Antti Palosaari]

Just ping up old thread since I updated that list.

On 18.03.2009 04:45, Devin Heitmueller wrote:
> Hello all,
>
> I have updated my compiled list of the various demods and how they
> currently report SNR info (including feedback from people in the last
> round).
>
> http://www.devinheitmueller.com/snr.txt

I updated that list up to that day:
http://palosaari.fi/linux/v4l-dvb/snr_2012-05-21.txt

> Here's how you can help out:
>
> If you are a maintainer for a device in this list, please let me know
> so I can update the document.  If you are the maintainer and somebody
> else's name is listed by the device, please do not take offense to
> this (it's probably just an error on my part [please email and correct
> me]).
>
> If you have specs for a device in this list where the format is
> currently "unknown", please let me know as this will be helpful in
> identifying which demods we can get accurate information for.
>
> If you know something about how SNR is currently reported by the
> driver, and it is not reflected in this list, please let me know and I
> will update the document.
>
> All of the above information will be helpful once a format has been
> decided on, so we can pull together and finally get a consistent
> interface.
>
> Thank you for your time,
>
> Devin
>

Basically, but not every case, there seems to be 3 different way:
1) return raw register value without any calculation
2) 0.1 dB
3) scaled to 0-0xffff using some formula

Very many drivers seems to do some dB handling even finally scaling it 
to some value.

regards
Antti
-- 
http://palosaari.fi/

Re: SNR status for demods

[Gianluca Gennari]

Il 22/05/2012 11:09, Antti Palosaari ha scritto:
> 
> Basically, but not every case, there seems to be 3 different way:
> 1) return raw register value without any calculation
> 2) 0.1 dB
> 3) scaled to 0-0xffff using some formula
> 
> Very many drivers seems to do some dB handling even finally scaling it
> to some value.
> 
> regards
> Antti

Another one (from staging):

as102-fe.c:        Pierrick Hascoet, Devin Heitmueller            linear MER

I can provide a trivial patch to convert it to the more common 0.1 dB
format, if you think it's useful.

This note comes from the driver:

/*
 * Note:
 * - in AS102 SNR=MER
 *   - the SNR will be returned in linear terms, i.e. not in dB
 *   - the accuracy equals ±2dB for a SNR range from 4dB to 30dB
 *   - the accuracy is >2dB for SNR values outside this range
 */

Regards,
Gianluca