Re: [Discuss-gnuradio] precise transmit scheduling: GNUradio state-of-the-art?

[George Nychis]

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.

- George


Brad Karp wrote:
> [Re-sending, as prior post appeared not to hit the list...]
>
> Greetings, all.
>
> 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).
>
> My question:
>
> 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
> we're implementing?
>
> Are there other implementations of precise packet transmit scheduling
> anyone can point me to?
>
> Many thanks,
> -Brad
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio