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

[Bahn William L Civ USAFA/DFCS]

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.

4) 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?

5) 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?

6) 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!