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 mailto: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
On Wed, Oct 19, 2011 at 6:39 AM, Nowlan, Sean 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
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 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 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
Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch
On Tue, Oct 18, 2011 at 4:40 PM, Nowlan, Sean 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 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
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: 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 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
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 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:19 PM, Josh Blum 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 Tue, Oct 18, 2011 at 4:18 PM, Nowlan, Sean 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. “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 > 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
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 mailto: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: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 Marcus D. Leech Sent: Tuesday, October 18, 2011 6:30 PM To: discuss-gnuradio@gnu.org<mailto: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.org<mailto: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
On Tue, Oct 18, 2011 at 4: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. > > ** ** > > 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
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: 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 :) 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
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] 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 root@usrp-e1xx:/usr/local/share/gnuradio/examples/digital# ./benchmark_tx.py -f 9 --tx-amplitude=0.36 -v --tx-gain=0.0 -r 4 -m bpsk linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.003.000-e0a7b8a Traceback (most recent call last): File "./benchmark_tx.py", line 148, in main() File "./benchmark_tx.py", line 112, in main tb = my_top_block(mods[options.modulation], options) File "./benchmark_tx.py", line 49, in __init__ options.antenna, options.verbose) File "/usr/local/share/gnuradio/examples/digital/uhd_interface.py", line 135, in __init__ freq, gain, antenna) File "/usr/local/share/gnuradio/examples/digital/uhd_interface.py", line 51, in __init__ num_channels=1) File "/usr/local/lib/python2.6/site-packages/gnuradio/uhd/__init__.py", line 84, in constructor_interceptor return old_constructor(*args, **kwargs) File "/usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line 2003, in usrp_sink return _uhd_swig.usrp_sink(*args, **kwargs) RuntimeError: Network is unreachable linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.003.000-e0a7b8a -- Opening device node /dev/usrp_e0... -- Initializing FPGA clock to 64.00MHz... -- USRP-E100 clock control: 6 -- r_counter: 1 -- a_counter: 0 -- b_counter: 12 -- prescaler: 8 -- vco_divider: 2 -- chan_divider: 15 -- vco_rate: 1920.00MHz -- chan_rate: 960.00MHz -- out_rate: 64.00MHz -- -- Performing wishbone readback test... pass -- Found a Jackson Labs GPS -- Setting references to the internal GPSDO -- Initializing time to the internal GPSDO _ / | Device: E-Series Device | _ |/ | | Mboard: E100 (euewanee) | | vendor: 3 | | device: 1 | | revision: 4 | | content: 0 | | model: E100 | | serial: E2R11Y3E1 | | | | Time sources: none, external, _external_ | | Clock sources: internal, external, auto | | Sensors: ref_locked, gps_gpgga, gps_gprmc, gps_gpgsa, gps_time, gps_locked | | _ | |/ | | | RX DSP: 0 | | | Freq range: -32.000 to 32.000 Mhz | | _ | |/ | | | RX DSP: 1 | | | Freq range: -32.000 to 32.000 Mhz | | _ | |/ | | | RX Dboard: A | | | ID: RFX900 (0x0025) | | | Serial: E0R11X1R9 | | | _ | | |/ | | | | RX Subdev: 0 | | | | Name: RFX900 (0x0025) | | | | Antennas: TX/RX, RX2 | | | | Sensors: lo_locked, rssi | | | | Freq range: 750.000 to 1050.000 Mhz | | | | Gain range PGA0: 0.0 to 70.0 step 0.0 dB | | | | Connection Type: QI | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: A | | | | Name: ad9522 | | | | Gain range pga: 0.0 to 20.0 step 1.0 dB | | _ | |/ | | | TX DSP: 0 | | | Freq range: -32.000 to 32.000 Mhz | | _ | |/ | | | TX Dboard: A | | | ID: RFX900 (0x0029) | | | Serial: E0R11X1R9 | | | _ | | |/ | | | | TX Subdev: 0 | | | | Name: RFX900 (0x0029) | | | | Antennas: TX/RX | | | | Sensors: lo_locked | | | | Freq range: 750.000 to 1050.000 Mhz | | | | Gain Elements: None | | | | Connection Type: IQ | | | | Uses LO offset: Yes | | | _ | | |/ | | | | TX Codec: A | | | | Name: ad9522 | | | | Gain range pga: -20.0 to 0.0 step 0.1 dB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
