On Tue, Oct 18, 2011 at 4:40 PM, Nowlan, Sean
<sean.now...@gtri.gatech.edu>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=gtri.gatech....@gnu.org[mailto:
> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org] *On Behalf
> Of *Tom Rondeau
> *Sent:* Tuesday, October 18, 2011 7:24 PM
> *To:* j...@ettus.com
> *Cc:* discuss-gnuradio@gnu.org
>
> *Subject:* Re: [Discuss-gnuradio] Error running benchmark_tx.py from
> "next" branch****
>
> ** **
>
> On Tue, Oct 18, 2011 at 4:19 PM, Josh Blum <j...@ettus.com> 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****
>
> ** **
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to