Report per chain RSSI
Signed-off-by: Norik Dzhandzhapanyan <nor...@gmail.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 6c0a82
ore the moving average
RSSI data for that peer. This becomes extremely bulky memory-wise.
Alternatively, it could be implemented such that it only applies to managed
mode and only when the peer identified is the currently connected BSSID.
On May 27, 2017, at 3:30 PM, Norik Dzhandzhapanyan &
Is there an enhanced or conflicting patch pending?
On 05/27/2017 10:56 AM, Michael Ney wrote:
The submitted code also doesn't appear to handle RSSI per-peer which would be
needed for any use when configured as an access point.
On May 27, 2017, at 12:39 PM, Adrian Chadd
We see this inconsistent/incorrect reporting in our RF chamber.
Norik
On 05/27/2017 09:39 AM, Adrian Chadd wrote:
On 27 May 2017 at 09:07, Ben Greear wrote:
At low encoding rates, especially if it switches to a single-chain encoding,
maybe the on-air signal really is
up
Norik
On 05/26/2017 07:09 PM, Norik Dzhandzhapanyan wrote:
Hi Adrian,
Inserting the smoothing function here is motivated by what we see as 'spikes'
in rssi data under weak rssi conditions. Figured its best to get rid of the
'bogus' data as close to the source as possible. Also t
eebsd.org>
Sent: Friday, May 26, 2017 6:12 PM
To: Norik Dzhandzhapanyan
Cc: ath...@lists.infradead.org; linux-wireless@vger.kernel.org
Subject: Re: [PATCH] Per chain RSSI reporting
[snip]
hiya,
I have something local that I've been meaning to push up to do this,
but with no smoothing. Ideally (
Add support for per chain RSSI reporting w/smoothing.
Signed-off-by: Norik Dzhandzhapanyan nor...@ethertronics.com
--- htt_rx.c.orig 2017-05-26 15:26:37.918504255 -0700
+++ htt_rx.c2017-05-26 12:10:33.139809025 -0700
@@ -825,14 +825,71 @@ static bool ath10k_htt_rx_h_channel(stru