Re: [ath9k-devel] CSI support
actually, how is this CSI information different from the spectral scan feature in the ar92xx chipset?? On 26/06/13 02:04, Ali Abedi wrote: Hello everyone, I am also interested in accessing CSI. Please update us as soon as you got some good news. Best, Ali On 13-04-02 08:18 AM, Nikolay Makarov wrote: Dear Andres, Adrian preliminary confirmed it is possible to get CSI out of hardware. He helped me to send an internal request to Atheros to assist on the issue. We sent the request 30 of March. I am not clear what to do next and I am waiting directions from Adrian at the moment. I think that it might be helpful to send to Atheros another request from you. Best regards, Nikolay Makarov On Tue, Apr 2, 2013 at 1:52 PM, Andrés García Saavedra agsaa...@it.uc3m.es mailto:agsaa...@it.uc3m.es wrote: Hi Adrian, Nikolay, any luck on this line? I am also interested in obtained CSI information from hw for research purposes. Thanks! Andrés On Sun, Mar 10, 2013 at 10:43 AM, Nikolay Makarov opnmaka...@gmail.com mailto:opnmaka...@gmail.com wrote: Thank you very much Adrian. I would appreciate your help. ? ?, ??? ??? +7 (926) 284 80 81 tel:%2B7%20%28926%29%20284%2080%2081 On 10.03.2013, at 10:21, Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org wrote: On 8 March 2013 23:16, Nikolay Makarov nmaka...@live.ru mailto:nmaka...@live.ru wrote: Sorry. My bad. The CSI (channel state information) is similar to RSSI which describes the power of received signal. But unlike RSSI, CSI is energy over multiple subcarriers. In 802.11 g/n, there are 64 subcarriers. So CSI is a vector with 64 elements, each is a complex value. At the physical layer of wifi, they will do channel estimation, CSI is the channel estimation results for every subcarrier. Oh, right. Yes. I think there's a way to get the CSI out of the hardware. I don't know any ETA for that though; sorry. I'll poke some people to see if I can get some documentation about how to get CSI values and how to interpret them. Thanks, Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org mailto:ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- ? ?, ??? ??? +7 926 284 80 81 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards; Peizhao ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Spectral Scan in ath9k
On 01/06/12 05:19, Adrian Chadd wrote: Argh, there's more to it.. :-) For AR9160 and later, you can enable the FFT bit in one of the radar registers and you'll get some FFT reports for longer radar pulses. It's enabled by default in the code that we've committed to ath9k and FreeBSD HAL. Spectral scan mode is related but different (and not in AR9160.) So for longer pulses, you'll get RADAR payload (phyerr code = 5) which may just have the pri/ext pulse duration and some config info, or it may have a series of FFT reports first. That's just for radar stuff though, it's not spectral scan. That's why he mentioned code = 5 or code = 38. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel Hi Adrian, To summarize what you saying if I have later chipset than AR9160 (e.g., AR9280/AR9285), then the FFT bit is enabled by default. So for longer pulses, you'll get RADAR payload (phyerr code = 5) which may just have the pri/ext pulse duration and some config info, or it may have a series of FFT reports first. That's just for radar stuff though, it's not spectral scan. Could you please explain what you mean by the radar stuff? So what is the spectral scan report? does anyone know? Is there anyone ready to start a documentation on this feature? -- Regards; Peizhao ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] More on signal and noise
Does this CMOS assumption apply to ath5k as well? I thought ath5k has noise recalibration which tune the noise floor accordingly (which seems to be true from our experiments). In madwifi the noise floor is fixed at -95 or -96, but the ath5k introduces the ani and noise recalibration. But the rs_rssi is SNR?? regards; Peizhao On 03/05/11 21:10, Alex Hacker wrote: On Mon, May 02, 2011 at 02:46:06PM -0700, Eduard GV wrote: Hi all, Just three questions. I need per-packet SNR information and my first guess was to inspect last_signal from debugfs. Values range from -30 to -60. last_signal file should contain signal (dBm) of last received frame (from sta_info.h), right? That explains values obtained. But... 1) This value is computed as signal=ATH_DEFAULT_NOISE_FLOOR + rx_stats-rs_rssi, which is confusing me. It would be explained if rs_rssi is actually SNR (not RSSI) measured in dB. Am I wrong? 2) Why is NOISE_FLOOR fixed to -95 (dBm?). Noise varies randomly, e.g. noise reported by iw survey dump vary from -91 to -101 dBm. 3) By the way, what do rs_rssi_ctlX and rs_rssi_extX (-1 X 3) measure? I'd spent some time trying to understand how these chips do the RSSI and noise measurements and attempt to shortly explain my vision of this process. Actually these chips unable to measure absolute signal level in dBm. This is because of amplifiers in radio are implemented in CMOS technology. Real gain of such gain stages are unpredictable and varies with temperature. Instead this CMOS technology gives a simple way to realize stable gain step independrnt from the temperature. So that Atheros chips can give as a valid SNR which is incorrectly called RSSI in descriptor status fields. The value of noise reported by iw survery is meaningless. This value obtained from a maximum gain set by free running AGC within short period of time and then substracted by baseband DSP from gain locked on packet's preamble. This process is described in much details in Atheros' patent US 7,245,893 B1. Very interesting document, should I say. I'm also impressed with 55 claims at the end. Now how the absolute RSSI is calculated in ath9k. Instead of using meaningless noisefloor it adds predefined value of -95 dBm to each SNR measured in baseband. I will try to guess how this value are calculated. The basic equation for calculating noise power at the antenna input is: Pn = k*T*F*B. Where: k - Boltzmann constant, T - input noise temperature, F - noise factor of the receiver and B - the bandwidth. The temperature variation is less then 1dB within working range 250..330K, so can be ignored. If we assume T = 300K, F = ~2 for LNAs used in Atheros reference boards, we got the following values: 166 fW = -98dBm in 20MHz bandwith and 331 fW = -95 dBm in 40 MHz bandwith. The value -95 programmed in ath9k is valid reference noise level for 40MHz, but for 20MHz it should be lowered by 3dB. This difference in measured RSSI can be easily shown in monitor mode observing signal level from 20MHz station. When monitor node is switched between HT20 and HT40 the RSSI will change by 3dB. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Progress on Ath9k HT support on Adhoc mode
Hi, I meant the number of actual antenna was used. I am not sure whether it has the same antenna setting in /sys/kernel/debug/ieee80211 like ath5k. regards; Peizhao On 15/02/11 19:10, Sagar Bijwe wrote: I would also like to know that... -Sagar On Tue, Feb 15, 2011 at 2:35 PM, Baldomero Coll baldo.at...@gmail.com mailto:baldo.at...@gmail.com wrote: Hello, Can you please tell me how do you select one o two antennas? I'm using a similar setting than you: Linux kernel: 2.6.32-28-generic-pae. Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the patch suggested by Alex. Radio card: Ubiquiti SR71x Thanks in advance, Baldomero Hi all, I would like to confirm my findings. My test platform configurations are follow. Board: pcengine alix3d2 Linux kernel: 2.6.35 from linux-wireless git Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the patch suggested by Alex. Radio card: Ubiqiti SR71a on channel 36 with HT40+ Measurement tool and settings: Iperf, UDP, 100Mb offered load Recored throughput: 50-54Mbps (one antenna); 78-80Mbps (two or three antennas). ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org mailto:ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Progress on Ath9k HT support on Adhoc mode
Hi Alex, I am testing the patch. I got the following dmesg message. I am using compat-wireless-2011-01-17.tar.bz2 and iw-0.9.21.tar.bz2 with both patches. The linux kernel is 2.6.35 from linux-wireless. [ 7549.786227] wlan0: No active IBSS STAs - trying to scan for other IBSS networks with same SSID (merge) [ 7549.925224] ath: cf559e20 [ 7549.928625] ath: cf559e48 [ 7549.944108] ath: cf559e04 [ 7550.073159] ath: cf559e20 [ 7550.077125] ath: cf559e48 [ 7550.092581] ath: cf559e04 [ 7550.277151] ath: cf559e20 [ 7550.281123] ath: cf559e48 [ 7550.296581] ath: cf559e04 [ 7550.369159] ath: cf559e20 [ 7550.373132] ath: cf559e48 [ 7550.388592] ath: cf559e04 [ 7550.461160] ath: cf559e20 [ 7550.465117] ath: cf559e48 [ 7550.480581] ath: cf559e04 [ 7550.553160] ath: cf559e20 [ 7550.557127] ath: cf559e48 [ 7550.572581] ath: cf559e04 [ 7550.701149] ath: cf559e20 [ 7550.705107] ath: cf559e48 [ 7550.720570] ath: cf559e04 [ 7550.793161] ath: cf559e20 [ 7550.797116] ath: cf559e48 [ 7550.812569] ath: cf559e04 [ 7550.885171] ath: cf559e20 [ 7550.889124] ath: cf559e48 [ 7550.904582] ath: cf559e04 regards; Peizhao On 19/01/11 23:42, Alexander Simon wrote: Hi there, i just want to let you know i just released my patch for this on linux- wireless. http://article.gmane.org/gmane.linux.kernel.wireless.general/63191 I really apreciate any tests/comments/proposals on this! Regards, Alex Am Mittwoch, 22. Dezember 2010, 09:25:39 schrieb Robert Chan: Hi All, May I ask whether the HT support (for Adhoc) is already in the trunk? Thanks. Regards, Robert ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Progress on Ath9k HT support on Adhoc mode
Hi Could anyone please tell me the progress on Ath9k HT support for adhoc mode? On the latest OpenWRT trunk build, I can only get 22Mbps throughput with 54Mbit/s rate. below are my setting for the AR9220 radio. config 'wifi-device' 'radio0' option 'type' 'mac80211' option 'macaddr' '00:0c:42:64:bf:70' option 'hwmode' '11na' option 'htmode' 'HT40-' list 'ht_capab' 'SHORT-GI-40' list 'ht_capab' 'TX-STBC' list 'ht_capab' 'RX-STBC1' list 'ht_capab' 'DSSS_CCK-40' option 'country' 'US' option 'channel' '44' option 'txpower' '1' config 'wifi-iface' option 'device' 'radio0' option 'ssid' 'ath9kTest2' option 'encryption' 'none' option 'network' 'wan' option 'mode' 'adhoc' -- regards; Peizhao ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k warning on AR9160 and AR9220 chipset with 2.6.36 kernel
Hi I am wondering whether this problem is due to the OpenWRT or an issue of the ATH9k. ---[ cut here ] WARNING: at /root/openwrt-svn-repo/routerStation/active_trunk/build_dir/linux-ar71xx_generic/compat-wireless-2010-11-20/drivers/net/wireless/ath/ath9k/recv.c:532 ath_stoprecv+0x90/0xa8 [ath9k]() Could not stop RX, we could be confusing the DMA engine when we start RX up Modules linked in: ath9k ath9k_common ath9k_hw mac80211 ath ohci_hcd ath_pci ath_hal(P) nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ehci_hcd ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables nfs loop lockd sunrpc usbcore nls_base crc_ccitt cfg80211 compat arc4 aes_generic deflate ecb cbc leds_gpio button_hotplug gpio_buttons input_polldev input_core [last unloaded: ath] Call Trace: [800696cc] dump_stack+0x8/0x34 [8007dedc] warn_slowpath_common+0x78/0xa4 [8007df90] warn_slowpath_fmt+0x2c/0x38 [82d075b0] ath_stoprecv+0x90/0xa8 [ath9k] [82d04138] ath_set_channel+0xa4/0x740 [ath9k] [82d0503c] ath_radio_enable+0x55c/0x680 [ath9k] [82f45414] ieee80211_scan_work+0x30c/0x524 [mac80211] [800910bc] process_one_work+0x2c0/0x460 [80091d88] worker_thread+0x240/0x434 [80096a3c] kthread+0x80/0x8c [8006dde4] kernel_thread_helper+0x10/0x18 ---[ end trace 5948ecf07cb92b59 ]--- [ cut here ] WARNING: at /root/openwrt-svn-repo/routerStationPro/trunk_23933/build_dir/linux-ar71xx_generic/compat-wireless-2010-11-20/drivers/net/wireless/ath/ath9k/recv.c:532 ath_stoprecv+0x90/0xa8 [ath9k]() Could not stop RX, we could be confusing the DMA engine when we start RX up Modules linked in: ath9k ath9k_common ath9k_hw mac80211 ath ohci_hcd ath_pci ath_hal(P) nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp xt_string xt_layer7 xt_quota xt_pkttype xt_owner ipt_MASQUERADE iptable_nat nf_nat xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ehci_hcd ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables nfs loop lockd sunrpc usbcore ts_fsm ts_bm ts_kmp nls_base cfg80211 compat arc4 aes_generic deflate ecb cbc leds_gpio button_hotplug gpio_buttons input_polldev input_core [last unloaded: ath] Call Trace: [800696cc] dump_stack+0x8/0x34 [8007df3c] warn_slowpath_common+0x78/0xa4 [8007dff0] warn_slowpath_fmt+0x2c/0x38 [869e75b0] ath_stoprecv+0x90/0xa8 [ath9k] [869e4138] ath_set_channel+0xa4/0x740 [ath9k] [869e503c] ath_radio_enable+0x55c/0x680 [ath9k] [87385414] ieee80211_scan_work+0x30c/0x524 [mac80211] [8009111c] process_one_work+0x2c0/0x460 [80091de8] worker_thread+0x240/0x434 [80096a9c] kthread+0x80/0x8c [8006dde4] kernel_thread_helper+0x10/0x18 ---[ end trace d0a293f7237f639f ]--- regards Peizhao ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k warning on AR9160 and AR9220 chipset with 2.6.36 kernel
Hi, The firmware was built using OpenWRT svn trunk 24136 that uses compat-wireless-2010-11-20 and 2.6.36.1 kernel. The warning message comes right after I configured the radio and bring it up in adhoc mode. regards, Peizhao On 25/11/10 15:05, Mohammed Shafi wrote: On Thu, Nov 25, 2010 at 9:27 AM, Peizhao Hupeiwo...@gmail.com wrote: Hi I am wondering whether this problem is due to the OpenWRT or an issue of the ATH9k. ---[ cut here ] WARNING: at /root/openwrt-svn-repo/routerStation/active_trunk/build_dir/linux-ar71xx_generic/compat-wireless-2010-11-20/drivers/net/wireless/ath/ath9k/recv.c:532 ath_stoprecv+0x90/0xa8 [ath9k]() Could not stop RX, we could be confusing the DMA engine when we start RX up Modules linked in: ath9k ath9k_common ath9k_hw mac80211 ath ohci_hcd ath_pci ath_hal(P) nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ehci_hcd ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables nfs loop lockd sunrpc usbcore nls_base crc_ccitt cfg80211 compat arc4 aes_generic deflate ecb cbc leds_gpio button_hotplug gpio_buttons input_polldev input_core [last unloaded: ath] Call Trace: [800696cc] dump_stack+0x8/0x34 [8007dedc] warn_slowpath_common+0x78/0xa4 [8007df90] warn_slowpath_fmt+0x2c/0x38 [82d075b0] ath_stoprecv+0x90/0xa8 [ath9k] [82d04138] ath_set_channel+0xa4/0x740 [ath9k] [82d0503c] ath_radio_enable+0x55c/0x680 [ath9k] [82f45414] ieee80211_scan_work+0x30c/0x524 [mac80211] [800910bc] process_one_work+0x2c0/0x460 [80091d88] worker_thread+0x240/0x434 [80096a3c] kthread+0x80/0x8c [8006dde4] kernel_thread_helper+0x10/0x18 ---[ end trace 5948ecf07cb92b59 ]--- [ cut here ] WARNING: at /root/openwrt-svn-repo/routerStationPro/trunk_23933/build_dir/linux-ar71xx_generic/compat-wireless-2010-11-20/drivers/net/wireless/ath/ath9k/recv.c:532 ath_stoprecv+0x90/0xa8 [ath9k]() Could not stop RX, we could be confusing the DMA engine when we start RX up Modules linked in: ath9k ath9k_common ath9k_hw mac80211 ath ohci_hcd ath_pci ath_hal(P) nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp xt_string xt_layer7 xt_quota xt_pkttype xt_owner ipt_MASQUERADE iptable_nat nf_nat xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ehci_hcd ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables nfs loop lockd sunrpc usbcore ts_fsm ts_bm ts_kmp nls_base cfg80211 compat arc4 aes_generic deflate ecb cbc leds_gpio button_hotplug gpio_buttons input_polldev input_core [last unloaded: ath] Call Trace: [800696cc] dump_stack+0x8/0x34 [8007df3c] warn_slowpath_common+0x78/0xa4 [8007dff0] warn_slowpath_fmt+0x2c/0x38 [869e75b0] ath_stoprecv+0x90/0xa8 [ath9k] [869e4138] ath_set_channel+0xa4/0x740 [ath9k] [869e503c] ath_radio_enable+0x55c/0x680 [ath9k] [87385414] ieee80211_scan_work+0x30c/0x524 [mac80211] [8009111c] process_one_work+0x2c0/0x460 [80091de8] worker_thread+0x240/0x434 [80096a9c] kthread+0x80/0x8c [8006dde4] kernel_thread_helper+0x10/0x18 ---[ end trace d0a293f7237f639f ]--- Under what scenario we are seeing this warning ?,is this still happening with the latest compat. regards Peizhao ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
