[linux-dvb] Revisiting the SNR/Strength issue

[linux-dvb] Revisiting the SNR/Strength issue

[Devin Heitmueller]

I know that this has been brought up before, but would it be possible
to revisit the issue with SNR and strength units of measure being
inconsistent across frontends?

I know that we don't always know what the units of measure are for
some frontends, but perhaps we could at least find a way to tell
applications what the units are for those frontends where it is known?

For example, if we had a call that returned the units that the
frontend is expecting to return the SNR in (e.g. dB, %, etc),
applications would know how to handle it (and for those cases where we
really don't know what the units are, the call can return "unknown" so
the application just represents the value on a linear scale).

I know we probably can't agree on what units the SNR field should
return, but if we could at least agree on a way where the frontend can
tell us what the units are, the field could actually be useful to
applications.  This approach would be backward compatible because we
wouldn't be expecting any of the frontends to change how they return
the underlying data - it would only have to add an additional call
implemented to return what units that data is in.

Right now the fields are pretty useless to applications.  For example,
with Kaffeine the data shows up great with my HVR-950 (which returns a
percentage), but when it said 0% with my Pinnacle 801e, as a user I
thought something was broken (the s5h1411 returns data in dB).

Devin

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

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Revisiting the SNR/Strength issue

[Steven Toth]

Devin Heitmueller wrote:
> I know that this has been brought up before, but would it be possible
> to revisit the issue with SNR and strength units of measure being
> inconsistent across frontends?
> 
> I know that we don't always know what the units of measure are for
> some frontends, but perhaps we could at least find a way to tell
> applications what the units are for those frontends where it is known?

The SNR units should be standardized into a single metric, something 
actually useful like ESNO or db. If that isn't available then we should 
aim to eyeball / manually calibrate impossible boards against known 
reliable demods on the same feed, it should be close enough.

This requires patience and time from the right people with the right 
hardware.

- Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Revisiting the SNR/Strength issue

[Devin Heitmueller]

On Wed, Oct 15, 2008 at 10:30 AM, Steven Toth <stoth@linuxtv.org> wrote:
> The SNR units should be standardized into a single metric, something
> actually useful like ESNO or db. If that isn't available then we should aim
> to eyeball / manually calibrate impossible boards against known reliable
> demods on the same feed, it should be close enough.
>
> This requires patience and time from the right people with the right
> hardware.

I agree that standardizing on a particular unit would be the ideal
scenario.  Realistically though, do you have any confidence that this
would actually happen?  Many frontends would have to change, reverse
engineering would have to be done, and in many cases without a signal
generator this would be very difficult.  This could take months or
years, or might never happen.

Certainly I'm in favor of expressing that there is a preferred unit
that new frontends should use (whether that be ESNO or db), but the
solution I'm suggesting would allow the field to become useful *now*.
This would hold us over until all the other frontends are converted to
db (which I have doubts will ever actually happen).

Devin

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

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Revisiting the SNR/Strength issue

[Steven Toth]

Devin Heitmueller wrote:
> On Wed, Oct 15, 2008 at 10:30 AM, Steven Toth <stoth@linuxtv.org> wrote:
>> The SNR units should be standardized into a single metric, something
>> actually useful like ESNO or db. If that isn't available then we should aim
>> to eyeball / manually calibrate impossible boards against known reliable
>> demods on the same feed, it should be close enough.
>>
>> This requires patience and time from the right people with the right
>> hardware.
> 
> I agree that standardizing on a particular unit would be the ideal
> scenario.  Realistically though, do you have any confidence that this
> would actually happen?  Many frontends would have to change, reverse

It will happen when someone cares enough to do it, that's the Linux mantra.

Let's quantify this. How many frontends would have to change?

> engineering would have to be done, and in many cases without a signal
> generator this would be very difficult.  This could take months or
> years, or might never happen.

You don't need a signal generator, you _do_ need a comparison product 
that is reliably reporting db.

> 
> Certainly I'm in favor of expressing that there is a preferred unit
> that new frontends should use (whether that be ESNO or db), but the
> solution I'm suggesting would allow the field to become useful *now*.
> This would hold us over until all the other frontends are converted to
> db (which I have doubts will ever actually happen).

I'm not in favour of this.

I'd rather see a single unit of measure agreed up, and each respective 
maintainer go back and perform the necessary code changes. I'm speaking 
as a developer of eight (?) different demod drivers in the kernel. 
That's no small task, but I'd happily conform if I could.

Lastly, for the sake of this discussion, assuming that db is agreed 
upon, if the driver cannot successfully delivery SNR in terms of db then 
  the bogus function returning junk should be removed.

Those two changes alone would be a better long term approach, I think.

- Steve


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Revisiting the SNR/Strength issue

[Devin Heitmueller]

On Wed, Oct 15, 2008 at 2:18 PM, Steven Toth <stoth@linuxtv.org> wrote:
> It will happen when someone cares enough to do it, that's the Linux mantra.

I care enough to do it, but I'm trying to see if there's a solution
that doesn't require me to learn the intimate details of how SNR is
computed for every demodulator in the codebase (and then change that
representation to dB).

I think it's actually really important that regular users be able to
use their application of choice (Kaffeine/MythTV/other) and be able to
tell whether they have a descent signal without having to look at the
kernel driver source code for the demodulator that is in their tuner
(that sentence alone has six words most regular users couldn't even
define).

> Let's quantify this. How many frontends would have to change?

I didn't get a chance to do a count last night.  I will do this
tonight when I get home.

>> engineering would have to be done, and in many cases without a signal
>> generator this would be very difficult.  This could take months or
>> years, or might never happen.
>
> You don't need a signal generator, you _do_ need a comparison product that
> is reliably reporting db.
>
>>
>> Certainly I'm in favor of expressing that there is a preferred unit
>> that new frontends should use (whether that be ESNO or db), but the
>> solution I'm suggesting would allow the field to become useful *now*.
>> This would hold us over until all the other frontends are converted to
>> db (which I have doubts will ever actually happen).
>
> I'm not in favour of this.
>
> I'd rather see a single unit of measure agreed up, and each respective
> maintainer go back and perform the necessary code changes. I'm speaking as a
> developer of eight (?) different demod drivers in the kernel. That's no
> small task, but I'd happily conform if I could.
>
> Lastly, for the sake of this discussion, assuming that db is agreed upon, if
> the driver cannot successfully delivery SNR in terms of db then  the bogus
> function returning junk should be removed.
>
> Those two changes alone would be a better long term approach, I think.

I'll see tonight how many demods we're talking about.  Certainly in
the long term I agree that this would be a better approach - I'm just
concerned that "long term" could mean "never", in which case I don't
think it would not be unreasonable to have a less-than-perfect
solution.

Cheers,

Devin

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

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Revisiting the SNR/Strength issue

[Christophe Thommeret]

Le Thursday 16 October 2008 16:28:04 Devin Heitmueller, vous avez écrit :
> On Wed, Oct 15, 2008 at 2:18 PM, Steven Toth <stoth@linuxtv.org> wrote:
> > It will happen when someone cares enough to do it, that's the Linux
> > mantra.
>
> I care enough to do it, but I'm trying to see if there's a solution
> that doesn't require me to learn the intimate details of how SNR is
> computed for every demodulator in the codebase (and then change that
> representation to dB).
>
> I think it's actually really important that regular users be able to
> use their application of choice (Kaffeine/MythTV/other) and be able to
> tell whether they have a descent signal without having to look at the
> kernel driver source code for the demodulator that is in their tuner
> (that sentence alone has six words most regular users couldn't even
> define).

Have to add that most users even don't know what "dB" is. So, whatever the 
unit, an application would have to translate it in an understandable form, 
which could be as simple as :
"Very bad signal quality"
"Bad signal quality"
"Good signal quality"
"Very good signal quality"

> > Let's quantify this. How many frontends would have to change?
>
> I didn't get a chance to do a count last night.  I will do this
> tonight when I get home.
>
> >> engineering would have to be done, and in many cases without a signal
> >> generator this would be very difficult.  This could take months or
> >> years, or might never happen.
> >
> > You don't need a signal generator, you _do_ need a comparison product
> > that is reliably reporting db.
> >
> >> Certainly I'm in favor of expressing that there is a preferred unit
> >> that new frontends should use (whether that be ESNO or db), but the
> >> solution I'm suggesting would allow the field to become useful *now*.
> >> This would hold us over until all the other frontends are converted to
> >> db (which I have doubts will ever actually happen).
> >
> > I'm not in favour of this.
> >
> > I'd rather see a single unit of measure agreed up, and each respective
> > maintainer go back and perform the necessary code changes. I'm speaking
> > as a developer of eight (?) different demod drivers in the kernel. That's
> > no small task, but I'd happily conform if I could.
> >
> > Lastly, for the sake of this discussion, assuming that db is agreed upon,
> > if the driver cannot successfully delivery SNR in terms of db then  the
> > bogus function returning junk should be removed.
> >
> > Those two changes alone would be a better long term approach, I think.
>
> I'll see tonight how many demods we're talking about.  Certainly in
> the long term I agree that this would be a better approach - I'm just
> concerned that "long term" could mean "never".

Yep it could, seeing how much time this issue has been discussed and still no 
solution.


-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Revisiting the SNR/Strength issue

[Andreas Oberritter]

Steven Toth wrote:
> Devin Heitmueller wrote:
>> Certainly I'm in favor of expressing that there is a preferred unit
>> that new frontends should use (whether that be ESNO or db), but the
>> solution I'm suggesting would allow the field to become useful *now*.
>> This would hold us over until all the other frontends are converted to
>> db (which I have doubts will ever actually happen).
> 
> I'm not in favour of this.
> 
> I'd rather see a single unit of measure agreed up, and each respective 
> maintainer go back and perform the necessary code changes. I'm speaking 
> as a developer of eight (?) different demod drivers in the kernel. 
> That's no small task, but I'd happily conform if I could.
> 
> Lastly, for the sake of this discussion, assuming that db is agreed 
> upon, if the driver cannot successfully delivery SNR in terms of db then 
>   the bogus function returning junk should be removed.
> 
> Those two changes alone would be a better long term approach, I think.

How about adding a new command instead (and a similar one for S2API)? 

/* Read SNR in units of dB/100 */
#define FE_READ_SNR_DB _IOR('o', 74, __u16)

Then it's no problem to slowly migrate the drivers to this interface. The
old interface can still stay for some time without changes. Applications
can try this ioctl, and if it returns an error, then it is not implemented
for the used device.

Regards,
Andreas

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Revisiting the SNR/Strength issue

[Steven Toth]

Andreas Oberritter wrote:
> Steven Toth wrote:
>> Devin Heitmueller wrote:
>>> Certainly I'm in favor of expressing that there is a preferred unit
>>> that new frontends should use (whether that be ESNO or db), but the
>>> solution I'm suggesting would allow the field to become useful *now*.
>>> This would hold us over until all the other frontends are converted to
>>> db (which I have doubts will ever actually happen).
>> I'm not in favour of this.
>>
>> I'd rather see a single unit of measure agreed up, and each respective 
>> maintainer go back and perform the necessary code changes. I'm speaking 
>> as a developer of eight (?) different demod drivers in the kernel. 
>> That's no small task, but I'd happily conform if I could.
>>
>> Lastly, for the sake of this discussion, assuming that db is agreed 
>> upon, if the driver cannot successfully delivery SNR in terms of db then 
>>   the bogus function returning junk should be removed.
>>
>> Those two changes alone would be a better long term approach, I think.
> 
> How about adding a new command instead (and a similar one for S2API)? 
> 
> /* Read SNR in units of dB/100 */
> #define FE_READ_SNR_DB _IOR('o', 74, __u16)
> 
> Then it's no problem to slowly migrate the drivers to this interface. The
> old interface can still stay for some time without changes. Applications
> can try this ioctl, and if it returns an error, then it is not implemented
> for the used device.

Devin has offered to review the demods and snr code, to see the differences.

BTW, I like a couple of the ideas mentioned so far.

Many of the recent Linux demods drivers were written from datasheets, so 
we have access to real credible numbers. I suspect I can also push NXP 
for datasheets on older parts if the maintainers of other demods are 
willing to go the extra mile and add add the code. Other vendors, maybe 
not - let's see.

You can't really judge good / better / best or db if you don't have 
credible esno / db registers, that's should be the first step - to 
understand how many demods have issues and how many are fixable.

The user-facing API is only any good after we know the demods are 
standardized. I tend to think we can get > 80% of the demods reporting 
db or esno, which in turn can easily be abstracted via dvb-core into 
good / better / best or a more appropriate user view.

I don't agree to blindly massaging the demod values and trying to add a 
fake user facing API is a real solution.

I do like that people are talking again, and I will certainly be willing 
to help in fixing demods.

- Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Revisiting the SNR/Strength issue

[Andreas Oberritter]

Steven Toth wrote:
> I don't agree to blindly massaging the demod values and trying to add a
> fake user facing API is a real solution.

I wonder what you're referring to with this sentence.

Regards,
Andreas


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Revisiting the SNR/Strength issue

[Steven Toth]

Andreas Oberritter wrote:
> Steven Toth wrote:
>> I don't agree to blindly massaging the demod values and trying to add a
>> fake user facing API is a real solution.
> 
> I wonder what you're referring to with this sentence.

I think trying to massage various mysterious and unknown demod 
statistics into something that we can barely understand, in order to get 
them exposed in either a single unit of measure, or multiple units of 
measure, isn't a credible solution.

We should go back and find the correct SNR mechanism for each demod. 
Then review and agree on an internal kernel spec, and re-engineer the 
demods to meet the spec.

Devin has started the ball rolling nicely, to allow this to happen.

- Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb