Norik Dzhandzhapanyan writes:
> 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
> to minimize the impact on
Adrian Chadd writes:
> I have something local that I've been meaning to push up to do this,
> but with no smoothing. Ideally (!) smoothing is done optionally in
> mac80211.
>
> What do you think about just committing the per-chain RSSI stuff to
> mac80211 so it shows up right
Norik Dzhandzhapanyan writes:
> 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
>
onal environment (cable) compared
to the 3 dimensional environment (air).
BR
Matthias
>>
>> From: Ben Greear
>> Sent: Saturday, May 27, 2:38 PM
>> Subject: Re: [PATCH] Per chain RSSI reporting
>> To: Norik Dzhandzhapanyan, Adrian Chadd
>> Cc: ath10k@lists.infr
Thanks Michael for the explanation. It makes complete sense.
Does the same concern then also apply to the existing functionality of the
driver's assignment of the combined rssi to the status->signal variable?
The submitted patch breaks nothing in the driver and adds the per chain feature
What I'm referring to is the real world case of an access point communicating
with multiple stations.
Take for example. an AP that has four stations attached to it with different
average RSSIs:
- Station 1: -45
- Station 2: -70
- Station 3: -50
- Station 4: -30
Now for argument's sake let
measuring on a single chain, or on all of the chains at once and adding
the power?
I think we would need more detailed reporting using a good third-party device
before
smoothing and RSSI.
Thanks,
Ben
From: Ben Greear
Sent: Saturday, May 27, 2:38 PM
Subject: Re: [PATCH] Per chain RSSI reporting
On 05/27/2017 12:25 PM, Norik Dzhandzhapanyan wrote:
We see this inconsistent/incorrect reporting in our RF chamber.
How different are the values, and did you sniff with a third-party device
to see if it sees the same spikes in RSSI?
Thanks,
Ben
Norik
On 05/27/2017 09:39 AM, Adrian Chadd
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
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
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 wrote:
>
> On 27 May 2017 at 09:07, Ben Greear wrote:
>> At low
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 stronger?
>
> Have you verified in some other manner than the signals reported by ath10k
> are
> wrong?
Hiya,
So
iday, May 26, 2017 6:12 PM
To: Norik Dzhandzhapanyan
Cc: ath10k@lists.infradead.org; linux-wirel...@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 (!) smoothing is don
<adrian.ch...@gmail.com> on behalf of Adrian Chadd
<adr...@freebsd.org>
Sent: Friday, May 26, 2017 6:12 PM
To: Norik Dzhandzhapanyan
Cc: ath10k@lists.infradead.org; linux-wirel...@vger.kernel.org
Subject: Re: [PATCH] Per chain RSSI reporting
[snip]
hiya,
I have something local that I've b
eebsd.org>
Sent: Friday, May 26, 2017 6:12 PM
To: Norik Dzhandzhapanyan
Cc: ath10k@lists.infradead.org; linux-wirel...@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 (
[snip]
hiya,
I have something local that I've been meaning to push up to do this,
but with no smoothing. Ideally (!) smoothing is done optionally in
mac80211.
What do you think about just committing the per-chain RSSI stuff to
mac80211 so it shows up right now, and then we figure out how to
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
18 matches
Mail list logo