On Wed, Mar 26, 2008 at 8:19 PM, Jean Tourrilhes <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 26, 2008 at 06:59:11PM -0400, Luis R. Rodriguez wrote:
> > Jean a question or two for you below.
> >
> > OK I know I seemed happy with the original patch but after some
> > thought I have some concerns. They are below.
>
> Hi there,
>
> I'm, currently on business trip. I'll try to answer the best I
> can. Ping me again next week.
> Note that I did not define what went into mac80211.h, and I
> disclaim any responsability from that.
I'm very well aware you did not define what went into mac80211.h. Also
I'm not blaming anyone for anything, I just wanted to ask you some
details of intentions behind a value used in WE so we can better
implement things moving forward.
> My idea is that the API should be based on real physical
> measurable values as much as possible. The tradeoff is that those
> values should also be useful, often raw values are useless.
ACK
> The most common unit for the RSSI is dBm, but I see that IEEE
> is using RCPTI. I personally don't like RCPTI because it's more
> opaque, people are physically measuring dBm, and are having transmit,
> gain and loss measured in dBs. That's why I think it's important that
> the unit used for that value be dBm.
I think you meant RCPI, and it seems to be well defined actually. The
value is opaque but it is a representation of a dbm value. Again,
quoting from Simon's comment on RCPI:
"The allowed values for the Received Channel Power Indicator (RCPI) parameter
shall be an 8 bit value in the range from 0 through 220, with indicated
values rounded to the nearest 0.5 dB as follows:
0: Power < -110 dBm
1: Power = -109.5 dBm
2: Power = -109.0 dBm
and so on where
RCPI = int{(Power in dBm +110)*2} for 0dbm > Power > -110dBm
220: Power > -0 dBm
221-254: reserved
255: Measurement not available
RCPI shall equal the received RF power within an accuracy of +/-5 dB
(95% confidence interval) within the specified dynamic range of the
receiver. The received RF power shall be determined assuming a receiver
noise equivalent bandwidth equal to the channel bandwidth multiplied by
1.1."
But as discussed already on the lists the problem with RCPI will be
getting hardware to support it and its accuracy. In terms accuracy for
RCPI you need to support "received RF power in the selected channel
for a received frame. This parameter shall be a measure by the PHY
sublayer of the received RF power in the channel measured over the
entire received frame or by other equivalent means which meet the
specified accuracy". I don't believe we have hardware that can fit
this definition yet. Atheros' rssi value is measured during the the
initial 4us of detection, during the preamble and PLCP, not sure if
this fits the definition on the "or" clause ("or by other equivalent
means which meet the specified accuracy"). I also wish and wonder if
we could modify this duration of 4us during which the SNR is measured.
> Now, we would like all hardware to report RSSI in dBm, and get
> done with it. However, some hardware (Atheros) can not do it, because
> their RSSI hardware is uncalibrated. So, what do you do with those
> hardware ? Reporting a "relative" signal strength is probably better
> than nothing.
What 802.11 hardware does report exact dbm signal strength
measurements? At least for Atheros AR5212 hardware there seems to be
an offset value between the actual signal strength and the measured
signal stregth. At Orbit we use a lot of Atheros hardware (800
wireless cards on the grid) and at one point it seems there was a big
concern over the value of signal strength reported and how it differed
amongst cards compared to a real controlled value. I just tried to
gather together a bit of the experience so far and it seems that in
general the offset was small and didn't vary too much. So actually,
unless I am misrepresenting the experience explained so far Atheros
hardware seems provide reliable results, across different experiments,
across different cards. An offset exists but it seems to be
negligible. If you want to be surgically precise you do have to
account for it but it seems it close enough for our purposes.
> Note that it could be uncalibrated in two way. One way is the
> offset (like the Atheros), the other is the slope (older hardware). It
> means that for some hardware, it does not even follow a dB
> curve. Uncalibrated usually means that every instance of the hardware
> is different and you can't have a global correction factor.
Is there standard 802.11 hardware out there that is not calibrated
under this definition?
> For example, check the Aironet driver. The driver has a RSSI
> correction table, for every raw RSSI value, the driver check in a
> table to get the RSSI in dBm. The table is stored in the EPROM of the
> card, and I believe specific to each card. The correction curve is not
> even linear !
> For the Atheros, there is another issue, the offset changes
> over time and is not constant for the card.
I wouldn't be surprised if the offset changes over time but I doubt
its by a lot. How much have you seen the offset change over time? I do
not think we have tested this. I will check.
> Note also that many hardware are not truly calibrated, but
> "sort of" calibrated (Orinoco, HostAP). Good measurement is expensive,
> that's why most implementation do measurement on the cheap. It means
> the value will be correct within some few percents for a large part
> range. Up to now, we pretented that those devices report dBm
> properly. That's why RCPTI talk of expected accuracy of measurement.
>
> So, in WE we have :
> o signal is RSSI in dBm, which is the most useful to apps.
> o if can't do dBm, do relative, which has no expectations.
>
> Now, back to your question.
> This additional value would be cases where only the offset is
> uncalibrated and the slope is correct, like the Atheros. What it would
> allow is to calculate SNR in dB, which a "unspec" would not allow. If
> the offset is constant (as specified above, but not the case for
> Atheros), you could compare different value over time and make a
> difference in dB.
In Atheros' case we want to use dbm as we also know the noise, so we
can just work with signal. Is there hardware where we might have SNR
but not noise?
> Clearly, you have to think hard and define is the reference is
> fixed (as stated above) or variable (Atheros). The fixed reference
> could be more useful to apps, but I don't know how many HW would fit
> that definition. The variable reference would accomodate the Atheros
> nicely.
> Also, with respect to "sort of calibrated" device, you would
> have to device if they are dBm or dB. What is the accuracy you expect.
>
> And of course, the main question to ask is, is this extra
> functionality worth the additional complexity of the API, and the
> potential confusion to users. I don't know, but for WE the answer was
> no.
Its a good point but for those who want precise results and if we
*can* provide better and more accurate results I don't see why not.
Ultimately I'd like to see RCPI embraced but we have to yet see
hardware who can fit its definition on accuracy.
<-- snip -->
> > > + * @IEEE80211_HW_SIGNAL_DBM:
> > > + * Hardware gives signal values in dBm, decibel difference from
> > > + * one milliwatt. This is the preferred method since it is
> standardized
> > > + * between different devices.
> > > + *
> > > + * @IEEE80211_HW_NOISE_DBM:
> > > + * Hardware can provide noise floor values in units dBm, decibel
> difference
> > > + * from one milliwatt.
>
> Noise only defined in dBm ? Some older devices have noise in
> "unspec". I also don't know what Atheros does here.
We don't have documentation for this but we can see what was *done* on
MadWifi. On MadWifi the noise is obtained during interrupts on
incoming set of frames and this is saved on a variable. This noise is
is subtracted from the SNR (rssi) to get the signal. I guess this
assumes that if there is a static noise during SIFs then you should
subtract that noise as well. I cannot say we have measured this
method's accuracy but hope its better than assuming a static noise as
its what we use in ath5k as well.
<-- snip -->
> > I'm pretty perplexed by the original intention of Wireless Extensions
> > max_qual. The documentation we have for this states:
> >
> > /* Quality of link & SNR stuff */
> > /* Quality range (link, level, noise)
> > * If the quality is absolute, it will be in the range [0 ;
> max_qual],
> > * if the quality is dBm, it will be in the range [max_qual ; 0].
> > * Don't forget that we use 8 bit arithmetics... */
> > struct iw_quality max_qual; /* Quality of the link */
> >
> > max_qual is a struct though, iw_quality which is:
> >
> > /*
> > * Quality of the link
> > */
> > struct iw_quality
> > {
> > __u8 qual; /* link quality (%retries, SNR,
> > %missed beacons or better...) */
> > __u8 level; /* signal level (dBm) */
> > __u8 noise; /* noise level (dBm) */
> > __u8 updated; /* Flags to know if updated */
> > };
> >
> > Jean, if range->max_qual.level is set to -110 does this mean signal
> > level can be set only from -110 up to 0 ? Is max_qual.level supposed
> > to be the weakest signal possibly detected?
>
> Yes. This is what make most sense.
How so? I think I must still be seriously misunderstanding something
then. If the weakest signal possibly detected is -110 dbm it does not
imply the strongest signal will be 0 dbm. On the contrary, I expect to
be able to receive frames with positive dbm values. For example, if I
hook up a card's antenna which is transmitting at 20dbm to another
card's antenna directly with cables with 10 dbm attenuator in the
middle I expect to see 10 dbm on the reception side. Therefore
shouldn't the max be close the max allowed, or at least expected,
EIRP?
> Remember we also have "avg_qual".
> The idea is that if we want to graphically represent the value
> on a graph, we need to know the bounds. Think about a
> thermometer. Most thermometers show a range of temperature from -20C
> to +100C.
> Usually, level and noise will have the same range [-110;0],
I expect noise to have the range [minimal possibly detected signal
---- max expected EIRP ]
The same applies to signal, which you seem to have labeled as "level".
Again, I think I'm probably just really not understanding this so
please clarify a bit more.
> and qual will have its own range [0-100] or whatever.
Sure, we use qual as a percentage of the best signal right now. This
is driver dependent; for Atheros hardware, for example, we assume a
max rssi value of 64.
> > Also, technically the noise should change depending on the channel
> bandwidth.
> >
> > IEEE-802.11 Channel bandwidth
> > 802.11a 20MHz
> > 802.11b 22MHz
> > 802.11g 20MHz (except when operating in 802.11b rates)
> > 802.11n 20MHz, 40MHz (except when operating in 802.11b rates)
> >
> > Applying the noise power formula:
> >
> > Pn = kTB
> >
> > where:
> >
> > k is Boltzmann's constant, 1.38*10^-23 J/K
> > T is the temperature in Kelvin (room temperature, 290 K)
> > B is the system bandwidth, in Hz
> >
> > Note: Watt = J/s
> >
> > For a 1 Hz bandwidth and at 290 K:
> >
> > Pn = 1.38 * 10-23 J/K * 290 K * 1 Hz
> > Pn = 4.00200 * 10^-21 JHz
> > Pn = 4.00200 * 10^-21 J/s
> > Pn = 4.00200 * 10^-21 W
> > Pn = 4.00200 × 10-18 mW
> >
> > To convert to Bell, we do log (foo), to deciBell we do 10 * log (foo)
> > so: (dBm == dBmW)
> >
> > Pn = 10 * log (4.00200 * 10^-18) dBm
> > Pn = ~-173.97722915699807401277 dBm
> > Pn = ~-174 dBm
> >
> > Now applying the same noise power formula, Pn = kTB, and knowing
> > already -174dBm applies for each 1 Hz we can compute the power noise
> > for each differing bandwidth for 802.11:
> >
> > Pn = -174 dBm / Hz + 10 * log (Bandwidth)
> >
> > [EMAIL PROTECTED]:~$ calc
> > C-style arbitrary precision calculator (version 2.12.1.13)
> > Calc is open software. For license details type: help copyright
> > [Type "exit" to exit, or "help" for help.]
> >
> >
> > ; -174 + (10 * log(20 * 10^6))
> > ~-100.98970004336018804794
> > ; -174 + (10 * log(22 * 10^6))
> > ~-100.57577319177793764041
> > ; -174 + (10 * log(40 * 10^6))
> > ~-97.97940008672037609579
> >
> > So I don't see why noise power should be -110, instead how about
> > having it set to -101 dBm for 20 MHz and 22 MHz channel bandwidth and
> > -98 dBm for 40 MHz channel bandwidth when used? If we want to be even
> > more exact we can take into consideration the noise from the amplifier
> > chain for the hardware when known; for example for Atheros it seems to
> > be known to be 5dBm [1] so the noise for Atheros hardware should
> > change to -96 dBm.
>
> Remember, what we care most here is to give a range so that
> graphical applications know the bound of the value. We don't need to
> be absolutely accurate here. Think about the thermometer example.
Point taken. In that case representation-wise we should take the
lowest number for the lowest possible value. For 802.11 though it
seems the lowest value should be -101 (20 MHz bandwidth) as I
illustrated but some funky hardware (Atheros) allows even for 5 MHz
channel widths so because of that this comes down to 107:
; -174 + (10 * log(5 * 10^6))
~-107.01029995663981195219
For 1MHz we get a clean -114:
; -174 + (10 * log(1 * 10^6))
-114
Whatever, I guess -110 or -114 is OK then :) I see your point though.
> Now, what you are talking is the channel noise. Receiver noise
> is different, as the receiver chain adds its own noise. Then, if you
> use DS (1 MB/s) or other complex modulation, you can have a processing
> gain which lower the noise floor. When I looked at the Orinoco at
> 1Mb/s, I believe the -110 dBm was correct, but I may have got it
> wrong.
> I think it would be wise to use a value that change as little
> as possible, so that the various applications can cache it (well, they
> will do it anyway).
> But yeah, please use whatever value make sense and give good
> result in userspace applications.
Sure.
Luis
_______________________________________________
ath5k-devel mailing list
[email protected]
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
