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 Rondeau [mailto:trondeau1...@gmail.com] Sent: Tuesday, October 18, 2011 11:15 PM To: Nowlan, Sean Cc: j...@ettus.com; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch On Tue, Oct 18, 2011 at 4:40 PM, Nowlan, Sean <sean.now...@gtri.gatech.edu<mailto: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:gtri.gatech....@gnu.org> [mailto:discuss-gnuradio-bounces+sean.nowlan<mailto:discuss-gnuradio-bounces%2Bsean.nowlan>=gtri.gatech....@gnu.org<mailto:gtri.gatech....@gnu.org>] On Behalf Of Tom Rondeau Sent: Tuesday, October 18, 2011 7:24 PM To: j...@ettus.com<mailto:j...@ettus.com> Cc: discuss-gnuradio@gnu.org<mailto: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<mailto: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
