wiki:802.11/Usage

Version 29 (modified by murphpo, 9 years ago) (diff)

--

802.11 Reference Design: Usage

The 802.11 Reference Design is intended as a starting point for a wide variety of research projects. The sections below describe the default behaviors of the reference design and give pointers on where to start for customizing the design for your application.

  1. Creating the SDK Workspace

Reference Design Archive

The Mango 802.11 Reference Design is packaged as a .zip file with the full source code and compiled bitstreams for the reference design. The latest release is available on the Dowload page. You can view the latest source code in the repository (ReferenceDesigns/w3_802.11). Please note the code in the repository is under active development.

The contents of the 802.11 Reference Design .zip file are explained below.

LICENSE.txt

This file explains terms under which the 802.11 Reference Design is released.

Bitstreams_Reference

Bitstreams are fully-built designs that are ready to be downloaded onto WARP hardware. Files ending with the extension '.bit' may be downloaded using the Xilinx tool iMPACT. Files ending with the extension .bin may loaded onto an SD card so that the WARP v3 hardware will automatically be programmed whenever it is powered on and has the SD card inserted. Details on how to configure an SD card with a '.bin' file are provided here.

EDK_Projects

This folder contains an EDK project built with the Xilinx Embedded Development Kit (EDK) software. The hardware design is constructed and implemented in EDK Xilinx Platform Studio (XPS). The software designs, running in two MicroBlaze processors, are built in the Xilinx SDK. Opening the EDK project requires a copy of the WARP edk_user_repository at the SVN revision in the table above.

The EDK projects is a combination of an XPS project along with Eclipse software projects that can be imported into an SDK workspace. These software projects are present in the 'SDK_Workspace' subfolder of every XPS project -- we recommend using this folder as the location of the SDK Workspace. These projects can then be imported "in place" and will not need to be copied.

SysGen_Reference

This folder contains the source System Generator models for the PHY Rx, Tx, AGC and MAC-DCF. Each sub-folder also contains the init scripts and support files required by each model. These scripts and models are configured to run in simulation as-is. To run a simulation, open MATLAB, cd to one of the model directories (wlan_phy_rx_pmd, for example), open the .mdl file and click Run.

Python_Reference

This folder contains the reference version of the wlan_exp Python package and associated example scripts. See the wlan_exp Getting Started page for details on installing the wlan_exp package from this folder.

AP vs STA Applications

The 802.11 Reference Design contains two implementations that share the same low-level MAC and PHY. These implementations are an access point (AP) that can be joined by 802.11 devices and a station (STA) that can join 802.11 APs (WARP or otherwise).

802.11 AP

By default, the AP Reference Design implements an 802.11 compatible access point with SSID "WARP-AP". To use the design in this configuration:

  1. Connect the WARP v3 ETH A interface to a local network, ideally one with a DHCP server and internet access. The 802.11 Reference Design is not a router -- it does not have a DHCP server to issue IP addresses to associated stations. It will pass DHCP requests and responses through its Ethernet portal to the wired network.
  2. Download the 802.11 Reference Design and program a WARP v3 board with the provided bitstream for the AP implementation.
  3. Use an 802.11 device (such as a computer or smartphone) to join the open network with SSID of "WARP-AP." The 802.11 device should associated successfully and communicate with the wired network (and internet, if the wired network has internet access).

802.11 STA

By default the Reference Design STA application will attempt to associate with an AP advertising the SSID of "WARP-AP." Programming one node with the AP design and one (or more) nodes with the STA design will automatically create a wireless network of associated nodes. The STA and AP node LEDs indicate association status (details below).

Alternatively, the UART menu on the station can be used to perform an active scan and display the list of all nearby APs and their SSIDs. This menu can then be used to attempt association to one of those APs. To use this design,

  1. Plug ETH A from a WARP v3 board into a single Ethernet device such as a laptop or desktop PC. The STA design will bridge the Ethernet link of that device to the 802.11 wireless link. NOTE: do not plug ETH A into a switch with other devices, especially other WARP v3 nodes running the STA application. This can create a circular bridge (wired-wireless-wired) that will behave badly.
  2. Download the 802.11 Reference Design and program a WARP v3 board with the provided bitstream for the STA implementation.
  3. Use the UART menu to associate with a nearby AP.
  4. Access the wireless network from the device that is plugged into ETH A.

Using the UART Menu

Both the AP and STA implementations include extensive control of parameters via UART. The instructions provided here show how to connect to the USB UART on WARP v3. The 802.11 Reference Design uses a baud rate of 115200 for all UART interactions. Because the 802.11 Reference Design contains two processors each with their own ability to print to UART, the User I/O dip switch on the board is used to select which UART output is driving the USB UART port on the board. The below menus assume you are connected to the UART that is driven by CPU_HIGH. To make this selection, ensure that the right-most dip switch in the User I/O section of the board is set to "up."

AP UART Capabilities

  • Change the advertised SSID
  • Change the channel
  • Change the rate used for unicast transmissions
  • Print the current status of transmit queues
  • Enter an interactive AP menu where
    • individual station statistics can be observed (e.g. last received power, packet counts, etc)
    • traffic can be locally generated for any number of connected stations

STA UART Capabilities

  • Perform an active scan and details about nearby access points
  • Associate with an access point displayed during the active scan
  • Change the rate used for unicast transmissions
  • Enter an interactive STA menu where
    • statistics about the associated AP can be observed (e.g. last received power, packet counts, etc)
    • traffic can be locally generated for the associated AP

LEDs

The 802.11 Reference Design AP and STA implementations use the WARP v3 board LEDs as status indicators.

  • Green LEDs: increment for every error-free packet reception that passes the node's address filter
  • Red LEDs: increment on Rx PHY events with good SIGNAL field but bad payload checksum. Note: packets that are not detected or packets that are detected but contain a bad SIGNAL field are not displayed in any way in the LED bank.
  • Hex Displays:
    • AP: the AP hex displays blink slowly to indicate the AP is accepting new association requests. The number of active associations is displayed.
    • STA: the STA displays the node's current AID (association ID), as assigned by the AP. The STA displays 00 when not associated with an AP.

Debugging Software

The dual-processor architecture of the 802.11 Reference Design presents some challenges in debugging the software applications.

The usual debugging tools in the Xilinx SDK work fine with dual-processor designs. The Reference Design includes one instance of the mdm pcore. The mdm is connected to both MicroBlaze debug ports. The PC-side debug tools can connect to either MB via the mdm and xmd.

Each MicroBlaze processor has an xps_uartlite peripheral mapped to stdin/stdout. The WARP v3 hardware has only one USB-UART transceiver. The Reference Design includes a uart_mux core which allows either xps_uartlite to connect to the USB-UART transceiver. By default the mux is controlled by the LSB of the user DIP switch on the WARP v3 board. A 0 (switch down) selects the UART for CPU Low.

Debug Signals

The Reference Design routes various internal MAC/PHY signals to the 16-pin debug header on the WARP v3 node. These signals allow monitoring of MAC/PHY state at run time using an oscilloscope or logic analyzer. The current pin assignments are listed below. These may change between releases, depending on what we're debugging at the time. You can confirm the current pin assignments by looking at the PORT debughdr = ... line in the system.mhs file.

Refer to the WARP v3 user guide for the numbering of pins on the header.

Pin Map for v0.93:

Pin Signal
0 OFDM Rx PHY running: asserts when the first FFT is started and de-asserts when the Rx PHY completes processing
1 Rx Packet Detect: asserts when the Rx PHY attempts a reception. A packet detection event does not always result in an Rx PHY started event
2 LTS Timeout: asserts briefly when the Rx PHY fails to correlate the preamble LTS following a packet detection event
3 Tx Pending: asserted by the MAC hardware when a new Tx MPDU is provided by the MAC but has not yet been submitted to the Tx PHY
4 RSSI Det: asserts when the instantaneous RSSI exceeds a programmed threshold (debug only - does not indicate actual PHY state)
5 FCS Good: asserts briefly after the PHY writes the last byte of a received frame to the packet buffer and the checksum calculation indicates no errors
6 Tx PHY Running: asserts when the Tx PHY begins transmitting a frame and de-asserts after the last sample is transmitted
7 DSSS Rx PHY Running: asserts when the DSSS receiver is processing a frame
8 NAV Active: asserted whenever the MAC is enforcing backoff due to virtual carrier sense after reception of a frame with a valid duration field
9 Idle for DIFS: asserted whenever the MAC observes the medium has been idle longer than DIFS interval
10 EIFS Sel: asserted when the MAC is enforcing an EIFS interval of idle time
11 Backoff Active: asserted whenever the MAC is deferring to a busy medium; the MAC will not transmit when backing off
12:15 Sw Debug: General debug outputs controlled by software via a register in the Rx PHY; useful for unobtrusively measuring software execution times

Pin Map for v0.95:

Pin In/Out Signal Description
0 Out Tx PHY Active: asserts when the Tx PHY begins transmitting a frame and de-asserts after the last sample is transmitted
1 Out OFDM Rx PHY Active: asserts when the first FFT is started and de-asserts when the Rx PHY completes processing
2 Out DSSS Rx PHY Active: asserts when the DSSS receiver is processing a frame
3 Out OFDM Packet Detect: asserts when the OFDM Rx PHY attempts a reception. A packet detection event does not always result in an Rx PHY active event
4 Out DSSS Packet Detect: asserts when the DSSS Rx PHY attempts a reception. A packet detection event does not always result in an Rx PHY active event
5 Out LTS Timeout: asserts briefly when the Rx PHY fails to correlate the preamble LTS following a packet detection event
6 Out FCS Good: asserts briefly after the PHY writes the last byte of a received frame to the packet buffer and the checksum calculation indicates no errors
7 Out RSSI Det: asserts when the instantaneous RSSI exceeds a programmed threshold (debug only - does not indicate actual PHY state)
8 Out Tx Pending: asserted by the MAC hardware when a new Tx MPDU is provided by the MAC but has not yet been submitted to the Tx PHY
9 Out Idle for DIFS: asserted whenever the MAC observes the medium has been idle longer than DIFS interval
10 Out Backoff Active: asserted whenever the MAC is deferring to a busy medium; the MAC will not transmit when backing off
11 Out NAV Active: asserted whenever the MAC is enforcing backoff due to virtual carrier sense after reception of a frame with a valid duration field
12:14 Out Sw Debug: General debug outputs controlled by software via a register in the Rx PHY; useful for unobtrusively measuring software execution times
15 In Rx OFDM Ext Pkt Det: input to PHY pkt detect logic which forces a pkt det event, independent of the normal detection thresholds; useful for assuring the Rx PHY attempts reception of every packet transmitted by another node (Tx PHY Active -> Ext Pkt Det is "perfect" packet detection)