[Discuss-gnuradio] Re: in-band signaling project overview

[Jeff Brower]

George-

Ok, I get it.  Sounds very promising.

A couple of quick questions:

1) What about commands (meta-data) to help deal with latency?  For example, 'if 
you receive such-and-such request,
send this ACK'?

2) Does your new FPGA code require the next-gen USRP, with Spartan 3 FPGA?  My 
understanding is that capacity is very
limited in the Cyclone, which is an old FPGA (around yr 2002 time-frame).

-Jeff

> Hi all,
>
> I've gotten an e-mail asking what exactly is the in-band signaling
> project, and since I'm asking for people to help contribute... I think
> that's a fair question for me to answer :)
>
> Overview:
>
> We're making significant changes in GNU Radio and the USRP FPGA to
> create a control channel between the two to support packet processing.
>
> Previously, the USRP interpreted all data over the USB bus to it as
> samples.  GNU Radio blocks also only handled fixed length data with no
> meta-data.  This is a great architecture for streaming, but not for
> packet based radio.  You can't send samples to the USRP and say
> "transmit at time X,"  "before transmitting this packet, switch your
> center channel to Y," or "perform carrier sense before transmitting this."
>
> You also received no information about samples you were receiving, such
> as the RSSI or even just a timestamp when the samples were received.
> Requiring fixed length data between GNU Radio blocks again is ok for
> streaming, but one of the key aspects of packet processing is variable
> length data with meta-data like a priority, a timestamp when it should
> be transmitted, or simply anything you can come up with.
>
> BBN proposed and implemented with Eric a completely new GNU Radio block,
> the m-block, which supports variable length data and meta-data that you
> can read about here:
> http://acert.ir.bbn.com/downloads/adroit/gnuradio-architectural-enhancements-3.pdf
>
> It was really the first great step towards packet processing in the
> architecture.  But, it left the gap between GNU Radio and the USRP.
> There was still no per-packet control over the USRP.  That's where our
> in-band signaling work comes in.  All samples over the USB are now
> encapsulated within a new packet structure:
> http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb
>
> This allows variable length data between GR and the USRP, and it
> provides additional information about the samples.  We've modified the
> FPGA to now interpret these packets, parse them, and of course... do
> what they say :)  The timestamp field, for example, gives you much
> tighter timing.  You can send samples down with a timestamp and they are
> transmitted at that time.
>
> We also have carrier sense working, which is not really reflected in
> that packet structure yet, where you use in-band signaling command
> packets to write an RSSI threshold to a register and any packets that
> come down with the carrier sense flag the FPGA waits until the RSSI goes
> below the threshold to transmit.  We also built in a deadline feature
> where you can specify that the FPGA only wait X clock ticks before it
> throws the samples out and moves on.
>
> It's really opening up a whole new level of processing between GR and
> the USRP that truly facilitates wireless MAC protocol development,
> packet processing, per-packet control over the radio, and more precision
> scheduling for TDMA.
>
> If you have any other questions, just let me know!  We hope to
> officially release it soon after profiling, so again, we would
> appreciate any help :)
>
> - George
>