You are not logged in.
Hi all,
It's being three weeks since I started to work with WARP v3 boards. So far I have just been testing the 802.11 reference design and getting familiar with Xilinx SDK. But now it's time to make the real magic. The experiment setup I am using is as follows:
AP (WARP v3) <-----> STA (WARP v3)
Each WARP board is connected to a laptop providing IPs to each one. AP and STA are able to ping each other.
Now I am interested to measure the RSSI, for instance by the AP (I would be interested in doing the same for the STA). For this, since I am quite new in this I thought of a simple solution. There is this function wlan_phy_rx_get_pkt_rssi() function defined at:
dir wlan_mac_shared -> wlan_mac_low_framework -> include -> wlan_phy_util.h
It is used at:
dir wlan_mac_low_dcf -> src -> wlan_mac_dcf.c
within the function frame receive.
As a first idea, I tried to modify the c file wlan_mac_ap_uart_menu.c placed at:
dir wlan_mac_high_ap -> src -> wlan_mac_ap_uart_menu.c
The modification was meant to include an extra feature at the printed menu when the COMX connection is opened. For instance:
[m] - Measure the RSSI of the channel
Within the same file, create a function performing rssi measurement when "m" is pushed (for simplicity only one value is reported each time user press "m").
So I created a function called void print_rssi(), which defines a variable, rssi and stores the result of calling wlan_phy_rx_get_pkt_rssi() and prints its value by the console. But there is a problem, when I try to include the header file ,where wlan_phy_rx_get_pkt_rssi() is defined, into wlan_mac_ap_uart_menu.c and error pops up (No such file in directory). The problem was not solved if I copy the file wlan_phy_util.h into the folder include of wlan_mac_high_ap.
I am sure, I am missunderstanding the layer architecture of the reference design. I was trying to look for more possibilities to implement this rssi print statement, but I ran out of ideas. I would like to get some advise in this concern if possible. Any help is welcome. Thanks beforehand.
Best regards,
Gabriele Galiero Casay
Offline
The 802.11 Ref Design uses two CPUs, both instances of the Xilinx MicroBlaze. The MAC application is split between the CPUs. Most peripherals in the hardware design can only be accessed by one CPU. For example, the Ethernet interfaces and DRAM can only be accessed by CPU High. Similarly the PHY cores and radio_controller can only be accessed by CPU Low. The wlan_phy_rx_get_pkt_rssi() function reads a register in the Rx PHY core. Thus, only CPU Low can run this function.
I would strongly suggest you investigate using the wlan_exp experiments framework, especially the wlan_exp Tx/Rx log tools. The reference code records the Rx power of every reception in the log. You can use wlan_exp to retrieve the log and analyze the Rx powers, all without changing the C code.
Offline
Thanks for your reply. It was really helpful. I was going through the code and trying to understand how the software architecture is defined. With relation to this I have noticed that the COM port of an AP offers a menu of options to display information. The option 1 gives information about time stamp, received power and so on, and refresh it each 1 sec, and the info stands for the last packet received. This info is shown for each particular station associated to the AP. My question was, is there any possibility or capability from the software to obtain the received power of each packet also for non associated or authenticated STAs?
Best regards
Last edited by ggalieroc (2015-Nov-06 09:10:48)
Offline
My question is there any possibility or capability from the software to obtain the received power of each packet also for non associated or authenticated STAs?
Yes, using the logging facility in the wlan_exp framework. The node logs every packet it receives, whether it is addressed to the node or not. The Rx log entries include Rx power (based on RSSI) and the PHY's Rx channel coefficients. You can retrieve a node's log via Ethernet and analyze the data using the wlan_exp Python tools.
The UART is there for debugging code - it is not a good way to gather experimental data. The UART interface is very slow, and printing to the UART is a blocking operation.
Offline
Thanks again for your advice. It was so useful
Offline