Understanding the c++ interface

GNU Radio
1

Hi,

I’m trying to understand the C++ interface to the USRP. I’ve read the
library files (usrp_{basic,standard}.h) and the test_usrp_standard_tx
and test_usrp_standard_rx scripts.

My current mission is to modify (or use?) these scripts to get the same
information out of the USRP that I put in. (Using Basic TX and Basic RX
on side A with a coax cable between them).

I run [test_usrp_standard_tx -f -F 0 -I 32], and then pull up
[usrp_oscope -d 32 -f 0] and the output on the scope looks good. I then
run [test_usrp_standard_rx -F 0 -D 32 -o usrp_rx_dump -M 1] to capture
1 MB of data from the USRP, but the file (seems to be) wrong - it only
contains the (signed short) 0 and -1=0xffff. I thought maybe there is
something wrong with the mux parameter (-1 seems to indicate all zeros
input?) and changed it to 0x33333333 but that didn’t work either.

I’ve also tried to mimic usrp_oscope.py and usrp_rx_cfile.py; I set the
gain to the average of the max and min gains (10.0 db). What am I
missing? Do I need to convolve the buffer returned by urx->read() with
another signal, for instance?

As an aside, is there a good reason the decimation/interpolation
arguments are not standardized across the various scripts? It’s hard to
remember whether the argument is -I, -i, -D, or -d… similar questions
apply to frequency arguments (-f vs. -F).

Thanks,

-Dan

2

Eric B. wrote:

The rx_mux value of -1 means “do the right thing”. It ends up setting
the mux to 0x32103210.

The tx_mux value of -1 means “do the right thing”. For the single
channel case it sets it to 0x0098.

Cool. Thanks!

I’ve also tried to mimic usrp_oscope.py and usrp_rx_cfile.py; I set the
gain to the average of the max and min gains (10.0 db). What am I
missing?

The basic_tx has very low output power.
Be sure to set the rx gain to its maximum value.

This seems to have fixed the problem.

Interesting. Does this mean that the python scripts are doing
daughterboard-specific cleverness to get good output even though they
report the gain to be 10db? (I intend to dive into the Python scripts in
the future to see what’s up, I just haven’t had time yet).

used much, and were almost dropped from the distribution because they
don’t know how to talk to the daugtherboards.)

Well then I’ll have to do just that :-).

Thanks for your help!

-Dan

3

On Tue, Nov 14, 2006 at 06:37:05PM -0800, Dan H. wrote:

Eric B. wrote:

The rx_mux value of -1 means “do the right thing”. It ends up setting
the mux to 0x32103210.

The tx_mux value of -1 means “do the right thing”. For the single
channel case it sets it to 0x0098.

Cool. Thanks!

You’re welcome!

The basic_tx has very low output power.
Be sure to set the rx gain to its maximum value.

This seems to have fixed the problem.

Good.

Interesting. Does this mean that the python scripts are doing
daughterboard-specific cleverness to get good output even though they
report the gain to be 10db? (I intend to dive into the Python scripts in
the future to see what’s up, I just haven’t had time yet).

Actually the RX side of the RFX daughterboards contains an additional
h/w gain control. We control all the gains with a single knob, since
the
daughterboard specific python code (db_*.py) knows how they should
work together.

From the python interface we export a couple of useful
methods:

u.subdev.gain_range() -> (min, max, step_size) # in dB (more or
less)
u.subdev.set_gain(g)

The gain_range returned is a function of the daughterboard to which
you are talking.

don’t know how to talk to the daugtherboards.)

Well then I’ll have to do just that :-).

Thanks!

Eric

4

On Tue, Nov 14, 2006 at 05:18:43PM -0800, Dan H. wrote:

Hi,

I’m trying to understand the C++ interface to the USRP. I’ve read the
library files (usrp_{basic,standard}.h) and the test_usrp_standard_tx
and test_usrp_standard_rx scripts.

OK. Note that these C++ programs don’t know how to control any of the
daughterboards. You’re probably OK with the basic tx and rx, since
there’s nothing to control, but you do lose the easy to use “tune”
function, easy handling of any daugtherboard in any slot, etc…

My current mission is to modify (or use?) these scripts to get the same
information out of the USRP that I put in. (Using Basic TX and Basic RX
on side A with a coax cable between them).

Any particular reason you’re not working Python?

I run [test_usrp_standard_tx -f -F 0 -I 32], and then pull up
[usrp_oscope -d 32 -f 0] and the output on the scope looks good. I then
run [test_usrp_standard_rx -F 0 -D 32 -o usrp_rx_dump -M 1] to capture
1 MB of data from the USRP, but the file (seems to be) wrong - it only
contains the (signed short) 0 and -1=0xffff. I thought maybe there is
something wrong with the mux parameter (-1 seems to indicate all zeros
input?) and changed it to 0x33333333 but that didn’t work either.

The rx_mux value of -1 means “do the right thing”. It ends up setting
the mux to 0x32103210.

The tx_mux value of -1 means “do the right thing”. For the single
channel case it sets it to 0x0098.

Are the tx and rx daughterboards both on the “A” side?

I’ve also tried to mimic usrp_oscope.py and usrp_rx_cfile.py; I set the
gain to the average of the max and min gains (10.0 db). What am I
missing?

The basic_tx has very low output power.
Be sure to set the rx gain to its maximum value.

Do I need to convolve the buffer returned by urx->read() with
another signal, for instance?

No.

As an aside, is there a good reason the decimation/interpolation
arguments are not standardized across the various scripts? It’s hard to
remember whether the argument is -I, -i, -D, or -d… similar questions
apply to frequency arguments (-f vs. -F).

The arguments are standardized across the python code. Please feel
free to submit a patch that makes these match the python code. (You
happen to be using two pieces of C++ code that were written at the
beginning of time to test early usrp functionality. They don’t get
used much, and were almost dropped from the distribution because they
don’t know how to talk to the daugtherboards.)

Thanks,

-Dan

Eric