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 reflectors. Yet, I don't think it does matter to capture CSI and estimate true phase. My attempts are based on a couple of papers which have done estimating true phase and AoA of a signal with uniform linear antenna array (ULA) in a realistic and practical living environment [1, 2, 3]. Which means, those papers claim that they can identify directpath component and multipath components with MUSIC algorithm [4]. One suspicious thing is, I think distance between antennas of ULA is misconfigured. I placed them 6.5 cm apart from each other. With calculation, a half of wavelength at 2.4 GHz band is less than 6.25 cm. Does it matter a lot? Regards, Jeon. [1]: K. Qian, C. Wu, Z. Yang, Y. Liu, and Z. Zhou, “PADS: Passive detection of moving targets with dynamic speed using PHY layer information,” in 2014 20th IEEE International Conference on Parallel and Distributed Systems (ICPADS), 2014, pp. 1–8. [2]: J. Xiong and K. Jamieson, “ArrayTrack: A Fine-Grained Indoor Location System,” in Presented as part of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13), Lombard, IL, 2013, pp. 71–84. [3]: M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, “SpotFi: Decimeter Level Localization Using WiFi,” SIGCOMM Comput. Commun. Rev., vol. 45, no. 4, pp. 269–282, Aug. 2015. [4]: R. Schmidt, “Multiple emitter location and signal parameter estimation,” IEEE Transactions on Antennas and Propagation, vol. 34, no. 3, pp. 276–280, Mar. 1986. 2016-06-14 3:28 GMT+09:00 Joe Ayers : > Jeon, > > "only constant offset across subcarrier seems to be effective".Could > this be because there's not just one signal being received anymore, rather > with microwaves, particularly with lots of nearby reflection surfaces, > there's now ~10 signals bouncing in to the receive antenna at 10 > AoA's--some with 2x the distance-delay traveled--and resonance/nulls > occurring? How perfect is your test environment? > > Joe AE6XE > > On Mon, Jun 13, 2016 at 10:00 AM, Jeon wrote: > >> 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 and time delay. >> i.e., measured_phase = true_phase + time_delay * subcarrier_index + >> phase_offset_due_to_txrx_mismatch >> This equation can be visualized as below: >> >> http://i.imgur.com/rk9Hh1M.png >> >> (Please note that this figure is based on CSI tool for Intel 5300 NIC.) >> >> It contains unwanted linear phase offset and constant phase offset. Since >> the true phase is relatively small, it seems that phase is monotonically >> increasing or decreasing in macro view due to the unwanted phase offsets. >> We cannot see a tiny true phase currently. >> >> To remove phase offset due to subcarrier, the mentioned papers are >> attempting to remove it with linear fitting ax + b, >> where a = slope of the figure, b = average of measured phase, and x = >> subcarrier index. >> >> After removing unwanted phase offset components, the true phase is >> estimated. >> This estimated true phase seems steady and consistent across a time >> duration shorter than < 100 - 1000 ms: >> >> http://i.imgur.com/AO89vYV.png >> >> Note that Y-axis scale is reduece from [-50, 10] to [5, -3] >> >> - My question >> >> I want to extract and manipulate CSI phase WITH ATH9K NIC. >> >> After extracting CSI from my ath9k NIC (AR9580 @ 2.4 GHz) with Atheros >> CSI extraction tool, >> I've tried various fitting methods to eliminate unwanted components and >> stacked results from nearly 100 packets: >> >> http://i.imgur.com/5r9eYwO.png >> >> From the result, in short, removing only constant offset across >> subcarrier seems to be effective. But I'm not sure. >> And sometimes, some phase measurement show large dispalcement along >> y-axis even they are captured within very short duration. >> >> Hence the question is, >> Is ath9k reports CSI with those unwanted linear phase offset removed? >> If it is not, should I look into Atheros CSI tool? As I look into it, it >> just captures CSI from the kernel and does not modify it. >> Or, Is CSI of Atheros different form that of Intel? I don't think so... >> >> The final goal of extracting true phase from CSI of ath9k is to determine >> angle of arrival (AoA) of signal. >> >> Regards, >> Jeon. >> >> [1]: http://pdcc.ntu.edu.sg/wands/Atheros/ "Atheros CSI Extraction Tool" >> [2] K. Qian, C. Wu, Z. Yang, Y. Liu, and Z. Zhou, “PADS: Passive >> detection of moving targets with dynamic speed using PHY layer >> information,” in 20
[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 and time delay. i.e., measured_phase = true_phase + time_delay * subcarrier_index + phase_offset_due_to_txrx_mismatch This equation can be visualized as below: http://i.imgur.com/rk9Hh1M.png (Please note that this figure is based on CSI tool for Intel 5300 NIC.) It contains unwanted linear phase offset and constant phase offset. Since the true phase is relatively small, it seems that phase is monotonically increasing or decreasing in macro view due to the unwanted phase offsets. We cannot see a tiny true phase currently. To remove phase offset due to subcarrier, the mentioned papers are attempting to remove it with linear fitting ax + b, where a = slope of the figure, b = average of measured phase, and x = subcarrier index. After removing unwanted phase offset components, the true phase is estimated. This estimated true phase seems steady and consistent across a time duration shorter than < 100 - 1000 ms: http://i.imgur.com/AO89vYV.png Note that Y-axis scale is reduece from [-50, 10] to [5, -3] - My question I want to extract and manipulate CSI phase WITH ATH9K NIC. After extracting CSI from my ath9k NIC (AR9580 @ 2.4 GHz) with Atheros CSI extraction tool, I've tried various fitting methods to eliminate unwanted components and stacked results from nearly 100 packets: http://i.imgur.com/5r9eYwO.png >From the result, in short, removing only constant offset across subcarrier seems to be effective. But I'm not sure. And sometimes, some phase measurement show large dispalcement along y-axis even they are captured within very short duration. Hence the question is, Is ath9k reports CSI with those unwanted linear phase offset removed? If it is not, should I look into Atheros CSI tool? As I look into it, it just captures CSI from the kernel and does not modify it. Or, Is CSI of Atheros different form that of Intel? I don't think so... The final goal of extracting true phase from CSI of ath9k is to determine angle of arrival (AoA) of signal. Regards, Jeon. [1]: http://pdcc.ntu.edu.sg/wands/Atheros/ "Atheros CSI Extraction Tool" [2] K. Qian, C. Wu, Z. Yang, Y. Liu, and Z. Zhou, “PADS: Passive detection of moving targets with dynamic speed using PHY layer information,” in 2014 20th IEEE International Conference on Parallel and Distributed Systems (ICPADS), 2014, pp. 1–8. [3] M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, “SpotFi: Decimeter Level Localization Using WiFi,” SIGCOMM Comput. Commun. Rev., vol. 45, no. 4, pp. 269–282, Aug. 2015. [4] http://dhalperi.github.io/linux-80211n-csitool/ "Linux 802.11n CSI Tool" ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[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 https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit
On 7 June 2016 at 13: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? >> >> Well in my case I'm sidestepping this by getting the TX duration from >> a register in the hardware. There seems to be registers containing the >> duration spent on each step in the retry chain; I simply sum these. > > Ah, but you're still talking RX? Hmm, I'm using ath_pkt_duration() to > compute the RX time, which does take into account MIMO (I think) but > expects the size to include padding. Which is probably not included in > the rs_datalen field of struct ath_rx_status that I'm using. > > So yeah, how to account for that? > > 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 > difficult; by the time the frame is handled in the rx tasklet, way too > much time has been spent on interrupt handling etc for the current time > to be worth comparing with. I think rs_tstamp in rx-status is different for first MPDU and last MPDU in an A-MPDU meaning you should be able to compute the entire duration (if you track it, and this should be fairly straightforward as you can't really rx interleaved MPDUs from different A-MPDUs/stations). I'm not sure if the last MPDU defines the tstamp of first symbol or last one. Michał ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
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 >>> difficult; by the time the frame is handled in the rx tasklet, way too >>> much time has been spent on interrupt handling etc for the current time >>> to be worth comparing with. > > As an aside, I'm no longer sure this explanation for why I got wrong > timings for this way of measuring RX time is correct. It may simply be > that I was counting the same time interval more than once because I > didn't realise that the handler would be called for each frame. See > below. > >> I think rs_tstamp in rx-status is different for first MPDU and last >> MPDU in an A-MPDU meaning you should be able to compute the entire >> duration (if you track it, and this should be fairly straightforward >> as you can't really rx interleaved MPDUs from different >> A-MPDUs/stations). I'm not sure if the last MPDU defines the tstamp of >> first symbol or last one. > > I actually went down this path again last night, but haven't had a > chance to test it yet. > > So what I have now is this: > >/* Only count airtime for last frame in an aggregate. FIXME: Should > * this be only the first frame? */ >if (!rs->rs_isaggr || !rs->rs_moreaggr) >airtime = (tsf & 0x) - rs->rs_tstamp; > > Which was under the assumption that rs_tstamp will be the time of the > first symbol *of the whole ampdu* for all the frames in that aggregate. > However, if rs_tstamp differs between frames, tracking it at the first > frame might be the right things to do? 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. Non A-MPDU obviously are special case (status bits are pricky). > Is the entire A-MPDU received before the RX handler is called for the > first frame? No idea. Maybe it is as there's distinction between "more" and "moreaggr". Michał ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
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 TX FIFO entry. Ie, if you queue 8 separate TX FIFO entries, > each with a single MPDU, then you end up only getting one frame per > burst window. > So it looks like it's not specifically TXOP gating, but it's frame scheduling gating and chantime gating. I need to go see what's going on in more detail. Ie, if I have a TXOP burst with lockout and it's frame scheduling is beacon gated (eg, like CAB queue is setup) then only one TX FIFO entry seems to get ungated, and then things stay locked out. If I'm pushing frames into the queue then things seem to get serviced, but if the queue is full then nothing extra gets serviced. -adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
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 left over at that point in the RX FIFO when it was last updated; it isn't an actual timestamp timestamp. The logic for populating the descriptor contents just takes stuff out of certain offsets in the RX FIFO, and sometimes that contains stale/wrong data. I'll go and double/triple check this (as well as where the TSF is actually stamped - I think it's actually stamped at the leading edge of a packet, but stamped at the /end/ of it.) -adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
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?". -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
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 Why we don't need that 1.5 ms delta anymore? It would be good to document that in the commit log in case someone else wonders why that change was made. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
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. Non A-MPDU obviously are special case >> (status bits are pricky). > > Right. So comparing the rs_stamp between first and last MPDU should give > the duration of the entire thing? Depends on how you define your "thing" :) I no, I don't know what you'll actually measure. It should be reasonable either way. > This would require keeping state > between subsequent calls to the RX handler. Also, what happens if the > last MPDU is lost? No idea. If that's possible, then track last MPDU within PPDU, so you can at least fallback to _something_ when you detect a new first (A-)MPDU? Or maybe it's impossible (i.e. not worth worrying) and HW always reports last MPDU as far as status bits are concerned (regardless of it being _actual_ last MPDU, i.e. it just says "ok, I'm done with this PPDU"). >>> Is the entire A-MPDU received before the RX handler is called for the >>> first frame? >> >> No idea. Maybe it is as there's distinction between "more" and >> "moreaggr". > > Hmm. If it is, comparing the stamp of the first MPDU to the current time > (when handling it) should give the needed duration? Will try doing that > and see what the result is. I'd say it's a little racy/inaccurate (and perhaps unreliable) to compare any kind of global timer and compare it against your rx-status descriptors. Michał ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
