Re: [USRP-users] E320 numpy missing?

2019-05-01 Thread Chris Gobbett via USRP-users
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

2019-05-01 Thread GhostOp14 via USRP-users
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

2019-05-01 Thread Ali Dormiani via USRP-users
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?

2019-05-01 Thread Jason Matusiak via USRP-users
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?

2019-05-01 Thread Jason Matusiak via USRP-users
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?

2019-05-01 Thread Philip Balister via USRP-users
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?

2019-05-01 Thread Jason Matusiak via USRP-users
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

2019-05-01 Thread GhostOp14 via USRP-users
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?

2019-05-01 Thread Jason Matusiak via USRP-users
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

2019-05-01 Thread Neel Pandeya via USRP-users
*
*** 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