Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Tom Rondeau]

On Tue, Oct 18, 2011 at 4:40 PM, Nowlan, Sean <address@hidden> 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: discuss-gnuradio-bounces+sean.nowlan=address@hidden [mailto:discuss-gnuradio-bounces+sean.nowlan=address@hidden] On Behalf Of Tom Rondeau
Sent: Tuesday, October 18, 2011 7:24 PM
To: address@hidden
Cc: address@hidden

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

 

On Tue, Oct 18, 2011 at 4:19 PM, Josh Blum <address@hidden> 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