Transitioning Multi-Channel IEEE 802.15.4 Packet Capture¶¶

The paper that covers the design of this pipeline is located here:
http://nesl.ee.ucla.edu/fw/zigbee_capture/leslie_choong_multichannel_ieee802154.pdf

Components to setup:

• GNU Radio
• USRP2
• UCLA 802.15.4 code (gr-ucla)
• Wireshark

GNU Radio¶¶

Go to: http://gnuradio.org/trac/wiki/BuildGuide for instructions on building the latest trunk of GNU Radio. They have operating System specific instructions too. Might as well get USRP1 working too, which is at the bottom of those instructions.

The GNU Radio mailing list is also a great place to search for help or post questions. It is highly recommended to do a few searches of the list as many problems have been covered before. http://lists.gnu.org/archive/html/discuss-gnuradio/

It would also be a good idea to sign up with the list so you can get a sense of the current project development as they do not keep the homepage up to date all the time.

USRP2¶¶

Go to: http://www.gnuradio.org/trac/wiki/USRP2

The Usage FAQ has setup instructions for getting the USRP2 setup for the current trunk of GNU Radio. You must keep the FPGA AND Firmware up to date with latest trunk of GNU Radio. To do this they normally have the pre-compiled binary images of the FPGA and firmware available through: http://gnuradio.org/releases/usrp2-bin/trunk/ but check the instructions as this may change.

Gr-UCLA code¶¶

To use the multichannel code check it out from this projects repository. This includes LQI as well and will work with the Wireshark PHy layer I added.

git clone git://wiesel.ece.utah.edu/gr-ieee802-15-4.git

Build as usual
./bootstrap && ./configure && make sudo make install

Example programs in src/examples to try out are:
Single Channel:

cc2420_rxtest.py -c 18  # Single Channel Capture on Channel 18

cc2420_multichannel.py -c 16 -g 35 -s -52 # Multi-Channel Capture 5 Channels starting at Channel 16

cc2420_txtest_usrp2.py -c 18 # Single Channel transmit on channel 18

Wireshark¶¶

Wireshark is the packet dissection and analyzer engine that we can output to. It would be good to go to the developer's guide: http://www.wireshark.org/docs/wsdg_html_chunked/ and read about the architecture. They also have build instructions for the trunk. If you have a normal install of Wireshark then you may want to install your dev version to another place. Install the patched version as follows:

svn co -r r36719 http://anonsvn.wireshark.org/wireshark/trunk/ wireshark 
  cd wireshark
  ./autogen.sh
  patch -p0 -i wireshark_r36719_ieee802154_phy.diff
  ./configure --prefix=dirname
  make install

This will put the compiled wireshark in directory "dirname"

Note, in Ubuntu, install dependencies for wireshark:

sudo apt-get install libgtkmm-2.4-dev bison flex libpcap-dev

The patch is available at:
wireshark_r36719_ieee802154_phy.diff

The patch for Wireshark was done with Trunk revision 36719. However it may still work with the latest trunk. One thing to note is Wireshark's method of defining new Dissection layers (DLT). The base IEEE 802.15.4 dissection type is defined as: WTAP_ENCAP_IEEE802_15_4 and is located in trunk/wiretap/libpcap.c

The patch adds another physical layer which you can see in the patch. A merge might have conflicts if Wiretap adds another DLT type with the same number that I chose.

In addition to another dissection layer I modified trunk/gtk/iostat* for visualization statistics of the IO Statistics plugin.

Using the pipeline¶¶

Check the command line help notes for the scripts. You can normally change the gain, squelch filter level, and the output file name. The program output packets in the libpcap format (which is readable by Wireshark). I normally use named pipes to redirect the capture packet data directly into Wireshark for realtime capture:

rm /tmp/pipe
mkfifo /tmp/pipe
# Start wireshark end
sudo nice -n -5 /home/leslie/wireshark_build/bin/wireshark -k -i /tmp/pipe &
#start the packet capture script
sudo nice -n -20 ./cc2420_multichannelrx.py -c 16 -g 35 -s -52 -f /tmp/pipe

Special Notes¶¶

Some systems have trouble keeping up with the data rate that the USRP2 dumps samples over the link. To ensure that the system puts enough resources to the demodulator, try enabling realtime scheduling by running the script with sudo permissions. I also try nice-ing the process for a further boost:

sudo nice -n -20 ./cc2420_rxtest.py -c 18

In addition, the squelch level needs to be adjusted properly so that samples containing packet signals do not get dropped but that the machine doesn't get overloaded with samples (unless you have a burly machine). To check the proper squelch level you can use ./usrp2_fft.py to see the general noise level at the decimation you use. Note that the dB scale on the displayed graph is not correct, you can throw a squelch filter into the fft path to iteratively find the proper squelch level.

Testing the Pipeline¶¶

Use Telos motes programmed with a sample app like RadioCountToLeds or the Oscilloscope app.

Future Work¶¶

Find the sweet spot for gain: Motes placed further away (30 ft) are hard to pickup by the USRP2 at the normal gain of 35 dB. Increasing the gain seems to help, but then motes transmitting close (3 ft) get their samples clipped. So find the sweet spot between 35 -70 dB that allows good reception of both distant and proximal motes.

Add more channels: On a more powerful machine try to get 5 channels in 16-bit sample mode. Or try to switch the USRP2 to 8-bit sample mode, which allows us to capture up to 10 channels (if we can process it all!). Check with recent GNU Radio developments to see if this has been fully implemented.

Any questions can be directed to me (Leslie) at septikus@gmail.com or Thomas :)

USRP E1xx¶¶

There are a couple of things you will have to do to get this code working. Note that RX is currently not possible as the E1xx is too slow. We would need some optimization to make this work.

Installation¶¶

This is based on he Linux image found here http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/BootFiles#Linux-Kernel-Modules, more specifically http://dl.dropbox.com/u/14618236/modules-3.0-pm-r0d-usrp-e1xx.tgz.

For some reason, the Linux installation on the E100 decided to install gr-ucla into /usr/local/lib/python instead of /usr/lib/python. Just moving the files over fixes this. I am sure there is a better solution. Let me know if you figure it out.

Numpy instead of Numeric¶¶

Numeric is outdated, and really difficult to come by on a fresh installation. You can instead opt for numpy. Install numpy 1.6.2 on the E1xx. Note that if you get an error because of a sysroot setting, then go and remove the compiler setting for that in /usr/lib/python2.6/config/Makefile. Don't ask me why, but somehow numpy gets the value from there. Removing the sysroot parameter should fix the problem.

Next, you have to change the one import for import Numeric to import numpy.oldnumeric as Numeric.

Eventually, these changes might make it into the actual codebase.

UHD¶¶

The new USRPs use the UHD interface. Thus, you will have to use a new file called cc2420_txtest_uhd.py instead of the others.