From: Simon Farnsworth <simon.farnsworth@onelan.com>
To: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: "Frank Schäfer" <fschaefer.oss@googlemail.com>,
"Mauro Carvalho Chehab" <mchehab@redhat.com>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>
Subject: Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
Date: Wed, 09 Jan 2013 11:02:23 +0000 [thread overview]
Message-ID: <9912400.S8YXz1JbUM@f17simon> (raw)
In-Reply-To: <CAGoCfiwwLwJkjZhEZP6-ek6cs6j51kNEDTC2LSmDnbimgX0KLQ@mail.gmail.com>
On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote:
> On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth
> <simon.farnsworth@onelan.com> wrote:
> > The wireless folk use dBm (reference point 1 milliwatt), as that's the
> > reference point used in the 802.11 standard.
> >
> > Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference
> > point (so suitable for carrier to noise etc, or for when the reference point
> > is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is
> > 1mW, so that frontends report in dBm?
> >
> > Note that if the frontend internally uses a different reference point, the
> > conversion is always going to be adding or subtracting a constant.
>
> Hi Simon,
>
> Probably the biggest issue you're going to have is that very few of
> the consumer-grade demodulators actually report data in that format.
> And only a small subset of those actually provide the documentation in
> their datasheet.
>
<snip>
My specific concern is that we already see people complaining that their cable
system or aerial installer's meter comes up with one number, and our
documentation has completely different numbers. When we dig, this usually
turns out to be because our documentation is in dBm, while their installer is
using dBmV or dBµW, and no-one at the customer site knows the differences.
If consumer demods don't report in a dB scale at all, we should drop dB as a
unit; if they do report in a true dB scale, but the reference point is
normally not documented, we need some way to distinguish demods where the
reference point is unknown, and demods where someone has taken the time to
find the reference point (which can be done with a signal generator).
This is sounding more and more like an argument for adding
FE_SCALE_DECIBEL_MILLIWATT - it gives those applications that care a way to
tell the user that the signal strength reading from the application should
match up to the signal strength reading on your installer's kit. Said
applications could even choose to do the conversions for you, giving you all
four commonly seen units (dBm, dBmV at 50Ω, dBmV at 75Ω, dBµW).
> For that matter, even the SNR field being reported in dB isn't going
> to allow you to reliably compare across different demodulator chips.
> If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't
> really mean demod Y performs better - just that it's reporting a
> better number. However it does allow you to compare the demod
> against itself either across multiple frequencies or under different
> signal conditions - which is what typical users really care about.
I'm not expecting people to compare across demods - I only care about the
case where a user has got in a professional installer to help with their
setup. The problem I want to avoid is a Linux application saying "-48 dB
signal strength, 15 dB CNR", and the installer's kit saying "60 dBuV signal
strength, 20 dB CNR", when we have enough information for the Linux
application to say "-48 dBm (60 dBuV at 75Ω), 15 dB CNR", cueing the
professional to remember that not all dB use the same reference point, and
from there into accepting that Linux is reporting a similar signal strength
and CNR to his kit.
This also has implications for things like VDR - if the scale is
FE_SCALE_DECIBEL but the measurement is absolute, the application probably
doesn't want to report the measurement as a dB measure, but as an arbitrary
scale; again, you don't want the application saying "50 dB", when the
professional installer tells you that you have "0 dBuV".
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
next prev parent reply other threads:[~2013-01-09 11:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-08 0:25 [PATCH RFCv9 0/4] DVB QoS statistics API Mauro Carvalho Chehab
2013-01-08 0:25 ` [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service Mauro Carvalho Chehab
2013-01-08 11:45 ` Simon Farnsworth
2013-01-08 18:00 ` Frank Schäfer
2013-01-08 23:18 ` Simon Farnsworth
2013-01-08 23:28 ` Devin Heitmueller
2013-01-09 11:02 ` Simon Farnsworth [this message]
2013-01-09 15:24 ` Mauro Carvalho Chehab
2013-01-10 10:19 ` Simon Farnsworth
2013-01-13 13:30 ` [linux-media] " Klaus Schmidinger
2013-01-08 12:33 ` Mauro Carvalho Chehab
2013-01-08 0:25 ` [PATCH RFCv9 2/4] dvb: the core logic to handle the DVBv5 QoS properties Mauro Carvalho Chehab
2013-01-08 0:25 ` [PATCH RFCv9 3/4] mb86a20s: provide signal strength via DVBv5 stats API Mauro Carvalho Chehab
2013-01-08 0:25 ` [PATCH RFCv9 4/4] mb86a20s: add BER measure Mauro Carvalho Chehab
2013-01-08 0:37 ` [PATCH RFCv9] " Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9912400.S8YXz1JbUM@f17simon \
--to=simon.farnsworth@onelan.com \
--cc=dheitmueller@kernellabs.com \
--cc=fschaefer.oss@googlemail.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox