Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
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.edumailto: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.orgmailto:gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org] On Behalf Of Tom Rondeau Sent: Tuesday, October 18, 2011 7:24 PM To: j...@ettus.commailto:j...@ettus.com Cc: discuss-gnuradio@gnu.orgmailto: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.commailto: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
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
On Wed, Oct 19, 2011 at 6:39 AM, Nowlan, Sean sean.now...@gtri.gatech.eduwrote: 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
Right.. that's what I meant :) From: Tom Rondeau [mailto:trondeau1...@gmail.com] Sent: Wednesday, October 19, 2011 2:45 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 Wed, Oct 19, 2011 at 6:39 AM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 J I'm getting a network unreachable error on an E100 when trying to run benchmark_tx.py from the gnuradio next branch (Tom Rondeau?). 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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
On Tue, Oct 18, 2011 at 4:02 PM, Nowlan, Sean sean.now...@gtri.gatech.eduwrote: 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:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf Of *Marcus D. Leech *Sent:* Tuesday, October 18, 2011 6:30 PM *To:* discuss-gnuradio@gnu.org *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 J I’m getting a “network unreachable” error on an E100 when trying to run benchmark_tx.py from the gnuradio “next” branch (Tom Rondeau?). 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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
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. d*psk would do the right thing. Thanks, Sean P.S. - Thank you for your hard work moving the gnuradio examples to UHD! From: Tom Rondeau [mailto:trondeau1...@gmail.com] Sent: Tuesday, October 18, 2011 7:06 PM To: Nowlan, Sean Cc: Marcus D. Leech; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch On Tue, Oct 18, 2011 at 4:02 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu 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: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org] On Behalf Of Marcus D. Leech Sent: Tuesday, October 18, 2011 6:30 PM To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org 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 :) I'm getting a network unreachable error on an E100 when trying to run benchmark_tx.py from the gnuradio next branch (Tom Rondeau?). 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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
On Tue, Oct 18, 2011 at 4:18 PM, Nowlan, Sean sean.now...@gtri.gatech.eduwrote: 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. “d*psk” 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 *From:* Tom Rondeau [mailto:trondeau1...@gmail.com] *Sent:* Tuesday, October 18, 2011 7:06 PM *To:* Nowlan, Sean *Cc:* Marcus D. Leech; discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch ** ** On Tue, Oct 18, 2011 at 4:02 PM, Nowlan, Sean sean.now...@gtri.gatech.edu 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:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf Of *Marcus D. Leech *Sent:* Tuesday, October 18, 2011 6:30 PM *To:* discuss-gnuradio@gnu.org *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 J I’m getting a “network unreachable” error on an E100 when trying to run benchmark_tx.py from the gnuradio “next” branch (Tom Rondeau?). 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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ** ** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
On 10/18/2011 04:23 PM, Tom Rondeau wrote: 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). Yea, empty device address will find everything it can. And the first device found will be the one thats instantiated. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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.eduwrote: 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
