Re: [RFC] RCPI support in radiotap and in our wireless subsystems

On Fri, Mar 7, 2008 at 3:57 AM, bruno randolf <[email protected]> wrote:
> On Friday 07 March 2008 12:04:24 Luis R. Rodriguez wrote:
>  > >  it could be changed to something like:
>  > >
>  > >   * @signal: signal strength in dBm above noise or RCPI according to flag
>  >
>  > As it stands I don't think all drivers could populate this field under
>  > that description. For example, ssi in b43 is set to some magical value
>  > we have no clue what it means.
>  >
>  > We *could* test this stuff and see if it matches RCPI for each device,
>  > or just try to figure out at least what RSSI is wrt to the observed
>  > signal through a spectrum analyser (and even jssi is for b43) but I
>  > wonder how this will change upon hw revisions.
>  >
>  > >   * @noise: PHY noise in dBm when receiving this frame
>  > >   (remove ssi)
>  >
>  > Again, the problem in clarifying this also puts a restriction on what
>  > driver developers may know about their hardware.
>
>  yes, but you suggested RCPI which is even more difficult to deliver. well - i
>  don't know *any* device which could...

Well I was hoping we could see if we *could* deliver it, at least
within Atheros hardware but from what you tell me we can't. And from
what I gather from a few other wireless cards we can't either. The
idea was to propose it for radiotap but I do think its pointless if we
don't have hardware yet which we can produce those results.

>  ok. what about 3 hw flags then?
>
>  something like:
>  _SIGNAL_RSSI_UNITLESS
>  _SIGNAL_RSSI_DBM
>  _SIGNAL_RCPI

Seems reasonable.

>  so mac80211 can fill in the right radiotap headers, and drivers can make it
>  clear what they support. it's clear that drivers should strive to deliver the
>  most exact when they can.

Sounds good!

So having IEEE80211_RADIOTAP_DBM_ANTSIGNAL is preferable than
IEEE80211_RADIOTAP_DB_ANTSIGNAL in drivers, for obvious reasons. I'll
deal with another question with respect to mac80211 in another e-mail.

>  we have the same problem with the rx timestamp. we made a definition and ath5k
>  for example can't deliver. but i think a clear definition and a clear note
>  where it cannot be delivered is better than no definition at all :)

Sure, we have to take into consideration what other drivers can deliver as well.

  Luis