discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] USRP in-band signaling


From: Eric Blossom
Subject: [Discuss-gnuradio] USRP in-band signaling
Date: Sun, 4 Feb 2007 13:37:00 -0800
User-agent: Mutt/1.5.9i

On Wed, Jan 31, 2007 at 08:43:22PM +0000, George Nychis wrote:
> Eric Blossom wrote:
> > On Mon, Jan 29, 2007 at 07:31:43PM -0500, George Nychis wrote:
> >> Hey Eric,
> >>
> >> Is this still on track to finish by the end of the month?
> >>
> > It's pretty close, but could be a week late.  That's for the
> > fundamental mblock support.  
> > 
> > It'll take longer to get the USRP in-band signaling (and precision
> > timing) working.
> > 
> 
> That's a step forward :)
> 
> So I have a question, and am looking for your opinion.
> 
> [ Project on Detailed MAC ]
> I am working with another student on building a more detailed MAC
> protocol for packet based applications on the GNU Radio platform and
> USRP.  We have found two projects which got sort of a stop and wait MAC
> working, one of which was done here and the other is here:
> http://typo3.cs.uni-paderborn.de/en/research-group/research-group-computer-networks/projects/gsr.html

Good.

> We are looking to take these MAC's to the next level and get fine
> grained timeouts, exponential backoff, rate adaptation... etc.

Great.  We need that stuff!

> [ Can we Help w/Signaling & Timing ]

> As you mentioned, its going to take longer for USRP in-band signaling
> and precision timing to be done.  How much work is this and what kind of
> knowledge does it require?  Considering our goal is to build a base MAC
> first, with the long term goal of modifying it and making improvements,
> we can't get much further without this functionality.  Therefore we were
> wondering if we should and can help with this?
> 
> Let us know what you think!
> 
> - George

Implementing the in-band signaling is going to require substantial
changes to the USRP verilog code and the host library.  It may require
some minor tweaks to the FX2 firmware, but not much.  Mostly we're
going to be removing functionality from the FX2 firmware.

You'll need to understand from a high-level point of view how the
existing host, fx2 and fpga code interact.  Otherwise it's going to be
tough sledding ;)

You're almost certainly going to need access to a logic analyzer to
debug the new code in the FPGA.

The low-level details of getting data across the USB won't change.
That is, we'll continue to use the fusb.h interface, and will
communicate between the host and FX2 using fixed-length 512 byte USB
packets.  Likewise, we'll keep the exact same method for bursting
packets between the FX2 and FPGA over the GPIF bus.  The
interpretation of the contents of the packets on the FPGA will be
different, but the low level details related to flow control will
remain unchanged.

I suspect that starting on the host side we'll create a new base class
similar to usrp_basic (possibly by refactoring it) that will support
the in-band signaling.

I think we're going to end up with a new hierarchy of classes on the
host, but it would be nice if we can avoid changing the interfaces to
the various methods.  The implementations will change, but we want to
avoid gratuitous interface changes.

Since virtually all commands (exceptions: loading firmware into the
FX2 using endpoint zero, could be others related to I2C and/or SPI)
will be in-band in the TX stream on endpoint 2, and all responses will
be in-band in the RX stream on endpoint 6, there may need to be a
separate process that handles muxing/demuxing of commands and status
from the logical Tx and Rx high-level users to the USB connection to
the USRP.  That is, we want to retain the ability to have separate (or
the same) processes open either or both the logical Tx and Rx paths.

If this sounds within your comfort (or stretch) zone, let me know, and
Matt and I will spend some time working out a proposed format for the
packets across the wire.  It's a non-trivial piece of work, but with
two of you working on it, it should go pretty quickly, and you'll
learn a lot besides ;)

FYI, I've taken the liberty of copying the list on this response.
This is a good conversation to have in public.  There may be
collaborators lurking!

Eric




reply via email to

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