What is the simplest way to get data to/from the USRP

GNU Radio
1

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?

I have been told by several people (none of whom, as far as I know, have
actually played with SDR) that the basic idea behind SDR is that the
software receiver receives a time-domain stream of waveform data from
the hardware receiver, does whatever it wants with it, and then the
software transmitter generates a time-domain stream of waveform data
that it send to the hardware transmitter.

Assuming that this is the case, then what I would like to do sounds
perfectly suited to that process. I would like to capture a stream of
values that represent the successive samples from the receiver’s A2D,
process them in a C program, and send out a stream of values that
represent the success samples that I want the transmitter’s DAC to
generate. No bells or whistles. I am completely unconcerned about data
rate at this point - if it’s 1 Hz I will be happy (for now).

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:

I have two memory buffers, one for input from the receiver and one for
output to the transmitter.

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.

#1 - Do whatever setup is required to set sampling rates, etc.

  ??? What does need to be done?

#2 - Read/Process/Write loop

WHILE: forever

  SET: transfer = 0;

  WHILE: ((transfer < MAXRXTRANSFER)&&(ReceiverHasData())

        TransferFromReceiverToReceiveBuffer()

        transfer++;



  SET: processtime = 0;

  WHILE: ((processtime < MAXPROCESSTIME)

        ProcessDataFromReceiveBuffer ();

        GenerateDataToTransmitBuffer ();

        UpdateProcessTime(processtime);



  WHILE: ((transfer < MAXTXTRANSFER)&&(TransmitterHasRoom())

        TransferFromTransmitBufferToTransmitter()

        transfer++;

Does this sound like something that can be implemented using C (compiled
with gcc) and a minimum number of USRP/GNURadio function calls? What
would those calls be and where would I look for information on them?

For what I am eventually planning to do, this is the equivalent of Hello
World.

Thanks,

Bill

2

On Wed, Sep 20, 2006 at 06:31:54PM -0600, Bahn William L Civ USAFA/DFCS
wrote:

Assuming that this is the case, then what I would like to do sounds
perfectly suited to that process. I would like to capture a stream of
values that represent the successive samples from the receiver’s A2D,
process them in a C program, and send out a stream of values that
represent the success samples that I want the transmitter’s DAC to
generate. No bells or whistles. I am completely unconcerned about data
rate at this point - if it’s 1 Hz I will be happy (for now).

If you haven’t already, I suggest starting with “Exploring GNU Radio”
http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html

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 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.

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.

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.

Thanks,

Bill

Eric

3

On Wed, 2006-09-20 at 18:31 -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?

The simplest way to get raw data to/from the USRP is to use the GNU
Radio code!

If you haven’t already, check out Dawei Shen’s tutorials, and “How to
Write a Signal Processing Block.” These are a nice starting point in
addition to “Exploring GNU Radio.”

http://www.nd.edu/~jnl/sdr/docs/
http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html

-Lee

4

-----Original Message-----
From: Eric B. [mailto:[email protected]]
Sent: Wednesday, September 20, 2006 11:16 PM
To: Bahn William L Civ USAFA/DFCS
Cc: [email protected]
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
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.

5

I’m just getting back to this after a few months (gotta love funding
issues).

Brief recap on what I am trying to do: I am trying to perform some very
non-conventional signal processing. To show that our basic approach is
viable it is sufficient for us to perform the following tasks:

  1. Generate a waveform that we want to transmit. This waveform has data
    encoded into it. Ideally, the data is just a list of numbers that we
    want to send to a DAC. We can prepare this well ahead of time.

  2. Broadcast the waveform generated in the previous step.

  3. Receive the waveform that was broadcast and record it as a
    time-sampled sequence of numbers that represent the outputs of an ADC.

  4. Analyze the data and see if the information we embedded in the
    waveform is recoverable. This can be done completely off-line via
    post-processing.

The only part that we need GNUradio and/or the USRP for is #2 and #3.

Task #3:

Previously, Eric recommended 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

This looks very promising for taking care of Task #3. Playing around
with it has generated a few questions:

  1. What are the legal values of the decimation factor? I see a comment
    in the code that the minimum factor is 4 and that the default is 16. By
    experimentation I also observe that integer powers of two up to and
    including 256 are legal. What is the maximum decimation allowed? Other
    factors, such as 192, are permitted, but arbitrary values are not. Are
    there a certain number of most significant bits in the value that can be
    chosen?

  2. What does the FREQ parameter do? It clearly doesn’t set the sampling
    frequency - that appears to be a fixed 64 MSps divided by the decimation
    value.

  3. I see that the -R option allows be to chose which subdevice on the
    USRP, but how do I choose (or know which one if I can’t choose) which
    input on, say, the Basic-RX board is being used?

BTW: I think the duplicated nomenclature is confusing. On the BasicRX
daughterboard the two inputs are labeled RX-A and RX-B, so I thought
that the -R option was referring to this selection and was wondering how
you tell it which daughterboard to pull the signal from. It wasn’t until
I looked at an unpopulated USRP (since, with the four daughter boards
mounted on the USRP, the RX-A and RX-B labels are hidden) and noticed
that the daughterboard slots themselves use the same labels that I
realized what the -R option is really referring to.

  1. I see in the file that the data is stored (by default) as two single
    precision floating point numbers that represent a complex number.
    Clearly, then, this is not simply the output of the ADC. What is it? How
    do I (assuming I can) recover what the time-sequence of values coming
    out of the ADC were?

  2. What are the input tolerances of the BasicRX daughterboard? I have a
    function generator that I want to use to send a signal into it, but want
    to be sure that I don’t exceed the input range of the board? Also, what
    is the input impedance? Is it intended to be driven from a 50 ohm
    source?

  3. Perhaps the most important question: Where do I find the answers to
    the above questions? These all seem like really basic questions about
    the details of the interface, but I haven’t found anyplace that provides
    this information.

As far as Task #2:

  1. Is there any similar program in GNUradio that does the reverse of
    usrp_rx_cfile? Namely, takes a file of appropriately formatted
    time-sequence samples and broadcasts that waveform?

One issue I know that I need to deal with is what it means to
“broadcast” the waveform that was generated in Task #1. Ideally, at
least from a conceptual standpoint, the waveform data would represent
the actual output at the antenna so that (assuming 1-bit on-off
encoding) the sequence 0010001010 would result in three very sharp
chirps of energy being broadcast. Given the need for the USRP to perform
up-conversion, I know that this level of control is not possible (not to
mention the prohibitive bit rates that would be required). We can live
with that, but we want to get as close to that as we can.

Thanks!