"Overall" and per-chain signal/noise values (was Re: multi-antenna handling)
Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/[email protected]> Sun, 30 Dec 2018 13:47:35 -0800
| Newsgroups | org.netbsd.radiotap |
|---|---|
| Message-ID | <[email protected]> |
On Jun 25, 2014, at 11:20 PM, Johannes Berg <[email protected]> wrote: > We actually have one per-chain value, and one "overall" value, the > latter is what we report in the first radiotap namespace, the per-chain > ones in the latter namespaces that only have the signal and antenna > value (but obviously we could add anything else that made sense per > antenna) > > Maybe we shouldn't be reporting the "overall" value? The calculation of > that seems to be driver dependent, our (the Intel) driver just takes the > max. If ath9k has a more specific calculation then I can see how that's > a bit confusing but OTOH it actually reports what much else of the stack > used for further work. About 4 1/2 years later, the ath9k driver plus the mac80211 code appears to provide the "overall" strength plus per-antenna strengths, at least as of the 4.17.10 kernel, so I guess it's somewhat of a *de facto* standard that there's an "overall" value. Given that, this is probably worth documenting - but not requiring, in case some adapter+driver combination doesn't supply it. Presumably the description would be that: if you see a signal strength indication, and *don't* see an antenna number before the end of the header or a Radiotap Namespace field, it's an "overall" value; otherwise, it's a per-antenna value for the specified antenna. Parsers must not assume that there will or won't be an "overall" value if there are per-antenna values. The "overall" value for a multi-antenna receiver could be described as device-dependent, which might suggest that, unless you know the device, you shouldn't try to interpret it.