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
On 05/27/2017 02:41 PM, Norik Dzhandzhapanyan wrote:
Yes ~6dB
If a packet is sent on 1 chain with ath10k firmware (9880 hardware,
specifically, but probably
others as well), it will be around 6db higher on that particular chain
than if the rate-control sends it on all three chains.
Are you
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
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?
Thanks,
Ben
On 05/26/2017 07:09 PM, Norik Dzhandzhapanyan wrote:
Hi Adrian,
I've been looking at this more and I believe that smoothing/filtering anywhere
other than as close as possible to where the ppdu gets unpacked will have the
disadvantage of being negatively influenced by 'out of band' values since the
average is not computed or averaged in the upper layers
11 matches
Mail list logo