Re: [PATCH] Per chain RSSI reporting

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

[PATCH v2] mac80211: Invoke TX LED in more code paths

ieee80211_tx_status() is only one of the possible ways a driver can report a handled packet, some drivers call this for every packet while others calls it rarely or never. In order to invoke the TX LED in the non-status reporting cases this patch pushes the call to ieee80211_led_tx() into

Re: [PATCH] Per chain RSSI reporting

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

Re: [PATCH] Per chain RSSI reporting

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

Re: [PATCH] Per chain RSSI reporting

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

Re: [PATCH] Per chain RSSI reporting

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

Re: [PATCH] Per chain RSSI reporting

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,

Re: BCM4350 not working properly under Debian 9 RC3, Dell XPS 13 9350

+ linux-wireless On 27-05-17 11:33, Graziano D'Innocenzo wrote: > Hello, > > I found this email address on: > https://wireless.wiki.kernel.org/en/users/Drivers/brcm80211 > > We have a laptop "Dell XPS 13 9350" and we have been unable to make > its wireless work properly: signal is extremely

Re: [PATCH] Per chain RSSI reporting

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