Re: femon signal strength
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 dheitmuel...@kernellabs.com wrote:
On Sunday, November 6, 2011, Steffen Barszus
steffenbpu...@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
--
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
Re: femon signal strength
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/100 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 -- 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
Re: femon signal strength
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/100 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 -- 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
Re: femon signal strength
On Sat, 5 Nov 2011 15:38:50 -0400 Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Saturday, November 5, 2011, Steffen Barszus steffenbpu...@googlemail.com wrote: On Wed, 26 Oct 2011 15:58:32 -0400 James bjloc...@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. -- 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
Re: femon signal strength
On Sun, 6 Nov 2011 10:01:49 -0500 Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sunday, November 6, 2011, Steffen Barszus steffenbpu...@googlemail.com wrote: On Sat, 5 Nov 2011 15:38:50 -0400 Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Saturday, November 5, 2011, Steffen Barszus steffenbpu...@googlemail.com wrote: On Wed, 26 Oct 2011 15:58:32 -0400 James bjloc...@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. -- 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
Re: femon signal strength
On Wed, 26 Oct 2011 15:58:32 -0400 James bjloc...@lockie.ca wrote: On 10/26/11 15:49, Devin Heitmueller wrote: On Wed, Oct 26, 2011 at 3:45 PM, Jamesbjloc...@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. -- 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
Re: femon signal strength
On Wed, Oct 26, 2011 at 12:36 AM, James bjloc...@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 | unc | 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 0x 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 -- 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
Re: femon signal strength
On 10/26/11 04:15, Devin Heitmueller wrote: On Wed, Oct 26, 2011 at 12:36 AM, Jamesbjloc...@lockie.ca wrote: My signal strength is always above 0 but when I use -H, it is 0%. Does that mean my signal strength is0%? Maybe femon should report 0.x%. $ femon FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC) status SCVYL | signal 00b9 | snr 00b9 | ber | unc | 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 have0% 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 0x 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 -- 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
Re: femon signal strength
On 10/26/11 15:49, Devin Heitmueller wrote: On Wed, Oct 26, 2011 at 3:45 PM, Jamesbjloc...@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. :-) -- 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
