Re: [ath9k-devel] linearity of ath9k CSI phase

Dear Joe Ayers, Thank you for response. I don't have a sort of RF anechoic chamber. So, I've captured CSI in a quite realistic and practical environemnt with possible interference and multipath components. There are other WLAN APs, Bluetooth devices. Also, there exist desks, chairs and walls as

[ath9k-devel] linearity of ath9k CSI phase

Dear ath9k developers, I am currently working with Atheros CSI Extraction Tool [1] to get a true phase of each subcarrier. - Background [2], [3] and many other papers claim that phase information from extracted CSI contains two components: true phase and unwanted phase offset due to subcarrier

[ath9k-devel] Spectral Scan on extended channel

Hi, In 20/40 mode if there is a transmission on extended channel while primary channel is idle. Using only the data given in the struct of spectral scan. How can we determine it. Regards, Kamran ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org

Re: [ath9k-devel] [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

On 10 June 2016 at 10:53, Toke Høiland-Jørgensen wrote: > >>> I initially thought that using the timestamp put into the frame by the >>> hardware could be a way to get timing. But there's only a timestamp of >>> the first symbol in rs_tstamp, and getting a time to compare it with is

Re: [ath9k-devel] ath9k EDMA behaviour with TXOP?

On 9 June 2016 at 19:56, Adrian Chadd wrote: > hi, > > I've noticed something reasonably quirky with the AR9380 and later > EDMA engine and I'd like to see if anyone else has seen it with ath9k. > > It /looks/ like the TXOP gating for burstTime (ie, WMM bursts) is > gated by a

Re: [ath9k-devel] [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

[picking a random email to reply to] I /think/ the TSF is only valid for the last frame of an aggregate. 'more' means "this RX frame is split across multiple RX descriptors" "moreaggr" means "there's more subframes in this RX'ed A-MPDU" If you get a TSF in the first frame, it's whatever was

Re: [ath9k-devel] [PATCH 4/6] ath9k: Expose tsf_adjustment in mac80211 tsf getters and setters.

Benjamin Berg writes: > From: Benjamin Berg > > Signed-off-by: Benjamin Berg Why? Does this help with mesh or what? Remember that the most important part of the commit log is to answer the question "Why?".

Re: [ath9k-devel] [PATCH 3/6] ath9k: Use tsf offset helper in ath9k_hw_reset

Benjamin Berg writes: > From: Benjamin Berg > > Not much of a change. Only small fix is that we don't assume that > exactly 1.5ms have passed for the second AR91xx SoC TSF setting. > > Signed-off-by: Benjamin Berg

Re: [ath9k-devel] [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

On 10 June 2016 at 11:08, Toke Høiland-Jørgensen wrote: > Michal Kazior writes: > >> For A-MPDU all MPDU rx status (except last one) should share the same >> timestamp. Last one has a different one so all you need is to >> distinguish first and last MPDU.

Re: [ath9k-devel] [PATCH 2/6] ath9k: Handle channel context in get_/set_/reset_tsf

Benjamin Berg writes: > From: Benjamin Berg > > Signed-off-by: Benjamin Berg Please avoid empty commit logs, it's just unfriendly to everyone. It doesn't take long for you to answer "Why?" in the log. --

Re: [ath9k-devel] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

On 7 June 2016 at 04:12, Toke Høiland-Jørgensen wrote: > Toke Høiland-Jørgensen writes: > >>> [snip] >>> >>> I also found one of my notes in my version of this - how can we >>> estimate the duration of an A-MPDU, when we only get hardware >>> de-encapsulated frames?