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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
