[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] precise transmit scheduling: GNUradio state-of-th

From: George Nychis
Subject: Re: [Discuss-gnuradio] precise transmit scheduling: GNUradio state-of-the-art?
Date: Wed, 11 Jul 2007 11:36:12 -0400
User-agent: Thunderbird (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 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:

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:

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,

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]