On Wed, Mar 26, 2008 at 8:19 PM, Jean Tourrilhes <jt@xxxxxxxxxx> 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. AlsoI'm not blaming anyone for anything, I just wanted to ask you somedetails of intentions behind a value used in WE so we can betterimplement 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. Thevalue 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) parametershall be an 8 bit value in the range from 0 through 220, with indicatedvalues rounded to the nearest 0.5 dB as follows:
0: Power < -110 dBm1: Power = -109.5 dBm2: Power = -109.0 dBm
and so on where
RCPI = int{(Power in dBm +110)*2} for 0dbm > Power > -110dBm
220: Power > -0 dBm221-254: reserved255: 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 thereceiver. The received RF power shall be determined assuming a receivernoise equivalent bandwidth equal to the channel bandwidth multiplied by1.1."
But as discussed already on the lists the problem with RCPI will begetting hardware to support it and its accuracy. In terms accuracy forRCPI you need to support "received RF power in the selected channelfor a received frame. This parameter shall be a measure by the PHYsublayer of the received RF power in the channel measured over theentire received frame or by other equivalent means which meet thespecified accuracy". I don't believe we have hardware that can fitthis definition yet. Atheros' rssi value is measured during the theinitial 4us of detection, during the preamble and PLCP, not sure ifthis fits the definition on the "or" clause ("or by other equivalentmeans which meet the specified accuracy"). I also wish and wonder ifwe 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 strengthmeasurements? At least for Atheros AR5212 hardware there seems to bean offset value between the actual signal strength and the measuredsignal stregth. At Orbit we use a lot of Atheros hardware (800wireless cards on the grid) and at one point it seems there was a bigconcern over the value of signal strength reported and how it differedamongst cards compared to a real controlled value. I just tried togather together a bit of the experience so far and it seems that ingeneral the offset was small and didn't vary too much. So actually,unless I am misrepresenting the experience explained so far Atheroshardware seems provide reliable results, across different experiments,across different cards. An offset exists but it seems to benegligible. If you want to be surgically precise you do have toaccount 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 calibratedunder 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 doubtits by a lot. How much have you seen the offset change over time? I donot 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 wecan just work with signal. Is there hardware where we might have SNRbut 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 seehardware 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* onMadWifi. On MadWifi the noise is obtained during interrupts onincoming set of frames and this is saved on a variable. This noise isis subtracted from the SNR (rssi) to get the signal. I guess thisassumes that if there is a static noise during SIFs then you shouldsubtract that noise as well. I cannot say we have measured thismethod's accuracy but hope its better than assuming a static noise asits 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 somethingthen. If the weakest signal possibly detected is -110 dbm it does notimply the strongest signal will be 0 dbm. On the contrary, I expect tobe able to receive frames with positive dbm values. For example, if Ihook up a card's antenna which is transmitting at 20dbm to anothercard's antenna directly with cables with 10 dbm attenuator in themiddle I expect to see 10 dbm on the reception side. Thereforeshouldn'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 soplease 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. Thisis driver dependent; for Atheros hardware, for example, we assume amax 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)> >> > mcgrof@monster:~$ 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 thelowest number for the lowest possible value. For 802.11 though itseems the lowest value should be -101 (20 MHz bandwidth) as Iillustrated but some funky hardware (Atheros) allows even for 5 MHzchannel 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��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
