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

[bruno randolf <bruno@thinktube.com>]

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...

ok. what about 3 hw flags then?

something like:
_SIGNAL_RSSI_UNITLESS
_SIGNAL_RSSI_DBM
_SIGNAL_RCPI

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.

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 :)

bruno