Machines:

Currently, all ten of the machines in Sieg 327 are now fully equipped with network-enabled computers and USRP devices. They are patagonian, gibson, atacama, ogaden, nubian, greatbasin, tanami, sechura, simpson, and altpiplano.

Equipment reservations: I've created each USRP board (and the associated machine) as a visitor on reserve. Unfortunately, the reservation system does not span 24 hours but rather 7am-7pm, so we'll have to find a work around for evening hours.

Initial setup:

I have created accounts on the lab machines for each of the class groups. The account names and passwords are in your e-mail inboxes. I also set up a CVS repository on the department webservers so that each group can easily keep its code synchronized. The 10 lab machines do not share hard drive space, and since they are class-managed (read: we get root access to the USB port, necessary for this project), the department will not support them. The repositories are located in /homes/gws/dhalperi/cse561_wi07_cvs with one repository for each group.

Each repository already contains a copy of the initial revision of the project code, also available here. To check it out, use the following command:

• CVSROOT=':extssh:USERNAME@kishwoot.cs.washington.edu:/homes/gws/dhalperi/cse561_wi07_cvs/cse561GROUP' cvs checkout echo

• CVSROOT=':ext:USERNAME@kishwoot.cs.washington.edu:/homes/gws/dhalperi/cse561_wi07_cvs/cse561GROUP' cvs checkout echo

• cvs -d ':ext:USERNAME@kishwoot.cs.washington.edu:/homes/gws/dhalperi/cse561_wi07_cvs/cse561GROUP' checkout echo

where you have replaced USERNAME with your own *CSE* username and GROUP with your group letter (in lowercase). You should know your group letter from the email "Lab machines and accounts", sent Jan 9.

Now, from inside the echo folder, you can run cvs update, cvs add, cvs checkout, and all your favorite CVS commands without needing to include the CVSROOT string in the first checkout command. You may, however, need to edit the CVS/Root file and replace the USERNAME in the extssh line.

Getting started:

The first thing you should do is run the echo program:

• ./echo.py -f 2.462G -r 250k (for wireless)
• ./echo.py -f 25M -r 250k (for wired)

The choice of 25 MHz for the wired situation is completely arbitrary, but it works; the basic boards can do frequencies between 0 and 44 MHz, but I think they get a little iffy at the higher end of the spectrum.

If you run the same command on each of two machines, they will be able to communicate over the air. Type some text and push enter; you will see output that looks like this:

text
Tx: len(payload) =    5
c66cc66cc66cc66cacdda4e2f28c20fc00050005746578740a55555555555555

• c66cc66cc66cc66cacdda4e2f28c20fc00050005746578740a55555555555555

  This is what is known as the preamble. It is typically a string of ones and zeros evenly mixed that is used to help the receiver's automatic gain control (dynamic adjustment of the amplitude of the received symbol) lock onto the right level to be able to decode a transmission.

• c66cc66cc66cc66cacdda4e2f28c20fc00050005746578740a55555555555555

  This is what is known as the access code. It is the pre-agreed-upon signal that lets a receiving node know that a packet is coming as opposed to random noise.

• c66cc66cc66cc66cacdda4e2f28c20fc00050005746578740a55555555555555

  This is simply the length of the packet payload, encoded in hex, repeated twice.

• c66cc66cc66cc66cacdda4e2f28c20fc00050005746578740a55555555555555

  This the packet payload itself; 't' = '0x74', 'e' = '0x65', 'x' = '0x78', and '0x0a' is the newline at the end.

• c66cc66cc66cc66cacdda4e2f28c20fc00050005746578740a55555555555555

  In order to transmit the raw data over the USB bus to the USRP, we need to ensure that it is sent in 512-byte chunks. The code automatically appends extra '0x55' characters to the end to ensure that this happens. Note that this is 512 bytes of signal samples after modulation, not necessarily 512-byte packets.

Understanding the code:

There are four main components of this program: echo.py, transmit_path.py, receive_path.py, and dbpsk.py.

• echo.py

  This file parses command line options, instantiates the receive_path and transmit_path objects which handle sending data to and receiving data from the USRP, and also contains the MAC and control loop of the program.

  The MAC is a simple CSMA (Carrier-Sense Multiple Access) protocol; when getting ready to send a packet, if the program senses signal above a certain threshold on the airwaves, it assumes that someone else is sending and delays.

• transmit_path.py

  This file instantiates the signal processing blocks necessary for transmitting data from the USRP. It first makes a gr.usrp_sink_c object. This is a sink of complex samples; the input to this blocK is passed directly to the USRP and sent over the air. The input to the USRP sink is an instance of the modulator class; this class modulates the signal, turning bytes into complex signals to be passed to the USRP. Finally, the input to the modulator class is a queue, which the control loop in echo.py fills when it receives data to transmit.

  After instaniating all blocks, the transmit path connects them all together using a flow_graph object fg.

  fg.connect(...) takes a list of signal processing blocks and connects them serially. Important: When looking at any particular bit of code, it will help immensely to search for places where the connect function is called; this will help you to understand the flow of data in the program.

• receive_path.py

  This file instantiates the signal processing blocks necessary to receive data from the USRP. Note that it is substantially more complicated than the transmit path. Understanding the different signal processing blocks in this program and how they are connected is left as an exercise to help you gain a better understanding of the GNU Radio coding style. I will be happy to answer questions once you've given it a shot. As a hint, the probe object is not used in this file, but in echo.py. Why is it set up here?

• dbpsk.py

  This file implements Differential Binary Phase Shift Keying. This is basically Binary Phase Shift Keying, except that we only encode the transitions between bits rather than each bit individually. DBPSK is considerably simpler to implement than BPSK, but has lower performance; see Sklar Chapter 3.6 for a reference. Be sure to at least get a handle on what the big idea of each of the signal processing blocks used in this file are, and why each block appears in a certain location in a certain path (modulation vs demodulation). This will help you understand better the workings of the physical layer.

Example code:

The GNU Radio project has implemented a large set of examples and a large library of signal processing blocks. I have posted a zipped package of their code tree here. The two most important directories are:

• gnuradio/gnuradio-examples/python/usrp, which contains many USRP examples including an oscilloscope (usrp_oscope.py), a spectrum analyzer (usrp_fft.py), and a signal generator (usrp_siggen.py), among other things.

• gnuradio/gnuradio-core/src/lib/, which contains the C++ implementations of the signal processing blocks.

Additionally, you can obtain a list of the signal processing blocks by looking in /usr/local/include/gnuradio.

Stage 1:

Stage 1 requires that you design and implement (efficient) reliable communication between two software radios. Note that the provided codebase does not implement communcation between two software radios; it merely implements two broadcast links. Part of this phase is having a working two-way channel that, for instance, one could transmit a file over and know that it was received correctly and in full.

The second part of Stage 1 asks that you improve upon the physical layer in some way. The sky's the limit!

Have fun! Work early, work often! I'll be checking email regularly for questions, and feel free to hunt me down (in Sieg 327, or in CSE 391) if you have questions.