femon signal strength

femon signal strength

[James]

My signal strength is always above 0 but when I use -H, it is 0%.
Does that mean my signal strength is <0%?
Maybe femon should report 0.x%.

$ femon
FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC)
status SCVYL | signal 00b9 | snr 00b9 | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK

$ femon -H
FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC)
status SCVYL | signal   0% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK

Is it normal to have <0% signal strength and still get reception?

Re: femon signal strength

[Devin Heitmueller]

On Wed, Oct 26, 2011 at 12:36 AM, James <bjlockie@lockie.ca> wrote:
> My signal strength is always above 0 but when I use -H, it is 0%.
> Does that mean my signal strength is <0%?
> Maybe femon should report 0.x%.
>
> $ femon
> FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC)
> status SCVYL | signal 00b9 | snr 00b9 | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
>
> $ femon -H
> FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC)
> status SCVYL | signal   0% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
>
> Is it normal to have <0% signal strength and still get reception?

For this demodulator, this is normal.  The issue is there is no set
standard for the way in which signal level and SNR are reported in the
linux DVB API, and as a result there are numerous different formats.
The format the s5h1409 demodulator driver delivers it doesn't match
the demodulator that the person who wrote femon had available to
him/her (the s5h1409 delivers both fields in 0.1dB increments, while
whatever demod the femon author had to test with expected signal to be
0-65535 and SNR to be in 1/256 increments).

In other words if you have an SNR of 30.0 dB, femon sees 0x012c, which
it treats as a percentage of 0xffff which is 0.00457%, which gets
rendered as 0%.

Unfortunately, the driver community has never been able to form a
consensus on how the data should be reported, so you cannot really
argue the s5h1409 driver is "doing it wrong" (numerous other drivers
report in the same manner as the s5h1409).  You can read the mailing
list archive for the gory history.  It really is a fine example of the
failure associated with "design by committee".

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: femon signal strength

[James]

On 10/26/11 04:15, Devin Heitmueller wrote:
> On Wed, Oct 26, 2011 at 12:36 AM, James<bjlockie@lockie.ca>  wrote:
>> My signal strength is always above 0 but when I use -H, it is 0%.
>> Does that mean my signal strength is<0%?
>> Maybe femon should report 0.x%.
>>
>> $ femon
>> FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC)
>> status SCVYL | signal 00b9 | snr 00b9 | ber 00000000 | unc 00000000 |
>> FE_HAS_LOCK
>>
>> $ femon -H
>> FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC)
>> status SCVYL | signal   0% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
>>
>> Is it normal to have<0% signal strength and still get reception?
> For this demodulator, this is normal.  The issue is there is no set
> standard for the way in which signal level and SNR are reported in the
> linux DVB API, and as a result there are numerous different formats.
How many different formats are there (do I have to go through the archive)?
Would it be feasable to change femon to handle different formats?

femon was written by Johannes Stezenbach (see DVB-apps/szap/femon.c ).

I'm going to try to change the code to at least work with my FE. :-)
> The format the s5h1409 demodulator driver delivers it doesn't match
> the demodulator that the person who wrote femon had available to
> him/her (the s5h1409 delivers both fields in 0.1dB increments, while
> whatever demod the femon author had to test with expected signal to be
> 0-65535 and SNR to be in 1/256 increments).
>
> In other words if you have an SNR of 30.0 dB, femon sees 0x012c, which
> it treats as a percentage of 0xffff which is 0.00457%, which gets
> rendered as 0%.
>
> Unfortunately, the driver community has never been able to form a
> consensus on how the data should be reported, so you cannot really
> argue the s5h1409 driver is "doing it wrong" (numerous other drivers
> report in the same manner as the s5h1409).  You can read the mailing
> list archive for the gory history.  It really is a fine example of the
> failure associated with "design by committee".
>
> Devin
>

Re: femon signal strength

[Devin Heitmueller]

On Wed, Oct 26, 2011 at 3:45 PM, James <bjlockie@lockie.ca> wrote:
> How many different formats are there (do I have to go through the archive)?
> Would it be feasable to change femon to handle different formats?

There are three or four common formats, and there is no real way for
an application to know which format was used unless it perhaps
hard-codes some table of demodulator driver names into the source
(which by the way will cause breakage if efforts are made to change
the demods to use a common format).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: femon signal strength

[James]

On 10/26/11 15:49, Devin Heitmueller wrote:
> On Wed, Oct 26, 2011 at 3:45 PM, James<bjlockie@lockie.ca>  wrote:
>> How many different formats are there (do I have to go through the archive)?
>> Would it be feasable to change femon to handle different formats?
> There are three or four common formats, and there is no real way for
> an application to know which format was used unless it perhaps
> hard-codes some table of demodulator driver names into the source
> (which by the way will cause breakage if efforts are made to change
> the demods to use a common format).
>
> Devin
>
I was thinking of a table. :-)

How about adding switches to femon, it won't be automatic?

I'm going to make femon work for my card, anyways. :-)

Re: femon signal strength

[Steffen Barszus]

On Wed, 26 Oct 2011 15:58:32 -0400
James <bjlockie@lockie.ca> wrote:

> On 10/26/11 15:49, Devin Heitmueller wrote:
> > On Wed, Oct 26, 2011 at 3:45 PM, James<bjlockie@lockie.ca>  wrote:
> >> How many different formats are there (do I have to go through the
> >> archive)? Would it be feasable to change femon to handle different
> >> formats?
> > There are three or four common formats, and there is no real way for
> > an application to know which format was used unless it perhaps
> > hard-codes some table of demodulator driver names into the source
> > (which by the way will cause breakage if efforts are made to change
> > the demods to use a common format).
> >
> > Devin
> >
> I was thinking of a table. :-)
> 
> How about adding switches to femon, it won't be automatic?
> 
> I'm going to make femon work for my card, anyways. :-)

This is no solution - drivers should be patched to deliver result in
common format. femon is not the only application reading this values.
And every application carrying its own set of correction tables doesn't
help in any way. Shouldn't be to hard to agree on one scale and scale
whatever value to that in reporting the signal strength.

Re: femon signal strength

[Steffen Barszus]

On Sat, 5 Nov 2011 15:38:50 -0400
Devin Heitmueller <dheitmueller@kernellabs.com> wrote:

> On Saturday, November 5, 2011, Steffen Barszus
> <steffenbpunkt@googlemail.com> wrote:
> > On Wed, 26 Oct 2011 15:58:32 -0400
> > James <bjlockie@lockie.ca> wrote:
> >> How about adding switches to femon, it won't be automatic?
> >>
> >> I'm going to make femon work for my card, anyways. :-)
> >
> > This is no solution - drivers should be patched to deliver result in
> > common format. femon is not the only application reading this
> > values. And every application carrying its own set of correction
> > tables doesn't help in any way. Shouldn't be to hard to agree on
> > one scale and scale whatever value to that in reporting the signal
> > strength.
> 
> You would think this would be relatively simple to get a consensus on.
> You would be wrong though.  I would suggest doing a search of the ML
> for "SNR" so you can see all. the history of the debate amongst the
> driver developers.

I don't need to read the history of this and i am not even interested
in doing so. No matter what "The right solution" is, showing the
inability of acting as a team and putting the conflict to the user is
the worst solution you can achieve. Any uniform scale is better, then
whats there at the moment. 

Being ignorant in this respect is and was intended.  

Re: femon signal strength

[Steffen Barszus]

On Sun, 6 Nov 2011 10:01:49 -0500
Devin Heitmueller <dheitmueller@kernellabs.com> wrote:

> On Sunday, November 6, 2011, Steffen Barszus
> <steffenbpunkt@googlemail.com> wrote:
> > On Sat, 5 Nov 2011 15:38:50 -0400
> > Devin Heitmueller <dheitmueller@kernellabs.com> wrote:
> >
> >> On Saturday, November 5, 2011, Steffen Barszus
> >> <steffenbpunkt@googlemail.com> wrote:
> >> > On Wed, 26 Oct 2011 15:58:32 -0400
> >> > James <bjlockie@lockie.ca> wrote:
> >> >> How about adding switches to femon, it won't be automatic?
> >> >>
> >> >> I'm going to make femon work for my card, anyways. :-)
> >> >
> >> > This is no solution - drivers should be patched to deliver
> >> > result in common format. femon is not the only application
> >> > reading this values. And every application carrying its own set
> >> > of correction tables doesn't help in any way. Shouldn't be to
> >> > hard to agree on one scale and scale whatever value to that in
> >> > reporting the signal strength.
> >>
> >> You would think this would be relatively simple to get a consensus
> >> on. You would be wrong though.  I would suggest doing a search of
> >> the ML for "SNR" so you can see all. the history of the debate
> >> amongst the driver developers.
> >
> > I don't need to read the history of this and i am not even
> > interested in doing so. No matter what "The right solution" is,
> > showing the inability of acting as a team and putting the conflict
> > to the user is the worst solution you can achieve. Any uniform
> > scale is better, then whats there at the moment.
> >
> > Being ignorant in this respect is and was intended.
> 
> Yes, as a team the Linux v4l-dvb team very much resembles
> dysfunctional family.  And saying this as one of the developers, it
> is pretty embarrassing that we haven't been able to agree on a
> standard (and I've said on numerous occasions when discussing this
> issue that any standard that is uniform is better than no standard at
> all).  "Perfect is the enemy of good"

i know that and i didn't mention with any word _you_ should fix that.
However it needs to be fixed. 

> That said, when random users show up and berate the developers for not
> thinking of the user experience, my knee-jerk reaction is to think,
> "Fuck you.  You don't pay my salary and it's not my job to work on
> the things you think are important.  Submit you own patches if you
> think you can do better.". Obviously I don't say that because it
> isn't polite, but the core sentiment is accurate.

First i did not berate anyone. Second i don't care if you think about
user experience. I said don't put your conflicts to the user. Third I
don't tell you what to do. 

I just stated the obvious. 

Let me rephrase what i tried to say initially:

No please don't start patching femon for a single card, there are other
applications using this interface, which would possibly need to go the
same route, once this get started. Then there are applications which
wont do this (which i can understand, because its wrong). Suggestion
will be to patch/fix the driver - which in the end means that the fight
will be done at the back of the end user or people who try to make life
easier for them and for example putting together specialized linux
distributions. So from my perspective it means that beside this patches:

ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches/

It will start to become more patches for the different cards, which i
get asked for to include it in my dkms package, or people start making
patches for vdr and other applications to do the same as suggested here,
which also end up at the same side. 

This is frustrating. Has my frustration been visible in my
mail ? Not impossible. But where else than on this list i could plead
for help in getting this fixed at the right place ? Devin i'm not asking
you to fix it, i'm writing to linux-media as i did in my initial mail. 

Re: femon signal strength

[Andreas Oberritter]

I didn't receive Devin's mail, so I'm replying to this one instead, see
below:

On 06.11.2011 20:59, Steffen Barszus wrote:
> On Sun, 6 Nov 2011 10:01:49 -0500
> Devin Heitmueller <dheitmueller@kernellabs.com> wrote:
> 
>> On Sunday, November 6, 2011, Steffen Barszus
>> <steffenbpunkt@googlemail.com> wrote:
>>>
>>> Any uniform
>>> scale is better, then whats there at the moment.

[...]

>> (and I've said on numerous occasions when discussing this
>> issue that any standard that is uniform is better than no standard at
>> all).  "Perfect is the enemy of good"

Quoting myself from three years ago, I propose to add an interface to
read SNR in units of db/100:

On 17.10.2008 11:55, Andreas Oberritter wrote:
> 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.

S2API currently implements none of the signal quality measurement
commands that v3 knows about. Nevertheless, it should be easy to add a
property:

/* SNR in units of dB/100 */
#define DTV_SNR		44

If a driver does not implement this property, the core should return an
error (i.e. set dtv_property.result to a non-zero value, e.g. -EOPNOTSUPP).

Regards,
Andreas

Re: femon signal strength

[Luca Olivetti]

Al 07/11/2011 11:47, En/na Andreas Oberritter ha escrit:
> I didn't receive Devin's mail, so I'm replying to this one instead, see
> below:

[...]
> Quoting myself from three years ago, I propose to add an interface to
> read SNR in units of db/100:

A previous version of the dvb api specified the unit of snr as db/1000000

http://linuxtv.org/downloads/legacy/old/linux_dvb_api-20020304.pdf

page 55, FE_READ_SIGNAL_STRENGTH

"The signal-to-noise ratio, as a multiple of 10E-6 dB, is stored into *snr.
Example: a value of 12,300,000 corresponds to a signal-
to-noise ratio of 12.3 dB."

It also defined the unit for ber (multiple of 10E-9).

However it was dropped from subsequent revisions, I don't know why.

Bye
-- 
Luca

Re: femon signal strength

[Andreas Oberritter]

On 07.11.2011 16:13, Luca Olivetti wrote:
> Al 07/11/2011 11:47, En/na Andreas Oberritter ha escrit:
>> I didn't receive Devin's mail, so I'm replying to this one instead, see
>> below:
> 
> [...]
>> Quoting myself from three years ago, I propose to add an interface to
>> read SNR in units of db/100:
> 
> A previous version of the dvb api specified the unit of snr as db/1000000
> 
> http://linuxtv.org/downloads/legacy/old/linux_dvb_api-20020304.pdf
> 
> page 55, FE_READ_SIGNAL_STRENGTH
> 
> "The signal-to-noise ratio, as a multiple of 10E-6 dB, is stored into *snr.
> Example: a value of 12,300,000 corresponds to a signal-
> to-noise ratio of 12.3 dB."
> 
> It also defined the unit for ber (multiple of 10E-9).
> 
> However it was dropped from subsequent revisions, I don't know why.
> 
> Bye

It was dropped because most (or all?) of the drivers available at the
time were created without access to register descriptions and thus
nobody of the developers knew how to calculate meaningful values and/or
nobody was allowed to publish code based on confidential information. It
was decided that big values meant good signal instead, which was good
enough to print a signal meter bar without any real numbers.

The situation has changed since then. I think two decimal digits should
be sufficient. A value displayed to the user would probably have at most
one decimal digit. The SNR measured by a demodulator isn't very
accurate, so adding more decimal digits doesn't improve the precision.

Personally, I don't care much whether the unit is db/10, db/100 or
db/1000. I just think db/100 is a reasonable choice and IIRC it's the
unit that most of the vendor drivers I've seen in the past are using.

Regards,
Andreas