WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2015-May-04 10:04:57

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

802.11 reference design AP mode on Warp v3

I am trying to test AP mode of .11 ref design.
My connection setup:
Eth A of Warp v3 to LAN port of Linksys router
Eth B and PC sharing gigabit switch connection on 10.0.0.0 network
I am able to run the experimental setup on FPGA and create WARP AP access point. But End device (Mobile and Laptop) is unable to connect to the hotspot. Hex display though increment the value when new device tries to connect.
Did I miss something why devices are unable to connect to WARP AP

Last edited by mcccliii (2015-May-04 10:06:58)

Offline

 

#2 2015-May-04 10:26:22

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: 802.11 reference design AP mode on Warp v3

Have you checked the UART output of the AP to make sure everything looks normal?

Is your Linksys router performing DHCP and other services necessary to allow the clients to show a "connected" state?   From the AP docs:  "The AP code will pass through DHCP, ARP and IP traffic from wireless client to the wired network, allowing wireless clients to receive DHCP address assignments and exchange data with Internet services."

Offline

 

#3 2015-May-04 10:33:02

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: 802.11 reference design AP mode on Warp v3

If the hex display on the board increments, that means that the Wi-Fi device has fully associated with the AP (i.e., it has successfully gone through the Probe Req / Probe Resp / Auth Req / Auth Resp / Association Req / Association Resp handshakes.) This likely means that the connectivity problems you are having aren't a wireless problem, but rather something subtle about the wired side of the network.

In what way is the device "unable to connect to the hotspot?" Is the device just unable to access the Internet or is there a lower-level observation you have?

One useful debugging step would be to connect your PC's 10.0.0.0 network into Eth A of the AP. Then, on your Wi-Fi client, hardcode the IP address to something else on the 10.0.0.0 network and then connect to the AP. This will make the network skip DHCP. Once connected, can your PC successfully ping the Wi-Fi client via the 'ping' terminal command?

Offline

 

#4 2015-May-05 02:54:36

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

Re: 802.11 reference design AP mode on Warp v3

Thanks for the troubleshooting direction. It worked till connection part with AP with static IP but couldn't access the internet.
1. Following the direction i.e keeping EthA(WARP AP input) and PC in same network of 10.0.0.0, Ping was successful.
2. Then I used my original setup(ETH A to LAN of router, ETHB and PC on 10.0.0.0 network sharing Gibabite switch). After giving static IP to my mobile device, I was able to connect to connect to AP and but couldn't access internet.
3. Seems there is some problem with DHCP configuration of my router.   DHCP is enabled in router.

Last edited by mcccliii (2015-May-05 07:22:18)

Offline

 

#5 2015-May-05 08:58:16

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

Re: 802.11 reference design AP mode on Warp v3

Hi team,
Finally able to make the mobile connect as well as access the internet.
It was due to the Ethernet port speed. After using Gigabit Switch to share internet, AP mode finally work.

Offline

 

#6 2015-May-06 07:46:42

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

Re: 802.11 reference design AP mode on Warp v3

Hi Team,
While testing STA mode of  802.11 ref design, WARP STA is unable to automatically connect to AP. The STA application is able to scan available
BSS information and display in PUTTY.
My connection setup: ETH B---> NIC A of PC (1Gbps). ETHA-- >Gigabit switch<--- NIC B(Obtain IP automatically) . AP is Linksys router without security.

Offline

 

#7 2015-May-06 09:20:49

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: 802.11 reference design AP mode on Warp v3

First, from the STA documentation, the left-most DIP switch is used to enable or disable active scan for wireless networks on at boot.  So, please check that you have your dip switches set correctly.  Each of the 802.11 reference designs has independent dip switch behavior.

Second, the STA uses the access_point_ssid variable to determine the network is scans for at boot.  If that network does not exist, then it will not connect to a network automatically.  By default, the AP will use the network SSID "WARP-AP" and the STA will look for the network SSID "WARP-AP".  However, if you have changed the AP network name, then the STA will not be able to find the AP.  Also, in the WLAN Experiments framework, you can set the the AP SSID and you can have the STA scan and join a provided SSID.  You can see an example of this here.

Offline

 

#8 2015-May-06 09:25:56

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: 802.11 reference design AP mode on Warp v3

Couple other things:

- Is the WARP STA attempting to join a WARP AP? Or a commercial Wi-Fi AP? If it's the latter, is security disabled on the commercial Wi-Fi AP?
- As stated in the documentation, a WARP STA can't handle Eth A being plugged into a switch. It needs to be plugged into a single device. This is due to the STA Ethernet Encapsulation behavior.

Offline

 

#9 2015-May-06 10:16:46

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

Re: 802.11 reference design AP mode on Warp v3

Thanks welsh and chunter,

Welsch wrote:

STA uses the access_point_ssid variable to determine the network is scans for at boot.  If that network does not exist, then it will not connect to a network automatically.  By default, the AP will use the network SSID "WARP-AP" and the STA will look for the network SSID "WARP-AP".  However, if you have changed the AP network name, then the STA will not be able to find the AP.   .

It worked after assigning  access_point_ssid  to desired AP.

Offline

 

#10 2015-Jun-09 10:05:32

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

Re: 802.11 reference design AP mode on Warp v3

Hi team,
For my experiment using 2 WARPv3 one as AP and another as STA, I have successfully tested the Example script on TxRx Log Capture and Analysis and channel estimator viewer.
1. Particularly for my experiment, I need to extract the timestamps when AP send the data and STA receives the data. Can you point me where can I get the timestamps of each  data transmission?
2. Again for the Dual-Node Log Capture Example, which type of data generation method does LTG implement? In the notes, it said something about periodic or uniform random data generation?

Last edited by mcccliii (2015-Jun-09 10:06:15)

Offline

 

#11 2015-Jun-09 10:46:38

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: 802.11 reference design AP mode on Warp v3

mcccliii wrote:

For my experiment using 2 WARPv3 one as AP and another as STA, I have successfully tested the Example script on TxRx Log Capture and Analysis and channel estimator viewer.
1. Particularly for my experiment, I need to extract the timestamps when AP send the data and STA receives the data. Can you point me where can I get the timestamps of each  data transmission?

Each TX_LOW entry contains a 64-bit microsecond timestamp of that particular transmission. The analogous field on the reception log at the STA is the RX_OFDM entry. You can access these fields directly from the numpy array of log entries that you pull from the boards. Check out the log processing examples to see how they get access to the numpy arrays.

One thing to keep in mind, the timebase at the STA is, by default, independent from the timebase at the AP. If you want to transmission timestamps that are comparable to reception timestamps, you'll need to make sure they logs at each node stay aligned. The best way to do this is let the STA update its timestamp to match the AP after every beacon it receives. This feature is disabled by default, but can be enabled directly from your python wlan_exp script with the following command:

Code:

n_sta.sta_configure(beacon_ts_update=True)

where n_sta is your STA node object. After calling this, your timestamps will stay aligned throughout your experiment.

mcccliii wrote:

2. Again for the Dual-Node Log Capture Example, which type of data generation method does LTG implement? In the notes, it said something about periodic or uniform random data generation?

The two LTG schedules we have implemented are periodic and uniform random. The periodic LTG schedule enqueues a packet for transmission at a fixed interval provided by your wlan_exp python script. The uniform random LTG schedule enqueues a packet a uniform random interval after the previous packet enqueue. This uniform random interval is parameterized by a minimum and maximum value provided by your wlan_exp python script.

Independent of the schedule that defines when a packet is enqueued, the node also must decide how long the packet should be. We have also implemented two types of LTG payloads: fixed and uniform random. A fixed payload LTG will enqueue every packet with some fixed length. A (fixed payload, periodic schedule) tuple is a constant bitrate flow source.  The wlan_exp command for configuring this type of LTG is FlowConfigCBR. We also have a uniform random payload LTG, where each enqueued packet is a random length that is parameterized by a minimum and maximum value provided by the python script. A (uniform random payload, uniform random schedule) tuple can be configured with the FlowConfigRandomRandom command.

Offline

 

#12 2015-Jun-10 10:35:22

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

Re: 802.11 reference design AP mode on Warp v3

Thanks chunter for the direction,
I could generate the timestamp information for TX and RX data. But I am still unable to sync the initial timestamp.

chunter wrote:

One thing to keep in mind, the timebase at the STA is, by default, independent from the timebase at the AP. If you want to transmission timestamps that are comparable to reception timestamps, you'll need to make sure they logs at each node stay aligned. The best way to do this is let the STA update its timestamp to match the AP after every beacon it receives. This feature is disabled by default, but can be enabled directly from your python wlan_exp script with the following command:

Code:

n_sta.sta_configure(beacon_ts_update=True)

where n_sta is your STA node object. After calling this, your timestamps will stay aligned throughout your experiment.

Do I need to change inside node_sta.py or add the line in log_capture_two_node_two_flow.py script?

Last edited by mcccliii (2015-Jun-10 10:35:39)

Offline

 

#13 2015-Jun-10 11:47:54

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: 802.11 reference design AP mode on Warp v3

Do I need to change inside node_sta.py or add the line in log_capture_two_node_two_flow.py script?

You do not need to change node_sta.py. The sta_configure() method is a class method for node_sta. Just add that line to your log_capture_two_node_two_flow.py script to enable beacon timestamp sync'ing at the STA.

Offline

 

#14 2015-Jun-15 10:17:49

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

Re: 802.11 reference design AP mode on Warp v3

Hi Chunter,
I want to reproduce the Throughput vs Attenuation graph as well as the Transmit power accuracy graph for 802.11 ref design.
1. For the TP vs Attenuation experiment, was the Tx power set to 0dBm? I tested with different Tx setting from max= 21dBm and min -9dBm with different range of attenuation and TP was constant around 14Mbps for Rx> -80dBm and drastically fell after Rx<-80dBm.

2. Again For Transmit power accuracy test, I am using spectrum analyzer to observe the output power. Do I need to add attenuator before connecting to Spectrum analyzer?

Offline

 

#15 2015-Jun-15 15:04:51

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: 802.11 reference design AP mode on Warp v3

mcccliii wrote:

1. For the TP vs Attenuation experiment, was the Tx power set to 0dBm? I tested with different Tx setting from max= 21dBm and min -9dBm with different range of attenuation and TP was constant around 14Mbps for Rx> -80dBm and drastically fell after Rx<-80dBm.

For the experiment on this page, we left the Tx power the at-boot default. In v1.2 of the 802.11 Reference Design, this default power is set to 15 dBm. Your results sound right. This characterization shows that the PER "cliff" is around -80dBm for the default 18Mbps rate. The sensitivity required by the 802.11 standard is -77dBm, so the design is clearing the requirements by a few dB.

For transparency, the wlan_exp Python script that generated the "Throughput vs. Attenuation" plot is here:

Code:

import sys
import time
import wlan_exp.config as wlan_exp_config
import wlan_exp.util as wlan_exp_util
import wlan_exp.ltg as wlan_exp_ltg

import numpy as np

import matplotlib.pyplot as plt

from wlan_exp.prog_atten import ProgAttenController


plt.ion()
plt.show()

#-------------------------------------------------------------------------
#  Global experiment variables
#

# NOTE: change these values to match your experiment setup
NETWORK           = '10.0.0.0'
NODE_SERIAL_LIST  = ['W3-a-00183', 'W3-a-00189']
CHANNEL           = 1
AP_SSID           = "WARP Char"

# Set the per-trial duration (in seconds)
TRIAL_TIME        = 5

EXT_ATTEN         = '35dB'
EXT_ATTEN_NUM     = 35

ADDR_FILTER_LIST  = [(0x000000000000, 0xFFFFFFFFFFFF)] # Do not allow anyone

#-------------------------------------------------------------------------
#  Initialization
#
print("\nInitializing experiment\n")

pa = ProgAttenController()

# Create an object that describes the network configuration of the host PC
network_config = wlan_exp_config.WlanExpNetworkConfiguration(network=NETWORK)

# Create an object that describes the WARP v3 nodes that will be used in this experiment
nodes_config   = wlan_exp_config.WlanExpNodesConfiguration(network_config=network_config,
                                                           serial_numbers=NODE_SERIAL_LIST)

# Initialize the Nodes
#   This command will fail if either WARP v3 node does not respond
nodes = wlan_exp_util.init_nodes(nodes_config, network_config)

# Extract the different types of nodes from the list of initialized nodes
#   NOTE:  This will work for both 'DCF' and 'NOMAC' mac_low projects
n_ap_l  = wlan_exp_util.filter_nodes(nodes=nodes, mac_high='AP',  serial_number=NODE_SERIAL_LIST)
n_sta_l = wlan_exp_util.filter_nodes(nodes=nodes, mac_high='STA', serial_number=NODE_SERIAL_LIST)

# Check that we have a valid AP and .STA
if (((len(n_ap_l) == 1) and (len(n_sta_l) == 1))):
    # Extract the two nodes from the lists for easier referencing below
    n_ap = n_ap_l[0]
    n_sta = n_sta_l[0]
else:
    print("ERROR: Node configurations did not match requirements of script.\n")
    print(" Ensure two nodes are ready, one using the AP design, one using the STA design\n")
    sys.exit(0)


# Set the AP address filter 
n_ap.set_authentication_address_filter(ADDR_FILTER_LIST)

#-------------------------------------------------------------------------
#  Setup
#
print("\nExperimental Setup:")


# Put each node in a known, good state
for node in nodes:    
    node.reset_all()

    # Set all nodes to be on the same channel
    node.set_channel(CHANNEL)
    
    # Remove any current association information
    node.disassociate_all()

    # Get some additional information about the experiment
    channel  = node.get_channel()
    
    

    print("\n{0}:".format(node.name))
    print("    Channel  = {0}".format(wlan_exp_util.channel_to_str(channel)))

print("")

# Set the network SSID
ssid = n_ap.set_ssid(AP_SSID)
print("AP SSID: '{0}'\n".format(ssid))

# Force the association state between the AP and STA
#  This call inserts the STA into the AP's association table
#   and sets the active BSS at the STA to the AP
n_ap.add_association(n_sta)

# Check that the nodes are associated.  Otherwise, the LTGs below will fail.
if not n_ap.is_associated(n_sta):
    print("\nERROR: Nodes are not associated.")
    print("    Ensure that the AP and the STA are associated.")
    sys.exit(0)



#-------------------------------------------------------------------------
#  Run Experiments
#
print("\nRun Experiment:")

# Experiments:
#   1) AP -> STA throughput
#   2) STA -> AP throughput
#   3) Head-to-head throughput
#
#   Since this experiment is basically the same for each iteration, we have pulled out 
# the main control variables so that we do not have repeated code for easier readability.
#

attens = np.arange(20,48,.5)

rates = [0,1,2,3,4,5,6,7]
#rates = [1,2]
rates_mbps = [0]*len(rates)
rate_labels = ['6 Mbps','9 Mbps','12 Mbps','18 Mbps','24 Mbps','36 Mbps','48 Mbps','54 Mbps']

#Lambda functions to translate attenuation, rate and throughput values to strings
# The data values (atten/xput here) must be numeric strings; int, float or scientific notation are ok
# The series label values (rate here) are used for the chart legend and can be descriptive strings
fmt_atten = lambda a: '{0:2.1f}'.format(a)
fmt_xput = lambda x: '{0:2.2f}'.format(x)
fmt_rate = lambda r: rate_labels[r]

for idx_r,rate_num in enumerate(rates):
    rates_mbps[idx_r] =  wlan_exp_util.wlan_rates[rate_num]['rate']

#xputs = np.zeros((len(attens),len(rates)),dtype=float)
xputs = np.empty((len(attens),len(rates)),dtype=float)
xputs[:] = np.NAN

n_ap.ap_configure(power_savings=False) #Disable DTIM bcast blanking

ap_ltg_id  = n_ap.ltg_configure(wlan_exp_ltg.FlowConfigCBR(n_sta.wlan_mac_address, 1400, 0, 0), auto_start=False)
#ap_ltg_id  = n_ap.ltg_configure(wlan_exp_ltg.FlowConfigCBR(0xFFFFFFFFFFFF, 1400, 0, 0), auto_start=False)

for idx_a,atten in enumerate(attens):
    pa.set_atten(atten)
    
    
    for idx_r,rate_num in enumerate(rates):        
        ap_ltg_id  = n_ap.ltg_configure(wlan_exp_ltg.FlowConfigCBR(n_sta.wlan_mac_address, 1400, 0, 0), auto_start=False)
                        
        n_ap.reset(log=True)
        n_sta.reset(log=True)        
        
        time.sleep(0.100)
        
        rate = wlan_exp_util.wlan_rates[rate_num]
        
        n_ap.set_tx_rate_unicast(rate, curr_assoc=True, new_assoc=True)
        n_sta.set_tx_rate_unicast(rate, curr_assoc=True, new_assoc=True)
        n_ap.set_tx_rate_multicast_data(rate)
        n_sta.set_tx_rate_multicast_data(rate)        
        
        n_ap.ltg_start(ap_ltg_id)
    
        # Record the initial Tx/Rx stats
        sta_rx_stats_start = n_sta.stats_get_txrx(n_ap)
        ap_rx_stats_start  = n_ap.stats_get_txrx(n_sta)
        
        # Wait for the TRIAL_TIME
        time.sleep(TRIAL_TIME)
        
        # Record the ending Tx/Rx stats
        sta_rx_stats_end = n_sta.stats_get_txrx(n_ap)
        ap_rx_stats_end  = n_ap.stats_get_txrx(n_sta)
        
        n_ap.ltg_stop(ap_ltg_id)
        n_ap.queue_tx_data_purge_all()
        
        sta_num_bits  = float((sta_rx_stats_end['data_num_rx_bytes'] - sta_rx_stats_start['data_num_rx_bytes']) * 8)
        sta_time_span = float(sta_rx_stats_end['timestamp'] - sta_rx_stats_start['timestamp'])
        sta_xput      = sta_num_bits / sta_time_span
        xputs[idx_a][idx_r] = sta_xput
        
        print('{0} db, {1} rate {2} Mbps'.format(atten, rate_num, sta_xput))
        
        #%% Printing routine
        plt.close(1)
        fig = plt.figure(1, figsize=(14,10))
                                   
        myPlots = plt.plot(attens,xputs,marker='o')
        plt.legend(myPlots,rates_mbps,loc=2)
        plt.xlabel('Programmable Attenuation (dB)')
        plt.ylabel('Throughput (Mbps)')
        plt.title('{0} -> {1} -> Prog. Atten -> {2}'.format(NODE_SERIAL_LIST[0],EXT_ATTEN,NODE_SERIAL_LIST[1]))
        plt.grid('on')
        plt.gca().invert_xaxis()        
        plt.draw()
        plt.pause(.0001)
        
        np.save('xput_matrix',xputs)
        np.save('atten_vector',attens)

        
            

pa.close()

plt.savefig('{0},{1}.png'.format(NODE_SERIAL_LIST[0],NODE_SERIAL_LIST[1]))

#Generate javscript-compatible output
# flotr2 wants data as a list of series, each represented as a dictionary with keys "label" and "data":
#  {
#     label: "Serial #1 Label",
#     data: [ [x0,y0], [x1,y1], [x2,y2], ... [xN,yN] ]
#  }

o_str = 'var chart_data = ['

#Iterate over each rate (column in the xput matrix)
for r_idx,rate in enumerate(rates):
    o_str += '\n\n{{label:"{0}", data:['.format(fmt_rate(rate))

    #Iterate over each xput value for this rate
    for x_idx,xput in enumerate(xputs[:,r_idx]):
        o_str += '[{0},{1}],'.format(fmt_atten(-1*(attens[x_idx]+EXT_ATTEN_NUM)), fmt_xput(xput))
    o_str += ']},'

o_str += ']'

print('------- START -------')

#Copy/paste the output of this print into wiki/html page
print(o_str)

print('-------- END --------')

Note: this script won't directly run with only a stock v1.2 802.11 Reference Design Network. It also uses a custom package we developed for controlling our programmable attenuator.



mcccliii wrote:

2. Again For Transmit power accuracy test, I am using spectrum analyzer to observe the output power. Do I need to add attenuator before connecting to Spectrum analyzer?

It depends entirely on the spectrum analyzer. For example, we use an Agilent (Keysight) E4405B Spectrum Analyzer whose inputs are rated for a full 30dBm. So, we can plug WARP v3 directly into it without damaging anything. Check the documentation on your spectrum analyzer to be sure.

One thing to keep in mind about using a spectrum analyzer to measure Tx power is that many analyzer's don't have the ability to trigger their measurements only at times where the transmitter is running. So, it may "undercount" your Tx power by averaging over idle times between packet transmissions. There are two ways around this:

1. WARPLab is a good for something like this since it has the continuous_tx mode. You can load up a transmit buffer with a Tx waveform of your choosing and tell WARPLab to loop over that buffer sending it continuously.

2. You can also minimize idle times in the 802.11 design and measure it's transmit power. Check out this thread for more details.

Offline

 

#16 2015-Jun-17 04:19:27

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

Re: 802.11 reference design AP mode on Warp v3

Thanks Chunter for the input.
1. Again I have a question regarding the Tx payload. While extracting the TX_LOW and RX_OFDM  information with Timestamp and payload, Icam seeing that Tx is periodically sending 74Bytes payload. Tx-Rx Timestamp with payload.
When I extract only the TX_LOW_LTG and RX_OFDM_LTG then I don't get the 74Bytes transmission and reception. Where is this 74 Byte coming from when LTG is configured for only 1400Bytes? During TP calculation is this 74 Bytes Tx/Rx also considered.

2.When I was going through throughput_two_node.py

Code:

node1_to_node2_num_bits  = float((node2_txrx_stats_for_node1_end['data_num_rx_bytes'] - node2_txrx_stats_for_node1_start['data_num_rx_bytes']) * 8)

In the variable explorer Rx Start and Rx End. I observe that only 1400 Bytes are considered. Total pkts=3397 each with 1400 Bytes.

Offline

 

#17 2015-Jun-17 09:23:06

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: 802.11 reference design AP mode on Warp v3

mcccliii wrote:

Thanks Chunter for the input.
1. Again I have a question regarding the Tx payload. While extracting the TX_LOW and RX_OFDM  information with Timestamp and payload, Icam seeing that Tx is periodically sending 74Bytes payload. Tx-Rx Timestamp with payload.
When I extract only the TX_LOW_LTG and RX_OFDM_LTG then I don't get the 74Bytes transmission and reception. Where is this 74 Byte coming from when LTG is configured for only 1400Bytes? During TP calculation is this 74 Bytes Tx/Rx also considered.

Those are beacon frames. The 802.11 standard requires an AP to periodically transmit beacons. Since they aren't LTG frames, they don't show up as the TX_LOW_LTG and RX_OFDM_LTG types.

Regarding throughput, it's up to you on whether you want to count them. Are you measuring throughput or goodput? From the MAC's perspective, the reception of a beacon frame is a successful reception from a wireless station. So, you could justify counting those packets towards a throughput measurement. However, beacons don't carry any usable payload. They are higher-layer overhead. So, you might not want to count them in a goodput measurement. Ultimately it's pretty inconsequential considering it only adds 74 bytes every ~100ms.

mcccliii wrote:

2.When I was going through throughput_two_node.py

Code:

node1_to_node2_num_bits  = float((node2_txrx_stats_for_node1_end['data_num_rx_bytes'] - node2_txrx_stats_for_node1_start['data_num_rx_bytes']) * 8)

In the variable explorer Rx Start and Rx End. I observe that only 1400 Bytes are considered. Total pkts=3397 each with 1400 Bytes.

I'm not sure I understand your question. The image you posted indicates that, prior to the beginning of your experiment, node2 had received 1 packet of payload size 1400 bytes. Since this reception happened prior to you actually beginning your experiment, it shouldn't be considered in your final throughput processing.

At the end of your experiment, the node had received a total of 3397 packets yielding a total number of bytes of (3397*1400 = 4,755,800 bytes). Therefore, the number of packets received during the experiment was (3397-1 = 3396) and the total number of payload bytes was (4,755,800 - 1400 = 4,754,400 bytes).

Last edited by chunter (2015-Jun-17 10:00:13)

Offline

 

#18 2015-Jun-18 11:31:38

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

Re: 802.11 reference design AP mode on Warp v3

Thanks Chunter for the detailed explanation.
With the direction provided I performed the TP vs Attenuation as well as Transmit power accuracy test.
1. TP vs attenuation graph was comparable.TPvsAtten
2. For Transmitter accuracy test, my observed Tx power was 1-2 dB higher than the set power.Tx Accuracy
Experiment setup:

Code:

1. Rhodeswarz spectrum analyzer with 30dBm input RF. No need for Attenuation for -9dBm to 21dBm range
2. FREQ=Channel 1( 2.412GHz) SPAN=40MHz ,RES BW=100KHz
3. Channel BW= 20MHz
4. Trace = MAX HOLD
USED: broadcast.py script to lower idle time. Time=30s

Is the behavior normal?

Offline

 

#19 2015-Jun-18 12:14:03

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: 802.11 reference design AP mode on Warp v3

A few dB variation is expected- this is well within the combined tolerances of the various ICs and passives on the board, variations due to temperature and differences between test instruments. If your project requires precise Tx power, then your experiment is the perfect setup to gather the data needed to replace the approximation implemented in the wlan_mac_low_dbm_to_gain_target() function with a kit-specific mapping.

Offline

 

#20 2015-Jun-22 03:16:33

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

Re: 802.11 reference design AP mode on Warp v3

Thank Murpho for the input.
I have new queries about wlan_exp framework.
1. I am using v1.2 of the reference design and the wlan_exp packages. I see that only from this version onwards setting Tx power from python script was incorporated. If I need to incorporate setting Tx from wlan_exp for v0.96 of ref design, does it require complex code changes?

Offline

 

#21 2015-Jun-22 10:26:29

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: 802.11 reference design AP mode on Warp v3

Looking through the SVN logs, it looks like there is a set_tx_power() method in the node object in the .96 release. Do you see that in your design? It's possible that it isn't "hooked up" in C in your design branch since it's safe to assume that setting Tx power in the MAX2829 radio is different than WURC. It's worth tracing that command through your code and see if it's processed in C on the node side. If it is, you should be able to add commands to change the Tx power. I'm not sure how you change Tx power in the WURC radio, so I can't help too much with that.

Offline

 

#22 2015-Jun-22 10:49:31

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: 802.11 reference design AP mode on Warp v3

1. I am using v1.2 of the reference design and the wlan_exp packages. I see that only from this version onwards setting Tx power from python script was incorporated. If I need to incorporate setting Tx from wlan_exp for v0.96 of ref design, does it require complex code changes?

Just to clarify this point- we changed the API for setting Tx power in the v1.2 release. Before this the node.set_tx_power() method accepted a single value, which set the Tx power for all packet types. But the corresponding node.get_tx_power() returned a 4-tuple of powers, one for each packet type. This inconsistency was confusing. In v1.2 we added explicit node methods to set and get the Tx power per packet type (set_tx_power_unicast(), set_tx_power_multicast_data() etc). This allows sensible code like "node.set_tx_power_unicast(node.get_tx_power_unicast()+1)". The node.set_tx_power() method has the same behavior (sets Tx power for all packet types).

Offline

 

#23 2015-Jun-22 10:53:29

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: 802.11 reference design AP mode on Warp v3

Just to follow up, in v0.96, we didn't quite have the setting power infrastructure completely defined.  The basic infrastructure was there but not the granularity of control.  Basically in v0.96, each node had a single tx power, while in later versions we expanded this so that the node could transmit at different powers for a variety of different situations.  Also, we had not done all of the calibration testing so you can see the MIN / MAX definitions are different as well as the node's notion of what a given power level means.  You can see the difference in the underlying implementation of the set_tx_power python command:

v0.96 Python set_tx_power command
vs
v1.3 Python set_tx_power command

Similarly, you can see the same difference reflected in the C implementation on the node:

v0.96 C set_tx_power command
vs
v1.3 C set_tx_power command

Here are the node's notion of power in each design:

v0.96 Rx power calculation
vs
v1.3 Rx power calculation

You will need to figure out how much of the new set power infrastructure you need and pull in the appropriate changes.  Also, you will need to understand how to control and calibrate the WURC radio since all of our power infrastructure is based on the WARP radios.

Offline

 

#24 2015-Jun-29 06:56:50

mcccliii
Member
Registered: 2013-Jun-20
Posts: 38

Re: 802.11 reference design AP mode on Warp v3

Hi Guys,
I have some confusion regarding the RX_OFDM log entry as well as the timestamp value extracted from stats_get_txrx().
1.
When I extract RX_OFDM log entry, the length of payload is shown 1428B. LTG is configured for payload=1400B. On the other hand TP _between_two nodes.py extracts 1400B payload information from txrx_stats to calculate goodput.
RX_OFDM_LTG
--Why is RX_OFDM  recording 1428Bytes as payload?
--From the RX_OFDM log entry, the RF gain and BB gain is same at Rx_power. Is the RF and BB gain disable by default  in ref design?

2. What does the timestamp information represent that is extract from stats_get_txrx()? Is it the time right after LTG is configured?
timestamp_start_end

Offline

 

#25 2015-Jun-29 10:07:06

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: 802.11 reference design AP mode on Warp v3

I apologize for this not being more clear in the documentation. 

Why is RX_OFDM  recording 1428Bytes as payload?

An LTG "payload" as defined in WLAN Exp is just the payload bytes of a packet and does not include the MAC header or FCS (you can see the this in the definition of the MIN and MAX payload length, here).  However, when we log a packet, we need the information in the MAC header and the FCS.  Therefore, we go ahead and include that in the payload information.  As you can see in the RX_OFDM logging code, the "length" field is the PHY length of the packet (i.e. it includes the 24 bytes of the MAC header and the 4 bytes of the FCS).  Therefore, when you set the "payload" to 1400 bytes, the actual packet that was transmitted is 1428 bytes. 

Now, when we look at throughput / goodput, 1428 bytes is the "raw" number of bytes transferred and not the "useful" bytes transferred (i.e. there are 28 "overhead" bytes for each packet).  Since the MAC header and FCS are overhead, when we update the txrx_stats, we only use the MPDU length (i.e. the length without the MAC header or FCS).  You can see this in the RX statistics logging and TX statistics logging

Now, I'm not quite sure I understand your second question:

From the RX_OFDM log entry, the RF gain and BB gain is same at Rx_power. Is the RF and BB gain disable by default  in ref design?

The AGC is operational in the reference design and is used to set the gains for each packet.  Based on the gains and the RSSI, CPU low computes the RX power.  Therefore, it is common to see different RX powers for a given set of gains. 

2. What does the timestamp information represent that is extract from stats_get_txrx()? Is it the time right after LTG is configured?

The timestamp in the txrx_stats entry is the "Microsecond timer value at time of log entry creation".  This means when you request a log entry through stats_get_txrx(), the timestamp is the value of the microsecond counter at the time that the entry is sent to you.  You can see the code here, where the entry is set to be copied to an ethernet packet to respond to the "stats_get_txrx" command, and here, where the stats structure is copied and the timestamp is set.

This is why in the throughput_two_nodes.py example, we calculate the time span using the timestamp in the "end" stats entry minus the timestamp in the "start" stats entry:

Code:

node1_to_node2_time_span = float(node2_txrx_stats_for_node1_end['timestamp'] - node2_txrx_stats_for_node1_start['timestamp'])

LTGs have no effect on statistics timestamps which is why we always start the LTG flow before recording any statistics and only stop the flow after we have finished recording the last statistics for the experiment.  This way, we do not include any "dead time" in our calculations using the statistics structures.

Offline

 

Board footer