On Fri, Mar 7, 2008 at 3:57 AM, bruno randolf <bruno@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
