update README

This commit is contained in:
Bastian Bloessl
2013-12-06 19:46:19 +01:00
parent 4f4418c6f2
commit ab82c9c8d7
2 changed files with 159 additions and 55 deletions
-55
View File
@@ -1,55 +0,0 @@
Hi,
this an IEEE 802.11 a/g/p transceiver for GNU Radio v3.7. Over the air, I tested it with the Ettus USRP N210 with XCVR2450 and CBX daughterboards. For interoperability tests I use mainly an Atheros (ath5k) WiFi card. The code can also be used to make packet error rate simulations.
### DEPENDENCIES
IT++ (Version: 4.2-4)
log4cpp (for now, until my cmake foo gets better)
GNU Radio (v3.7 with UHD support)
If you want to run the receive demo (the one that plots the subcarrier constellations), please assert that you have python-opengl installed. The nongl version of the plot does not work for me.
### INSTALLATION
sudo apt-get install libitpp-dev
sudo apt-get install liblog4cpp5-dev
git clone git://github.com/bastibl/gr-ieee802-11.git
cd gr-ieee802-11
mkdir build
cd build
cmake ..
make
sudo make install
sudo ldconfig
If you want to connect the flow graph to Wireshark you might also want to install my non WiFi related blocks from
https://github.com/bastibl/gr-foo
The physical layer is encapsulated in a hierarchical block. To install it, open examples/ofdm_phy_hier.grc in GRC and click build.
The message ports in the flow graphs might not be connected. In that case just reconnect them. See
http://comments.gmane.org/gmane.comp.gnu.radio.general/48222
### USAGE
In the examples folder are several flow graphs. For the more complex ones, there are start scripts in the apps folder.
### REMARKS
- If you have problems with the DC offset, try to set the frequency of the RF frontend to a value outside your signal of interest. To do that, set the frequency parameter of the USRP block to something like: uhd.tune_request(5.9e9, 6e6).
- If you have a CBX or SBX board, calibrate it.
- If you have overruns, assert that you compiled everything in release mode and run volk_profile, which is part of GNU Radio.
- If 'D's appear, it might be related to your network interface card. Assert that you made the sysconf changes recommended by Ettus. What NIC do you have? How are you connected to the USRP (switch or directly)?
- I never needed it, but maybe real-time priority helps.
Transmitter related:
- The transceiver is currently connected to a TAP device, i.e. is a virtual Ethernet interface. Therefore, we have no WiFi signaling like association requests and hence, the transceiver can not "join" an ad hoc network. You have to make some small changes to the kernel in order to convince you WiFi card to send to this hosts nevertheless.
- The transceiver can not respond to ACKs in time. This is kind of an architectural limitation of USRP + GNU Radio since Ethernet and computations on a normal CPU introduce some latency. You can set the number of ACK retries to zero and handle retransmits on higher layers (-> TCP).
- RTS/CTS is not working for the same reason. You can however just disable this mechanism.
- Currently, there is no CSMA/CA mechanism, but this can be implemented on the FPGA.
### FURTHER INFORMATION
http://www.ccs-labs.org/projects/wime/
+159
View File
@@ -0,0 +1,159 @@
Hi,
this an IEEE 802.11 a/g/p transceiver for GNU Radio v3.7. Over the air, I tested it with the Ettus USRP N210 with XCVR2450 and CBX daughterboards. For interoperability tests I use mainly an Atheros (ath5k) WiFi card. The code can also be used for packet error rate simulations.
# Installation
## Dependencies
### log4cpp
I use the new [logging feature](http://gnuradio.org/doc/doxygen/page_logger.html) of GNU Radio which relies on log4cpp. This should be an optional dependency some when, but currently it is required. You can install it with
sudo apt-get install log4cpp5-dev
sudo port install log4cpp
### GNU Radio v3.7
There are several ways to install GNU Radio. You can use
- [pybombs](http://gnuradio.org/redmine/projects/pybombs/wiki)
- [pre-combiled binaries](http://gnuradio.org/redmine/projects/gnuradio/wiki/BinaryPackages)
- [from source](http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource)
### IT++
I use the Viterbi decoder of IT++.
sudo apt-get install libitpp-dev
sudo port install itpp
### gr-foo
I have some non project specific GNU Radio blocks in my gr-foo repo that are needed. For example the Wireshark connector. You can find these blocks at [https://github.com/bastibl/gr-foo](https://github.com/bastibl/gr-foo). They are installed with the typical command sequence:
git clone https://github.com/bastibl/gr-foo.git
cd gr-foo
mkdir build
cd build
cmake ..
make
sudo make install
sudo ldconfig
## Installation of gr-ieee802-11
To actually install the blocks do
git clone git://github.com/bastibl/gr-ieee802-11.git
cd gr-ieee802-11
mkdir build
cd build
cmake ..
make
sudo make install
sudo ldconfig
### OFDM PHY
The physical layer is encapsulated in a hierarchical block to allow for a clearer transceiver structure in GNU Radio Companion. This hierarchical block is not included in the installation process. You have to open ```/examples/ofdm_phy_hier.grc``` with GNU Radio Companion and build it. This will install the block in ```~/.grc_gnuradio/```.
### Check message port connections
Sometime the connections between the message ports (the gray ones in GNU Radio Companion) break. Therefore, please open the flow graphs and assert that everything is connected. It should be pretty obvious how the blocks are supposed to be wired. Actually this should not happen anymore, so if your ports are still unconnected please drop me a mail.
### Python OpenGL
If you want to run the receive demo (the one that plots the subcarrier constellations), please assert that you have python-opengl installed. The nongl version of the plot does not work for me.
### Run volk_profile
volk_profile is part of GNU Radio. It benchmarks different SIMD implementations on your PC and creates a configuration file that stores the fastest version of every function. This can speed up the computation considerably and is required in order to deal with the high rate of incoming samples.
### Calibrate your daughterboard
If you have a WBX, SBX, or CBX daughterboard you should calibrate it in order to minimize IQ imbalance and TX DC offsets. See the [application notes](http://files.ettus.com/uhd_docs/manual/html/calibration.html).
# Checking you installation
As a first step I recommend to test the loopback flow graph. This flow graph does not need any hardware and allows you to ensure that the software part is installed correctly. So open the flow graph and run it. If everything works as intended you should see some decoded 'Hello World' packets in the console.
# Usage
## Simulation
The loopback flow graph should give you an idea of how simulations can be conducted. To ease use, most blocks have debugging and logging capabilities that can generate traces of the simulation. You can read about the logging feature and how to use it on the [GNU Radio Wiki](http://gnuradio.org/doc/doxygen/page_logger.html).
## Unidirectional communication
As first over the air test I recommend to try ofdm_rx and ofdm_tx. Just open the flow graphs in GNU Radio companion and execute them. If it does not work out of the box, try to play around with the gain. If everything works as intended you should see similar output as in the loopback example.
## RX frames from a WiFi card
TBD
## TX frames to a WiFi card
TBD
## Transceiver (SDR <-> SDR)
TBD
## Ad Hoc Network with WiFi card
- The transceiver is currently connected to a TAP device, i.e. is a virtual Ethernet interface. Therefore, we have no WiFi signaling like association requests and hence, the transceiver can not "join" an ad hoc network. You have to make some small changes to the kernel in order to convince you WiFi card to send to this hosts nevertheless.
- The transceiver can not respond to ACKs in time. This is kind of an architectural limitation of USRP + GNU Radio since Ethernet and computations on a normal CPU introduce some latency. You can set the number of ACK retries to zero and handle retransmits on higher layers (-> TCP).
- RTS/CTS is not working for the same reason. You can however just disable this mechanism.
- Currently, there is no CSMA/CA mechanism, but this can be implemented on the FPGA.
# Troubleshooting
- Did you calibrate your daughterboard?
- Did you run volk_profile?
- Did you try different gain settings?
- Did you close the devices?
- Did you try real-time priority?
- Did you compile GNU Radio and gr-ieee802-11 in release mode?
- Did you try to tune the RF frequency out of the band of interest (i.e. used the LO offset menu of the flow graphs)?
- If 'D's appear, it might be related to your Ethernet card. Assert that you made the sysconf changes recommended by Ettus. Did you try to connect you PC directly to the USRP without a switch in between?
# Asking for help
In order to help you it is crucial that you provide enough information about what is going wrong and what you are actually trying to do. So if you write me please include at least the following
- OS (Ubuntu, OSX...)
- hardware (SDR and daughterboard)
- GNU Radio version
- What are you trying to do
- What is you setup, i.e. are you transmitting between SDRs or with WiFi cards.
- Bandwidth and frequency
- What did you already do to debug?
- Where exactly does it break, i.e. is frame detection working? Is the signal field decoded correctly?).
# Further information
For further information please checkout our project page
[http://www.ccs-labs.org/projects/wime/](http://www.ccs-labs.org/projects/wime/)