RE: [Discuss-gnuradio] What is the simplest way to get data to/from the USRP

[Bahn William L Civ USAFA/DFCS]

> -----Original Message-----
> From: Eric Blossom [mailto:address@hidden
> Sent: Wednesday, September 20, 2006 11:16 PM
> To: Bahn William L Civ USAFA/DFCS
> Cc: address@hidden
> Subject: Re: [Discuss-gnuradio] What is the simplest way to get data
> to/from the USRP
> 
> On Wed, Sep 20, 2006 at 06:31:54PM -0600, Bahn William L Civ
USAFA/DFCS
> wrote:
> > Assuming that I am ever able to actually establish communications
with
> > the USRP, what is the simplest way to get raw data to/from the USRP?
> >
> If you haven't already, I suggest starting with "Exploring GNU Radio"
> http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html
> 

I've read that and got the dialtone example to work (with the
soundcard).

> 
> > I am envisioning something really, really simple. Initially it can
even
> > be a brute force polled system that operates along the lines of the
> > following:
> 
> If you want to capture data from the front end and put it into a file,
> the easiest way is to use
gnuradio-examples/python/usrp/usrp_rx_cfile.py
>

I'm looking that one over. For parts of what I need to do initially,
that should suffice provided I capture a sufficiently long uninterrupted
stream of data.
 
> > I have two memory buffers, one for input from the receiver and one
for
> > output to the transmitter.
> 
> You're trying to operate at a _much_ lower level of abstraction than
> we usually work...
> 
> If want to work at that low level, you could consider using
> the C++ interface to the USRP (same one that GNU Radio uses
internally).
> 
> See usrp/host/lib/usrp_standard.h and usrp_basic.h for the interface.
> Note however, that if you work at this level, you lose the advantage
of
> all of the (python) code that knows how to talk transparently to the
> 11 kinds of RF daughterboards that are supported.  I wouldn't
> recommend this path.  I'm including it for completeness.  The basic
> i/o methods are called read and write.
> 

Thanks - that is probably where I will end up working for at least some
things.

> > I would like/hope/pray that there is some kind of construct that
allows
> > me to see if the USRP receiver has data for me and also whether the
USRP
> > transmitter can accept data from me.
> 
> It just streams data to and from you. Fundamentally GNU Radio is a
> data flow architecture.
> 
> For something somewhat similar to what you're trying to do, take a
> look at gnuradio-examples/python/audio/spectrum_inversion.py
> It uses an audio card for i/o, but the same idea applies to the USRP.
> 
> Spend some time with "Exploring GNU Radio" and take a look at
> gnuradio-examples/python/usrp/usrp_wfm_rcv_nogui.py for one of the
> simplest programs that actually does something interesting.  It's a
> wideband FM receiver.
> 
> 
> If you're looking for something that moves packets of data across the
> air, take a look at gnuradio-examples/python/gmsk2/tunnel.py.  Among
> other tricks, it can send IP packets between machines using the USRP.
>

Will look at all of these. 
 
> 
> > For what I am eventually planning to do, this is the equivalent of
> > Hello World.
> 
> If you tell us what you're really trying to do, someone may be
> able to suggest a suitable approach.

Fair enough. Unfortunately I'm really not in a position to disclose too
much about the end goals (nothing hush, hush secret or anything, just a
matter of obligations to release details in the proper order to the
proper people first to make the folks paying the bills happy). 

We actually have a couple of separate approaches we are hoping to
demonstrate using SDR. 

One would involve a sender using spread spectrum to send a message but
where the message is encoded via the sequence of spreading codes that
are used. The data is really just a marker and would most likely be
pseudorandom (or perhaps even truly random) noise. The sender would
broadcast the marker using the first code in the sequence (or perhaps
simultaneously transmit using the first N codes in the sequence) and
then, after a certain amount of time, shift to the next code(s) in the
sequence. The receiver is simply trying to determine if the sender is
sending something on one or more of a list of potential spreading codes.
Based on which codes are in use, the receiver can determine a new list
of codes to listen to for the next marker. So they need to be able to
listen to many codes (at some point, potentially a few thousand)
"simultaneously". It's fine to capture a data stream and then
sequentially examine it to see which codes are in use, although
eventually a highly parallelized system would be highly preferred. The
protocol can accommodate this by adjusting the marker's transmit
duration to permit adequate receiver processing time.

Another, completely different, approach is for the transmitter to send
out a sequence of very short chirps (bursts of noise) where the time
location of the chirps encodes the message. The receiver then determines
what those time locations are and, from that, reconstructs the message.

The last one is the one we want to implement first, but it lends itself
more to an Ultra Wide Band approach. To demonstrate the basic concept
using the USRP, I am thinking of two approaches. The first is to using
the BasicTX and BasicRX boards wired together to send chirps directly
from one system to another. But we also want to demonstrate that
wireless communication is actually possible using this protocol and so
what I am thinking of there is to use CW-OOK (essentially Morse code) to
emulate the chirps.