WARP Project Forums - Wireless Open-Access Research Platform

1) The hardware platform is absolutely capable of that kind of turn-around time. In the currently posted reference design (v08), however, the turn-around time is around 80 microseconds. We've fixed this in the new reference design (v09) with some architecture changes resulting in a much more palatable 30 microseconds. I expect the v09 reference design to be posted within the week. Reducing that time even further (to mimic 802.11 MAC timing) is a work in progress that generally improves with each reference design release.

2) With QPSK on each of the 48 subcarriers of the current PHY, the peak throughput is around 12Mbps with an effective throughput at the MAC layer of about 6Mbps. However, the current PHY also supports higher modulation orders that can dramatically increase that number in clean wireless environments. A networking student at Rice has a publication currently under review that presents results from a novel MAC layer implemented on WARP that aggressively changes the PHY rate based on internal PHY parameters instead of the usual inference of channel quality from dropped packets. If you are interested, you can email him about an advance copy of the paper and I'm sure he'd be happy to send it.

3) I'm not sure about this one. I'll consult with the student who wrote the radio controller and get back to you. Of course, it's very easy to use any arbitrary channel in the 2.4GHz and 5GHz bands. As far as tuning to some arbitrary frequency between channels, I'll have to get back to you.

4) It's possible. The radios themselves provide 40MHz of bandwidth, but it's up to the PHY to decide how to use it. For our OFDM reference design's PHY, only 10MHz of that band is actually used. This is done primarily so we can quickly iterate on PHY changes without waiting around for the tools to try to meet stricter timing constraints in placing and routing the FPGA. That said, in C-code you can use an arbitrary amount of that 10MHz by enabling and disabling subcarriers.

5) You are correct. The MAC is entirely C code and is fast and easy to change. Luckily, the tools are smart and don't try to rebuild the hardware designs if you simply want to make a change to the PowerPC's behavior. Modifying our PHY requires some FPGA programming expertise. The design was built and is maintained in Xilinx System Generator, which is a graphical FPGA programming tool that sits inside Matlab's simulink. You can change the design there or rip out pieces and replace them with your own hand-written VHDL or Verilog. We've had many students fork the PHY code in the repository and make changes to suit their own research goals. FYI, the example you gave (separate modulation scheme for each of the OFDM carriers) is already supported in the PHY. From C-code, you can enable/disable subcarriers as well as set their modulation orders independently from one another. The one caveat to this is that we haven't built a way to provide the receiver with what separate subcarrier modulation orders actually are. This means that both the transmitter and receiver have to agree a priori what the allotment is or else the receiver won't be able to decode the message. We have, however, built this system for the simpler case of every subcarrier being the same arbitrary modulation order. In that system, the header of the packet is an agreed-upon base rate and contains information about the full-rate of the rest of the packet. This is how the aforementioned networking student was able to construct an aggressive rate-adaptation algorithm and implement it on WARP. Something similar could be built for a system where each subcarrier has an independent rate, but the amount of overhead in conveying that information to the receiver would grow pretty large.


The graphic on this page shows the main subsystems that run on the WARP boards. A key feature of WARP is that absolutely everything about the comm system runs directly on the boards. Computers are only used for testing the link by generating traffic; no link-related processing takes place there. If you take an out-of-the-box reference design and load it onto a board that is just plugged into the wall over Ethernet, you can surf the internet on a computer that is tied into another WARP node that is running the reference design. No computer is actually needed for the networking stack.

If any of that was unclear or if you have any more questions, please reply back. Thanks!

-Chris

1) That's right- you can enable/disable subcarriers using just C functions. It's important to note that this is a property of our PHY implementation. A different PHY could be more (or less) flexible. The FPGA and radio boards don't care what signals you transmit/receive.

2) Changing the subcarrier spacing would definitely require FPGA design changes (i.e. modifications to the System Generator model implementing the PHY).

3) BPSK, QPSK, 16-QAM and 64-QAM are all implemented. The first three work reliably; 64-QAM works well only over short distances (i.e. high SNR). The corresponding data rates are 6, 12, 24 and 36 Mbps. This assumes the standard subcarrier choices (48 data-bearing subcarriers per OFDM symbol).

4) The current PHY isn't built to monitor energy over a wide bandwidth. It uses RSSI for carrier sensing, but this only covers ~3MHz bandwidth around the carrier. A different FPGA model could be built that would sense energy across the full 40MHz bandwidth the radio can receive.

5) The FPGA board supports 4 radios simultaneously. Each radio is controlled independently (i.e. each can be tuned to different channels). We currently only have one model of radio board; it covers the 2.4 and 5GHz bands.

6) Modifying the PHY would require modifying the System Generator model. This is definitely FPGA design, but it's graphical (it works inside Simulink) instead of textual (like Verilog/VHDL). It's hard to articulate the learning curve. It might help to look through our workshop exercises that use Sysgen for some very simple designs. You can also download a demo from Xilinx (assuming you already have MATALB); the installation includes a bunch of well-documented examples.

I'm pretty sure you can tune to arbitrary frequencies (in the 2.4/5GHz bands), but we haven't tried it. The tuning is definitely controlled from software. You can see the current code in the radio controller driver. You'll see there a switch statement, indexed by 802.11 channel numbers. Each index corresponds to two "magic" numbers, written to registers in the radio transceiver. These registers control the PLL in the transceiver, setting the center frequency. We used the values suggested in the MAX2829 datasheet for tuning to 802.11 channels, but I think other frequencies are possible with the right PLL parameters.