[Top][All Lists]

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

Re: [Discuss-gnuradio] m-block timeouts, time passed, or

From: George Nychis
Subject: Re: [Discuss-gnuradio] m-block timeouts, time passed, or
Date: Thu, 24 Apr 2008 13:30:53 -0400
User-agent: Thunderbird (X11/20080227)

David Li wrote:
Hi George, I am interested in your MAC work. Does it run in the kernel or user
 space? Does it interact with IP?
Is there a branch that I can download and play with it? I have two USRP
 2400 boxes.

Hi David,

Put your reading glasses on.

To do MAC work in GNU Radio, you need to use the m-blocks which allow meta-data with message passing in the framework. They're extremely flexible blocks. These blocks have been officially released with GNU Radio and I have been using them for quite some time with no issues.

However, to do MAC work, you also need to use what we call inband signaling. This functionality is a work in progress within GNU Radio and is scheduled to be released with the next major GNU Radio release. The inband signaling functionality adds a control channel between the host and the USRP, as well as meta-data which as passed on the USB blocks of samples for tighter timing control for TDMA and such.

Additionally, my research group at CMU has made additional FPGA and host changes to support time-critical common MAC functionality in the FPGA, with completely control at the host using the control channel. It's sort of like an addon in terms of functionality of the in-band signaling. For example, we implement a 96 coefficient matched filter in the FPGA to support several things:

- squelching of samples to the host until a sequence is detected (prevents constant demodulation at the host, great for packet detection)

- generation of dependent packets --> for example, when a packet is detected in the FPGA and it's detected that its for this host, trigger the transmission of pending samples (like a pending ACK). This reduces ACK turnaround time, which in turn increases capacity. This could also be used to generate some sort of synchronization responses in TDMA quickly.

We also implement carrier sense on the board, with control by the host on a packet basis, to reduce the size of the carrier sense "blind spot" introduced by the bus latency.

Our goal has been to argue against the traditional streaming based architecture of software-defined radios, for a new architecture which can support MAC development.

There are 2 more "gotchas" in terms of GNU Radio. There is no m-block->grblock connection, which means you can't use 99% of what is in GNU Radio with the in-band work or our additional work so far. Lastly, there is no C++ daughterboard control which limits things even further. I wish I could give a timeline of this functionality being available, but I have no clue :)

Our group, with the help of Dan (another student at UW), has worked towards temporary work arounds while waiting on this functionality. We implemented a hacked up version of GMSK in an m-block, so its the only PHY currently supported, and we hacked up initialization of the daughterboards in python and passing the reference to our m-blocks via SWIG.

We have a simple file transfer application working on the USRP with any daughterboard using a basic CSMA protocol:

It does addresses, ACK's, ACK timeouts, and carrier sense. Some students in a class are working on extending it to random exponential backoff (fairness) and sequence numbers (ACK-loss resilience).

I'm also working on a TDMA MAC right now, sort of layed out here:

If you're interested in playing around with it until the missing GR functionality is implemented, you can contact me off list and I can pass you a series of patches. That's my own personal support towards my own work which I want people to use. Once it hits GNU Radio mainstream, then you will be able to find support on the list.

- George

reply via email to

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