Re: [USRP-users] E320 numpy missing?
I've had similar problems since this post in March, and still waiting on a 'clean' way forwardhttp://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-March/059332.html In the interim I've done lots of cross-compiling and also stealing libraries/binaries from working E310 images; many of the included binaries seem gimped or a step down from what was on the E310. - Original Message - From: "Jason Matusiak" To:"Philip Balister" , "Ettus Mail List" Cc: Sent:Wed, 1 May 2019 14:40:16 + Subject:Re: [USRP-users] E320 numpy missing? I just double-checked and ENABLE_PYTHON is on in my system (which was apparently the default since I didn't spell it out in my cmake command). - FROM: Jason Matusiak SENT: Wednesday, May 1, 2019 10:36 AM TO: Philip Balister; Ettus Mail List SUBJECT: Re: [USRP-users] E320 numpy missing? I actually was using a .sh file from earlier in April, but pulling down the most recent: e3xx_e320_sdk_default-v3.13.0.2-20190415.zip, I still don't see pretty much any site-packages in the sysroot. Those things seem to be there automatically when using the .sh info with the e310 files. I will try including python in the cmake path (which I've never needed to do before), but is that going to be enough? I feel like the back-and-forth you and I had last year with the rocko build for the E310 were for pretty similar issues. But honestly, I need to look back at the emails for the exact issues at the time. - FROM: Philip Balister SENT: Wednesday, May 1, 2019 10:31 AM TO: Jason Matusiak; Ettus Mail List SUBJECT: Re: [USRP-users] E320 numpy missing? On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote: > I also get a "ImportError: No module named sip" when I try to run: uhd_siggen_gui > > So I think a few things might be missing from the cross-compile setup. I took a few minutes and looked at the current state of the BSP. It looks like you might have this image: https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb [1] I forget where numpy is the gnuradio dependency tree, but I'm going to guess if you enable python support in gnuradio (yes it might be possible to use gnuradio without python) you will need numpy to build/run. Philip > > > From: Jason Matusiak > Sent: Wednesday, May 1, 2019 8:46 AM > To: Ettus Mail List > Subject: E320 numpy missing? > > Finally got my E320 in and I cross-compiled a new setup. I tried to fire up my flowgraph (which works fine on an E310) and it is complaining about numpy missing. > > If I do a search from / on the E320, the only numpy that is showing up is: > /usr/include/boost/python/numpy > > If I do a search from a good E310 in / I see: > ./usr/lib/python2.7/site-packages/numpy > ./usr/lib/python2.7/site-packages/numpy/core/include/numpy > ./usr/lib/python2.7/site-packages/Cython/Includes/numpy > ./usr/include/boost/python/numpy > > > Back on the host machine, my E320 cross-compile prefix shows numpy: > ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy > > My good E310 prefix shows: > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy > > So, was numpy forgotten? Left out for a reason? I am going to attempt to build it by hand, but I have a fear that I am going to go down dependency hell with this and other missing packages that GR might want. > > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2] > Links: -- [1] https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb [2] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] How to periodically write files using USRP and GNUradio
Thanks Ali, I'll take a look at what you found with inconsistencies and see if I can hunt them down. On Wed, May 1, 2019 at 5:35 PM Ali Dormiani wrote: > Hello GhostOp14 and USRP users, > > Your oot blocks are amazing. They do exactly what we need in a clean way. > In testing, we have found that there are rare anomalies though (occur like > a rare Poisson process). > > 1. Sometimes the advanced file sink will create an empty file of 0 bytes. > > 2. Sometimes the state timer messes up. We avoid a runaway data capture by > using the 'max file size' parameter in the advanced file sink. > > Overall, this solution is very good and eliminates a lot of variables from > our experiments. All of our USRP devices are initialized once and > constantly stream data (only some of which is saved). Our phase calibration > is a lot more consistent now. > > Thank you again for providing these oot blocks on Github. My own custom > embedded python block was inelegant and inconsistent. > > Cheers, > > Ali > > > On Wed, May 1, 2019 at 6:19 AM GhostOp14 via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Morning everyone, not sure my note yesterday hit the list correctly so >> I'm trying again. >> >> Mark: I have a solution for you. I added a new block yesterday to >> gr-filerepeater (pybombs or github). There's now a state timer block >> that'll generate a message based on block-specified timing. Trigger time, >> cycle time, etc. gr-filerepeater also has a new file sink block I've added >> in the past couple of weeks specifically to address the same kind of >> problem. You can feed the timer msg out to the new sink msg in. The new >> block will then key off the state (1/0) in the msg metadata and start/stop >> writing to a file. You can specify a directory and a base file name, then >> every time a new file write is started it'll append a timestamp. Should >> exactly match up to what you're trying to accomplish. I'll post on the >> gnuradio list as well since they're gnuradio blocks. >> >> >> >> On Mon, Apr 29, 2019 at 8:24 PM Marcus D. Leech via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> On 04/29/2019 08:08 PM, Mark Wagner via USRP-users wrote: >>> > Hey all, >>> > >>> > I'd like to know how to write short files of streamed USRP data >>> > periodically using GNUradio. For instance, I'd like the USRP to >>> > automatically record 5 seconds of data every 10 minutes. It does not >>> > matter to me whether the USRP is constantly on and most of the data is >>> > being discarded, or if the USRP wakes up every 10 minutes to record >>> > the data before sleeping. Whichever is easiest to achieve is fine by >>> > me. Does anyone have experience doing this kind of thing? >>> > >>> > -Mark >>> > >>> > >>> > >>> > -- >>> > Mark Wagner >>> > University of California San Diego >>> > Electrical and Computer Engineering >>> > >>> > >>> If you're using Gnu Radio, you can simply use the file sink, and have it >>> record to "/dev/null" most of the time, then have something (perhaps via >>>the XMLRPC built-in feature) change the filename to whatever your >>> desired filename is, and then revert it back to "/dev/null". >>> >>> I think I said the same thing on the discuss-gnuradio mailing list a few >>> days ago. >>> >>> The usrp-users mailing list isn't the best place to ask Gnu Radio >>> questions, a question like this, which is inherently radio-type >>> agnostic, probably >>>belongs on the discuss-gnuradio mailng list, because it's more about >>> "how do I make Gnu Radio dance". >>> >>> >>> >>> ___ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >> ___ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] How to periodically write files using USRP and GNUradio
Hello GhostOp14 and USRP users, Your oot blocks are amazing. They do exactly what we need in a clean way. In testing, we have found that there are rare anomalies though (occur like a rare Poisson process). 1. Sometimes the advanced file sink will create an empty file of 0 bytes. 2. Sometimes the state timer messes up. We avoid a runaway data capture by using the 'max file size' parameter in the advanced file sink. Overall, this solution is very good and eliminates a lot of variables from our experiments. All of our USRP devices are initialized once and constantly stream data (only some of which is saved). Our phase calibration is a lot more consistent now. Thank you again for providing these oot blocks on Github. My own custom embedded python block was inelegant and inconsistent. Cheers, Ali On Wed, May 1, 2019 at 6:19 AM GhostOp14 via USRP-users < usrp-users@lists.ettus.com> wrote: > Morning everyone, not sure my note yesterday hit the list correctly so I'm > trying again. > > Mark: I have a solution for you. I added a new block yesterday to > gr-filerepeater (pybombs or github). There's now a state timer block > that'll generate a message based on block-specified timing. Trigger time, > cycle time, etc. gr-filerepeater also has a new file sink block I've added > in the past couple of weeks specifically to address the same kind of > problem. You can feed the timer msg out to the new sink msg in. The new > block will then key off the state (1/0) in the msg metadata and start/stop > writing to a file. You can specify a directory and a base file name, then > every time a new file write is started it'll append a timestamp. Should > exactly match up to what you're trying to accomplish. I'll post on the > gnuradio list as well since they're gnuradio blocks. > > > > On Mon, Apr 29, 2019 at 8:24 PM Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> On 04/29/2019 08:08 PM, Mark Wagner via USRP-users wrote: >> > Hey all, >> > >> > I'd like to know how to write short files of streamed USRP data >> > periodically using GNUradio. For instance, I'd like the USRP to >> > automatically record 5 seconds of data every 10 minutes. It does not >> > matter to me whether the USRP is constantly on and most of the data is >> > being discarded, or if the USRP wakes up every 10 minutes to record >> > the data before sleeping. Whichever is easiest to achieve is fine by >> > me. Does anyone have experience doing this kind of thing? >> > >> > -Mark >> > >> > >> > >> > -- >> > Mark Wagner >> > University of California San Diego >> > Electrical and Computer Engineering >> > >> > >> If you're using Gnu Radio, you can simply use the file sink, and have it >> record to "/dev/null" most of the time, then have something (perhaps via >>the XMLRPC built-in feature) change the filename to whatever your >> desired filename is, and then revert it back to "/dev/null". >> >> I think I said the same thing on the discuss-gnuradio mailing list a few >> days ago. >> >> The usrp-users mailing list isn't the best place to ask Gnu Radio >> questions, a question like this, which is inherently radio-type >> agnostic, probably >>belongs on the discuss-gnuradio mailng list, because it's more about >> "how do I make Gnu Radio dance". >> >> >> >> ___ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E320 numpy missing?
I just double-checked and ENABLE_PYTHON is on in my system (which was apparently the default since I didn't spell it out in my cmake command). From: Jason Matusiak Sent: Wednesday, May 1, 2019 10:36 AM To: Philip Balister; Ettus Mail List Subject: Re: [USRP-users] E320 numpy missing? I actually was using a .sh file from earlier in April, but pulling down the most recent: e3xx_e320_sdk_default-v3.13.0.2-20190415.zip, I still don't see pretty much any site-packages in the sysroot. Those things seem to be there automatically when using the .sh info with the e310 files. I will try including python in the cmake path (which I've never needed to do before), but is that going to be enough? I feel like the back-and-forth you and I had last year with the rocko build for the E310 were for pretty similar issues. But honestly, I need to look back at the emails for the exact issues at the time. From: Philip Balister Sent: Wednesday, May 1, 2019 10:31 AM To: Jason Matusiak; Ettus Mail List Subject: Re: [USRP-users] E320 numpy missing? On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote: > I also get a "ImportError: No module named sip" when I try to run: > uhd_siggen_gui > > So I think a few things might be missing from the cross-compile setup. I took a few minutes and looked at the current state of the BSP. It looks like you might have this image: https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb I forget where numpy is the gnuradio dependency tree, but I'm going to guess if you enable python support in gnuradio (yes it might be possible to use gnuradio without python) you will need numpy to build/run. Philip > > > From: Jason Matusiak > Sent: Wednesday, May 1, 2019 8:46 AM > To: Ettus Mail List > Subject: E320 numpy missing? > > Finally got my E320 in and I cross-compiled a new setup. I tried to fire up > my flowgraph (which works fine on an E310) and it is complaining about numpy > missing. > > If I do a search from / on the E320, the only numpy that is showing up is: > /usr/include/boost/python/numpy > > If I do a search from a good E310 in / I see: > ./usr/lib/python2.7/site-packages/numpy > ./usr/lib/python2.7/site-packages/numpy/core/include/numpy > ./usr/lib/python2.7/site-packages/Cython/Includes/numpy > ./usr/include/boost/python/numpy > > > Back on the host machine, my E320 cross-compile prefix shows numpy: > ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy > > My good E310 prefix shows: > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy > > So, was numpy forgotten? Left out for a reason? I am going to attempt to > build it by hand, but I have a fear that I am going to go down dependency > hell with this and other missing packages that GR might want. > > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E320 numpy missing?
I actually was using a .sh file from earlier in April, but pulling down the most recent: e3xx_e320_sdk_default-v3.13.0.2-20190415.zip, I still don't see pretty much any site-packages in the sysroot. Those things seem to be there automatically when using the .sh info with the e310 files. I will try including python in the cmake path (which I've never needed to do before), but is that going to be enough? I feel like the back-and-forth you and I had last year with the rocko build for the E310 were for pretty similar issues. But honestly, I need to look back at the emails for the exact issues at the time. From: Philip Balister Sent: Wednesday, May 1, 2019 10:31 AM To: Jason Matusiak; Ettus Mail List Subject: Re: [USRP-users] E320 numpy missing? On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote: > I also get a "ImportError: No module named sip" when I try to run: > uhd_siggen_gui > > So I think a few things might be missing from the cross-compile setup. I took a few minutes and looked at the current state of the BSP. It looks like you might have this image: https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb I forget where numpy is the gnuradio dependency tree, but I'm going to guess if you enable python support in gnuradio (yes it might be possible to use gnuradio without python) you will need numpy to build/run. Philip > > > From: Jason Matusiak > Sent: Wednesday, May 1, 2019 8:46 AM > To: Ettus Mail List > Subject: E320 numpy missing? > > Finally got my E320 in and I cross-compiled a new setup. I tried to fire up > my flowgraph (which works fine on an E310) and it is complaining about numpy > missing. > > If I do a search from / on the E320, the only numpy that is showing up is: > /usr/include/boost/python/numpy > > If I do a search from a good E310 in / I see: > ./usr/lib/python2.7/site-packages/numpy > ./usr/lib/python2.7/site-packages/numpy/core/include/numpy > ./usr/lib/python2.7/site-packages/Cython/Includes/numpy > ./usr/include/boost/python/numpy > > > Back on the host machine, my E320 cross-compile prefix shows numpy: > ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy > > My good E310 prefix shows: > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy > > So, was numpy forgotten? Left out for a reason? I am going to attempt to > build it by hand, but I have a fear that I am going to go down dependency > hell with this and other missing packages that GR might want. > > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E320 numpy missing?
On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote: > I also get a "ImportError: No module named sip" when I try to run: > uhd_siggen_gui > > So I think a few things might be missing from the cross-compile setup. I took a few minutes and looked at the current state of the BSP. It looks like you might have this image: https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb I forget where numpy is the gnuradio dependency tree, but I'm going to guess if you enable python support in gnuradio (yes it might be possible to use gnuradio without python) you will need numpy to build/run. Philip > > > From: Jason Matusiak > Sent: Wednesday, May 1, 2019 8:46 AM > To: Ettus Mail List > Subject: E320 numpy missing? > > Finally got my E320 in and I cross-compiled a new setup. I tried to fire up > my flowgraph (which works fine on an E310) and it is complaining about numpy > missing. > > If I do a search from / on the E320, the only numpy that is showing up is: > /usr/include/boost/python/numpy > > If I do a search from a good E310 in / I see: > ./usr/lib/python2.7/site-packages/numpy > ./usr/lib/python2.7/site-packages/numpy/core/include/numpy > ./usr/lib/python2.7/site-packages/Cython/Includes/numpy > ./usr/include/boost/python/numpy > > > Back on the host machine, my E320 cross-compile prefix shows numpy: > ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy > > My good E310 prefix shows: > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy > ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy > > So, was numpy forgotten? Left out for a reason? I am going to attempt to > build it by hand, but I have a fear that I am going to go down dependency > hell with this and other missing packages that GR might want. > > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E320 numpy missing?
I also get a "ImportError: No module named sip" when I try to run: uhd_siggen_gui So I think a few things might be missing from the cross-compile setup. From: Jason Matusiak Sent: Wednesday, May 1, 2019 8:46 AM To: Ettus Mail List Subject: E320 numpy missing? Finally got my E320 in and I cross-compiled a new setup. I tried to fire up my flowgraph (which works fine on an E310) and it is complaining about numpy missing. If I do a search from / on the E320, the only numpy that is showing up is: /usr/include/boost/python/numpy If I do a search from a good E310 in / I see: ./usr/lib/python2.7/site-packages/numpy ./usr/lib/python2.7/site-packages/numpy/core/include/numpy ./usr/lib/python2.7/site-packages/Cython/Includes/numpy ./usr/include/boost/python/numpy Back on the host machine, my E320 cross-compile prefix shows numpy: ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy My good E310 prefix shows: ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy So, was numpy forgotten? Left out for a reason? I am going to attempt to build it by hand, but I have a fear that I am going to go down dependency hell with this and other missing packages that GR might want. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] How to periodically write files using USRP and GNUradio
Morning everyone, not sure my note yesterday hit the list correctly so I'm trying again. Mark: I have a solution for you. I added a new block yesterday to gr-filerepeater (pybombs or github). There's now a state timer block that'll generate a message based on block-specified timing. Trigger time, cycle time, etc. gr-filerepeater also has a new file sink block I've added in the past couple of weeks specifically to address the same kind of problem. You can feed the timer msg out to the new sink msg in. The new block will then key off the state (1/0) in the msg metadata and start/stop writing to a file. You can specify a directory and a base file name, then every time a new file write is started it'll append a timestamp. Should exactly match up to what you're trying to accomplish. I'll post on the gnuradio list as well since they're gnuradio blocks. On Mon, Apr 29, 2019 at 8:24 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 04/29/2019 08:08 PM, Mark Wagner via USRP-users wrote: > > Hey all, > > > > I'd like to know how to write short files of streamed USRP data > > periodically using GNUradio. For instance, I'd like the USRP to > > automatically record 5 seconds of data every 10 minutes. It does not > > matter to me whether the USRP is constantly on and most of the data is > > being discarded, or if the USRP wakes up every 10 minutes to record > > the data before sleeping. Whichever is easiest to achieve is fine by > > me. Does anyone have experience doing this kind of thing? > > > > -Mark > > > > > > > > -- > > Mark Wagner > > University of California San Diego > > Electrical and Computer Engineering > > > > > If you're using Gnu Radio, you can simply use the file sink, and have it > record to "/dev/null" most of the time, then have something (perhaps via >the XMLRPC built-in feature) change the filename to whatever your > desired filename is, and then revert it back to "/dev/null". > > I think I said the same thing on the discuss-gnuradio mailing list a few > days ago. > > The usrp-users mailing list isn't the best place to ask Gnu Radio > questions, a question like this, which is inherently radio-type > agnostic, probably >belongs on the discuss-gnuradio mailng list, because it's more about > "how do I make Gnu Radio dance". > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] E320 numpy missing?
Finally got my E320 in and I cross-compiled a new setup. I tried to fire up my flowgraph (which works fine on an E310) and it is complaining about numpy missing. If I do a search from / on the E320, the only numpy that is showing up is: /usr/include/boost/python/numpy If I do a search from a good E310 in / I see: ./usr/lib/python2.7/site-packages/numpy ./usr/lib/python2.7/site-packages/numpy/core/include/numpy ./usr/lib/python2.7/site-packages/Cython/Includes/numpy ./usr/include/boost/python/numpy Back on the host machine, my E320 cross-compile prefix shows numpy: ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy My good E310 prefix shows: ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy So, was numpy forgotten? Left out for a reason? I am going to attempt to build it by hand, but I have a fear that I am going to go down dependency hell with this and other missing packages that GR might want. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Announcing NEWSDR at UMass-Boston on June 13/14
* *** NEWSDR 2019 *** Free Registration Offering technical Workshops, Symposium, Poster Presentations Call for Poster Presentations * NEWSDR 2019 New England Workshop on Software Defined Radio Ninth Annual Technical Workshops Thursday June 13 16:00 to 21:00 Symposium Friday June 14 08:00 to 17:00 University of Massachusetts at Boston 100 William T Morrissey Blvd Boston, MA, 02125, USA http://www.sdr-boston.org/ Free Registration * INVITATION TO PARTICIPATE You are cordially invited to the 2019 New England Workshop on Software Defined Radio (NEWSDR 2019), which is the ninth installment of an annual series of symposium and workshop events organized by the Boston SDR User Group (SDR-Boston). This year, NEWSDR will be held at University of Massachusetts at Boston. It consists of a day-long symposium on Friday, as well as several hands-on short courses the evening before on Thursday. You are welcome to attend either or both events, which are entirely free. Attendance is typically about 100 people, and attendees come from both academia and industry. * WORKSHOPS Thursday June 13 16:00 to 21:00 Agenda 16:00 to 17:00 Pizza/Soda and Attendee Networking 17:00 to 21:00 Workshop Events Two workshops are being offered in parallel: * (title and abstract coming soon!) by Analog Devices * "FPGA Programming on the USRP with the RFNoC Framework" by Ettus Research / National Instruments Analog Devices and Ettus Research will each run a short course the evening before the main event. Short courses are technical, practical, hands-on activities. Attendance is free, but advance registration is required. Free pizza and soda will be provided. Title: FPGA Programming on the USRP using the RFNoC Framework Abstract: The RFNoC (RF Network-on-Chip) software framework from Ettus Research is meant to decrease the development time for experienced FPGA engineers seeking to integrate IP into the USRP signal processing chain. RFNoC is the architecture for USRP devices that use Xilinx 7-series FPGAs (E310, E312, E320, X300, X310, N310, N320). RFNoC is built around a packetized network infrastructure in the FPGA that handles the transport of control and sample data between the host CPU and the radio. Users target their custom algorithms to the FPGA in the form of Computation Engines (CE), which are processing blocks that attach to this network. CEs act as independent nodes on the network that can receive and transmit data to any other node (e.g., another CE, the radio block, or the host CPU). Users can create modular, FPGA-accelerated SDR applications by chaining CEs into a flow graph. RFNoC is supported in UHD and GNU Radio. In this workshop, we will present an interactive hands-on tutorial on RFNoC, including a discussion on its design and capabilities, demonstrations of several existing examples, and a walk-through on implementing a user-defined CE and integrating the CE into both UHD and GNU Radio. Prerequisites: Attendees should have some previous experience with Linux and using the Linux command line, and basic familiarity with a programming language such as C, C++, or Python, and have basic understanding of fundamental concepts in DSP and RF. Attendees should also have some basic familiarity with Verilog. Extensive or deep experience with these topics is not necessary. Attendees do not have to bring any USRP radios or laptop computers. All necessary hardware and software will be provided in the workshop. Attendees may optionally bring their own laptops and/or radios for use in the workshop. Please contact "supp...@ettus.com" for specific setup and configuration requirements. * SYMPOSIUM Friday June 14 07:45 to 17:00 Tentative Agenda (check website next week for updates) 07:45 – 08:30 Registration, Coffee, Light Breakfast, Attendee Networking 08:30 – 08:45 Welcome and Introduction 08:45 – 10:15 Corporate Sponsor Presentations 10:15 – 11:00