Error running benchmark_tx.py from "next" branch

GNU Radio
#1

Perhaps this is the wrong place to post this error, but I’m hoping for a
quick response :slight_smile:

I’m getting a “network unreachable” error on an E100 when trying to run
benchmark_tx.py from the gnuradio “next” branch (Tom R.?). Command
line & error, and output of uhd_usrp_probe are attached.

Thanks!
Sean

#2

Probably needs a --args that tells UHD to go looking for the e100
interface, rather than whatever its default is.

Perhaps Josh can comment on the search order that UHD uses when you
don’t explicitly specify a device, and is that order
different on an e100?

#3

On Tue, Oct 18, 2011 at 4:02 PM, Nowlan, Sean
[email protected]wrote:

Sean

You’re right about the address–>args thing. I started doing all of this
on
a USRP N210, so it was always the systems IP address for me, so that’s
what
it became. Now, to remember all of the places where I did it and correct
for
it…

As for the auto-detection, I suppose it’s possible to tap into the UHD’s
find_devices feature and just default to the first one it finds as
opposed
to a static default. I’ll talk with Josh about doing this.

Tom

#4

I tried with the E100’s actual address and the loopback address
(127.0.0.1) and both worked. I should also say it’s a bit confusing to
call the command line switch “–address” when it’s actually handling the
arguments the same way as uhd_find_devices, etc. handle the “–args”
switch. For instance, I also got it to run with --address=“type=e100”.
Also it’d be nice (but not necessary) to have the program automatically
detect if it’s an E100 since it will never be controlling devices other
than itself.

Sean

From: [email protected]n.invalid
[mailto:[email protected]n.invalid] On
Behalf Of Marcus D. Leech
Sent: Tuesday, October 18, 2011 6:30 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from
“next” branch

Perhaps this is the wrong place to post this error, but I’m hoping for a
quick response :slight_smile:

I’m getting a “network unreachable” error on an E100 when trying to run
benchmark_tx.py from the gnuradio “next” branch (Tom R.?). Command
line & error, and output of uhd_usrp_probe are attached.

Thanks!
Sean

Probably needs a --args that tells UHD to go looking for the e100
interface, rather than whatever its default is.

Perhaps Josh can comment on the search order that UHD uses when you
don’t explicitly specify a device, and is that order
different on an e100?

–

Marcus L.

Principal Investigator

Shirleys Bay Radio Astronomy Consortium

http://www.sbrac.org

#5

On 10/18/2011 04:02 PM, Nowlan, Sean wrote:

I tried with the E100’s actual address and the loopback address
(127.0.0.1) and both worked. I should also say it’s a bit confusing
to call the command line switch “–address” when it’s actually
handling the arguments the same way as uhd_find_devices, etc. handle
the “–args” switch. For instance, I also got it to run with
–address=“type=e100”. Also it’d be nice (but not necessary) to have
the program automatically detect if it’s an E100 since it will never
be controlling devices other than itself.

I think this will help clear some things up:
http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps

So, e100 will not actually respond to the addr key. I believe that the
error stems from the usrp2 find routine trying to send a discovery
packet on the address that you specified, which may be invalid to do.

So I guess my question is, what device address arguments are being
passed into the uhd source/sink constructor?

I recommend using an empty device address. But if you have other usrps
attached to the e100 somehow, and you build uhd with support for those
usrps, you may want to specify type=e100 as a way to filter the other
devices.

-Josh

#6

On Tue, Oct 18, 2011 at 4:18 PM, Nowlan, Sean
[email protected]wrote:

Also in benchmark_tx.py I noticed that calling -m qpsk and -m bpsk
still default to their differential versions unless I explicitly use the
–non-differential switch. Was this intended? I assumed that specifying
psk vs. dpsk would do the right thing.

No intentional, and I thought I had it working correctly. It’s an issue
with
the OptionParser and having two options with the same name. They step on
each other. I need to figure out a better way to handle that.

Thanks,****

Sean****

P.S. Thank you for your hard work moving the gnuradio examples to UHD!

You’re welcome!

Tom

#7

Also in benchmark_tx.py I noticed that calling “-m qpsk” and “-m bpsk”
still default to their differential versions unless I explicitly use the
“–non-differential” switch. Was this intended? I assumed that
specifying “psk" vs. "dpsk” would do the right thing.

Thanks,
Sean

P.S. - Thank you for your hard work moving the gnuradio examples to UHD!

From: Tom R. [mailto:[email protected]]
Sent: Tuesday, October 18, 2011 7:06 PM
To: Nowlan, Sean
Cc: Marcus D. Leech; [email protected]
Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from
“next” branch

On Tue, Oct 18, 2011 at 4:02 PM, Nowlan, Sean
<[email protected]mailto:[email protected]> wrote:
I tried with the E100’s actual address and the loopback address
(127.0.0.1) and both worked. I should also say it’s a bit confusing to
call the command line switch “–address” when it’s actually handling the
arguments the same way as uhd_find_devices, etc. handle the “–args”
switch. For instance, I also got it to run with --address=“type=e100”.
Also it’d be nice (but not necessary) to have the program automatically
detect if it’s an E100 since it will never be controlling devices other
than itself.

Sean

You’re right about the address–>args thing. I started doing all of this
on a USRP N210, so it was always the systems IP address for me, so
that’s what it became. Now, to remember all of the places where I did it
and correct for it…

As for the auto-detection, I suppose it’s possible to tap into the UHD’s
find_devices feature and just default to the first one it finds as
opposed to a static default. I’ll talk with Josh about doing this.

Tom

From:
[email protected]n.invalidmailto:[email protected]
[mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan[email protected]mailto:[email protected]]
On Behalf Of Marcus D. Leech
Sent: Tuesday, October 18, 2011 6:30 PM
To: [email protected]mailto:[email protected]
Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from
“next” branch

Perhaps this is the wrong place to post this error, but I’m hoping for a
quick response :slight_smile:

I’m getting a “network unreachable” error on an E100 when trying to run
benchmark_tx.py from the gnuradio “next” branch (Tom R.?). Command
line & error, and output of uhd_usrp_probe are attached.

Thanks!
Sean

Probably needs a --args that tells UHD to go looking for the e100
interface, rather than whatever its default is.

Perhaps Josh can comment on the search order that UHD uses when you
don’t explicitly specify a device, and is that order
different on an e100?

–

Marcus L.

Principal Investigator

Shirleys Bay Radio Astronomy Consortium

http://www.sbrac.org

#8

On Tue, Oct 18, 2011 at 4:19 PM, Josh B. [email protected] wrote:

be controlling devices other than itself.
So I guess my question is, what device address arguments are being
passed into the uhd source/sink constructor?

I recommend using an empty device address. But if you have other usrps
attached to the e100 somehow, and you build uhd with support for those
usrps, you may want to specify type=e100 as a way to filter the other
devices.

-Josh

So does an empty string default to the first UHD device found? If so,
then
that solves the problem, and I’ll change all of the defaults to that
(along
with the change to args).

Tom

#9

One more thing - it looks like BITRATE refers to the USRP sample rate as
opposed to the bitrate of the modulation scheme. I think this is a
little confusing. Please correct me if I’m wrong with this math, using
QPSK as an example:

actual_bitrate = (2 bits/symbol) * 1/(SPS) * BITRATE, where
SPS=(samples/symbol) and BITRATE is the USRP sample rate.

Thanks,
Sean

From: [email protected]n.invalid
[mailto:[email protected]n.invalid] On
Behalf Of Tom R.
Sent: Tuesday, October 18, 2011 7:24 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from
“next” branch

On Tue, Oct 18, 2011 at 4:19 PM, Josh B.
<[email protected]mailto:[email protected]> wrote:

On 10/18/2011 04:02 PM, Nowlan, Sean wrote:

I tried with the E100’s actual address and the loopback address
(127.0.0.1) and both worked. I should also say it’s a bit confusing
to call the command line switch “–address” when it’s actually
handling the arguments the same way as uhd_find_devices, etc. handle
the “–args” switch. For instance, I also got it to run with
–address=“type=e100”. Also it’d be nice (but not necessary) to have
the program automatically detect if it’s an E100 since it will never
be controlling devices other than itself.

I think this will help clear some things up:
http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps

So, e100 will not actually respond to the addr key. I believe that the
error stems from the usrp2 find routine trying to send a discovery
packet on the address that you specified, which may be invalid to do.

So I guess my question is, what device address arguments are being
passed into the uhd source/sink constructor?

I recommend using an empty device address. But if you have other usrps
attached to the e100 somehow, and you build uhd with support for those
usrps, you may want to specify type=e100 as a way to filter the other
devices.

-Josh

So does an empty string default to the first UHD device found? If so,
then that solves the problem, and I’ll change all of the defaults to
that (along with the change to args).

Tom

#10

On Tue, Oct 18, 2011 at 4:40 PM, Nowlan, Sean
[email protected]wrote:

Thanks,****

Sean

I thought it was the bitrate; must have been another oversight when I
was
working on it. I’ll fix that, too.

Thanks for the bug reports (and useful suggestions)!

Tom

#11

On 10/18/2011 04:23 PM, Tom R. wrote:

–address=“type=e100”. Also it’d be nice (but not necessary) to have
packet on the address that you specified, which may be invalid to do.

So does an empty string default to the first UHD device found? If so, then
that solves the problem, and I’ll change all of the defaults to that (along
with the change to args).

Yea, empty device address will find everything it can. And the first
device found will be the one thats instantiated.

-josh

#12

I think I was wrong; it looks like “bitrate” is used in the expected way

  • to indicate the transmission bit rate. However the code doesn’t take
    bits-per-symbol into account in uhd_interface.py (line 70):

asked_samp_rate = bitrate * req_sps

Shouldn’t this be, “asked_samp_rate = bitrate * req_sps *
bits_per_symbol”?

Thanks for the bug reports (and useful suggestions)!

No problem!

Sean

From: Tom R. [mailto:[email protected]]
Sent: Tuesday, October 18, 2011 11:15 PM
To: Nowlan, Sean
Cc: [email protected]; [email protected]
Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from
“next” branch

On Tue, Oct 18, 2011 at 4:40 PM, Nowlan, Sean
<[email protected]mailto:[email protected]> wrote:
One more thing - it looks like BITRATE refers to the USRP sample rate as
opposed to the bitrate of the modulation scheme. I think this is a
little confusing. Please correct me if I’m wrong with this math, using
QPSK as an example:

actual_bitrate = (2 bits/symbol) * 1/(SPS) * BITRATE, where
SPS=(samples/symbol) and BITRATE is the USRP sample rate.

Thanks,
Sean

I thought it was the bitrate; must have been another oversight when I
was working on it. I’ll fix that, too.

Thanks for the bug reports (and useful suggestions)!

Tom

From:
[email protected]n.invalidmailto:[email protected]
[mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan[email protected]mailto:[email protected]]
On Behalf Of Tom R.
Sent: Tuesday, October 18, 2011 7:24 PM
To: [email protected]mailto:[email protected]
Cc: [email protected]mailto:[email protected]

Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from
“next” branch

On Tue, Oct 18, 2011 at 4:19 PM, Josh B.
<[email protected]mailto:[email protected]> wrote:

On 10/18/2011 04:02 PM, Nowlan, Sean wrote:

I tried with the E100’s actual address and the loopback address
(127.0.0.1) and both worked. I should also say it’s a bit confusing
to call the command line switch “–address” when it’s actually
handling the arguments the same way as uhd_find_devices, etc. handle
the “–args” switch. For instance, I also got it to run with
–address=“type=e100”. Also it’d be nice (but not necessary) to have
the program automatically detect if it’s an E100 since it will never
be controlling devices other than itself.

I think this will help clear some things up:
http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps

So, e100 will not actually respond to the addr key. I believe that the
error stems from the usrp2 find routine trying to send a discovery
packet on the address that you specified, which may be invalid to do.

So I guess my question is, what device address arguments are being
passed into the uhd source/sink constructor?

I recommend using an empty device address. But if you have other usrps
attached to the e100 somehow, and you build uhd with support for those
usrps, you may want to specify type=e100 as a way to filter the other
devices.

-Josh

So does an empty string default to the first UHD device found? If so,
then that solves the problem, and I’ll change all of the defaults to
that (along with the change to args).

Tom

#13

On Wed, Oct 19, 2011 at 6:39 AM, Nowlan, Sean
[email protected]wrote:

Shouldnt this be, asked_samp_rate = bitrate * req_sps * bits_per_symbol?

You almost got me… sample_rate = samps_per_sym * bitrate/bits_per_sym

I just pushed changes to ‘next’ that take care of this and change
address->args with an empty default.

Tom

#14

Right… that’s what I meant :slight_smile:

From: Tom R. [mailto:[email protected]]
Sent: Wednesday, October 19, 2011 2:45 PM
To: Nowlan, Sean
Cc: [email protected]; [email protected]
Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from
“next” branch

On Wed, Oct 19, 2011 at 6:39 AM, Nowlan, Sean
<[email protected]mailto:[email protected]> wrote:
I think I was wrong; it looks like “bitrate” is used in the expected way

  • to indicate the transmission bit rate. However the code doesn’t take
    bits-per-symbol into account in uhd_interface.py (line 70):

asked_samp_rate = bitrate * req_sps

Shouldn’t this be, “asked_samp_rate = bitrate * req_sps *
bits_per_symbol”?

You almost got me… sample_rate = samps_per_sym * bitrate/bits_per_sym

I just pushed changes to ‘next’ that take care of this and change
address->args with an empty default.

Tom