[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] precise transmit scheduling: GNUradio state-of-th
Re: [Discuss-gnuradio] precise transmit scheduling: GNUradio state-of-the-art?
Wed, 11 Jul 2007 11:36:12 -0400
Thunderbird 188.8.131.52 (X11/20070604)
(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
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:
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
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.
Brad Karp wrote:
[Re-sending, as prior post appeared not to hit the list...]
I should preface this question by confessing that I'm new to the USRP
hardware and the gnuradio software. My students and I have only just
started hacking on 4 USRPs with 2.4 GHz daughterboards here in
lab. We'd like to use the platform to build a MAC protocol prototype.
As I know has been widely discussed in the gnuradio community,
link-layer acknowledgements require fairly precise timing of
transmissions. For example, the receiver of a data packet must delay a
very short interval before sending an ACK for the packet received
(e.g., on the order of 50 us).
What's the state of the art in precise scheduling of transmissions for
gnuradio? I'm looking for building blocks I can use that will allow
fairly precise scheduling of packet transmissions despite the 10 ms
process scheduling granularity of Linux.
I've seen in the archives of this list that BBN's work on m-blocks
appears at least partly motivated by precise scheduling of
transmissions. And other list traffic suggests that m-blocks are
being more broadly adopted; e.g., mail from Eric Blossom suggesting
that he was enhancing the m-block code further, perhaps with the
eventual goal of merging m-blocks into the core gnuradio distribution.
Is the m-block implementation in a state where my students and I could
use the code to schedule packet transmissions in the MAC protocol
Are there other implementations of precise packet transmit scheduling
anyone can point me to?
Discuss-gnuradio mailing list