Re: [Discuss-gnuradio] implementing state flow

[Rahul Dhar]

On Thu, May 05, 2005 at 11:52:23AM -0700, Eric Blossom wrote:
> On Mon, May 02, 2005 at 04:07:04PM -0700, Richard Cagley wrote:
> > To implement MAC layer elements, i.e. waiting for data to arrive, is the
> > best strategy to program these elements in python? 
> 
> This is an area of active exploration.
> 
> Some are working in python, some with blocks in C++, some using the
> message and message queue abstractions.  It's not sorted out.
> 
> > Are there any example apps that implement packet modem like functionality?
> 
> Rahul, care to chime in here about your work?

I'm working on CSMA/CA-over-GNU Radio.  Here's a long-winded summary:

The end goal is an 802.11-like protocol (probably with relaxed timing
requirements), so CSMA/CA is a necessary first step.  To keep things
simple, I'm using wires (wireless will come...later)  The flowgraph
makes things very modular, and once you understand the programming
model, things fall into place nicely (Eric, thanks for you all your
help!)  GNU Radio provides message queues, which are very useful for
passing state information between blocks and also link subgraphs nicely.
Incidentally, I'm told the OSSIE project at Virginia Tech is compatible
with GNU Radio.  I'm not sure if that means the full platform or just
the USRP, though.

The main problems that I've encountered are lack of a good way to handle
timing and difficulty implementing physical carrier sensing.  Timing has
been mentioned a few times, and the consensus seems to be that it will
require some changes in GNU Radio.  Eric mentioned setting up something
running alongside the ADCs/DACs to do this (off-list discussion).  Until
then, I'm planning on hacking in something to emulate timeouts and
retransmissions.  In general, it's a bad idea to sleep in a block, but
if I set up the flowgraph right, I think I can get away with it.  Maybe
using SIGALRM will help also.  As already noted, keeping up with DIFS
and SIFS will be difficult because of the latency issues.  Putting some
of the MAC in the FPGA sounds promising, but what are the implications
for on-the-fly reconfigurationg?  How long would it take to reprogram
the FPGA if you needed to switch between 802.11a and b/g?

As for carrier sensing, I'm pretty sure I'm just not doing something
right and need to take another look at it (I'm wrapping up my thesis
right now, so I'm tied up with that).  Is there a way to shut of the Tx
port to make sure there's no carrier?  How long does it take to go back
to a ready-to-transmit state after it's been shut off?

-Rahul
-- 
Rahul Dhar
address@hidden
Actually, my goal is to have a sandwich named after me.

pgpCXQJIQdOas.pgp
Description: PGP signature