discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: David Li
Subject: Re: [Discuss-gnuradio] m-block timeouts, time passed
Date: Fri, 25 Apr 2008 12:06:32 -0700

Hi George,

I browsed through cmac.cc and got a few questions: 

1. Can you explain more about "Without m block to gr block connection,
all raw samples are forced thru the MAC layer"?

2. What kind of applications are needed to interface with your MAC code
to do CS configuration and data transfer/receive? 

3. What are those PMT related macros? Perhaps it's easier if there
exists documentations explaining the current mblock implementation.  

The bottom line is this is interesting enough and I 'd like to give it a
try. You can email the directions to me offline.

Thanks.

- David


On Thu, 2008-04-24 at 13:30 -0400, George Nychis wrote:
> 
> 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:
> https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/browser/macs/cmusdrg_macs/trunk/src/lib/cmac.cc
> 
> 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:
> https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/wiki/TMAC
> 
> 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]