Hi,
(get your reading glasses on ;))
The m-block is the place to start, as it is completely motivated by what
you want to accomplish. The BBN document, which I think you’ve found,
details everything about the m-block which Eric has stuck pretty much
exactly to. The m-block is completely useable, as I’ve been using it
for the past couple of months now. I think it is supposed to be
released in 3.1. Eric has merged it in to the trunk.
I sent a similar mail to the mailing list that I wanted to build a MAC
protocol with tight timing issues, and the m-block is great on the GNU
Radio end for this… but the USRP and communication between it and GNU
Radio is not quite ready for it.
So what you want out of packet processing is variable length packets,
high priority packets, some packet level control over the radio, and the
ability for very precise scheduling of packets. The current FPGA code
is setup to be very ‘streaming’ based. GNU Radio communicates with the
USRP using fixed sized blocks which are interpreted completely as
samples, and streamed right out.
While the m-block can do variable length packets, prioritize packets,
set timestamps on packets, etc… the USRP has no clue what in the world
this is.
There is a strong need for a platform to completely build and evaluate a
mac protocol from scratch, and software-radios are great for it. Kind
of like SoftMAC, but a much cleaner slate to begin with. Wanting to
build a MAC on the platform, and the need for this… I decided to take
up the in-band signaling project with Eric, Thibaud, and Brian.
The goal of in-band signaling is to bridge the gap between GNU Radio /
m-block and the USRP. We’ve been working on it since February, and
we’re making nice progress.
I’ve been hacking up the GNU Radio end, creating an interface between
the application and the USRP. It is pretty close to useable. Right now
it can open a connection to the USRP under control of an m-block,
receive m-block packets and fragment them in to lower level USB blocks
to burst over the USB bus, interpret C/S packets, and receive data back
from the USB bus and recreate m-block packets.
Thibaud and Brian have done great work on the FPGA code… decoding the
new USB packets, reading the packet headers appropriately, stripping out
the data and transmitting it, and receiving samples and reconstructing
USB blocks and passing them back up to GNU Radio.
Documentation of the USB packets we are using to communicate are here:
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb
You’ll see that there are control status packets which will be used to
control the radio on a per packet basis or do register read/writes on
the USRP. I have implemented this functionality in GNU Radio, but the
FPGA code to parse these control/status packets are still being worked
on.
The other major thing that needs done is synchronization of a logical
timer between the USRP and GNU Radio. This is needed for timestamps.
Once the FPGA can interpret and send me back a ping response, I am going
to work on synchronizing the two.
All of the in-band code is being worked on in developer branches and
branches/features/inband-usb is where we merge our changes.
I have written some test applications for the basic TX and RX with
in-band signaling:
http://gnuradio.org/trac/browser/gnuradio/branches/developers/gnychis/inband/usrp/host/apps/test_usrp_inband_tx.cc
http://gnuradio.org/trac/browser/gnuradio/branches/developers/gnychis/inband/usrp/host/apps/test_usrp_inband_rx.cc
The TX application is written as m-blocks where it generates a sine wave
and builds m-block packets, then passes these packets to USRP server
which does all the in-band signaling magic. It’s a great example of how
the m-block works and how it communicates with in-band signaling.
Likewise, the RX reads incoming samples. Using two USRPs, the TX
application can transmit a sine wave, and the RX application can receive
the sine wave… all using the in-band signaling. All transmissions are
timestamped as ‘NOW’ (0xffffffff).
As for the FPGA code, I don’t think that we have an RBF file somewhere
in the repository to use. Thibaud and Leo have been custom building
them from code in their developer branches. If you are keen on using
it, I can have them build an RBF for you.
So in summary, we’re close… we’re very close. But it’s not complete.
I would think by the beginning of August we will have something
working pretty nicely.
If you have any questions feel free to contact me… there are tons of
details that I’m kind of glossing over but we can definitely discuss.