Trouble understanding the Constellation Receiver block parameters

[Jason Matusiak]

I am working on a custom BPSK packet-based TX/RX flowgraph(s) and the TX side 
seems to operate pretty well and is fairly clean, but the receive side is where 
I have a question.  I was attempting to use the Constellation Receiver block, 
but I am having trouble understanding the minimum/maximum freq deviation 
parameters.  My stream going into the block seems pretty good, and I am pretty 
happy with everything I've done up to that point, but the stream coming out 
just does not look great.  It really seems like the block is distorting things 
somehow, and I have a suspicion that those two parameters are to blame.  
Unfortunately, you can only find a few references to that block online, and it 
is usually people asking the same question I am, but without a resolution.  I 
can tell when I've tweaked the parameters so badly that everything goes 
sideways, but I am basically imperially testing it, and it feels like that is 
hoping that a shot-in-the-dark is going to hit.

Since they are normalized, are they normalizing 2*pi to 1?  I've seen some 
examples where the minimum was a negative number, but it seems like if that was 
what was needed, it would be symmetrical about zero and you wouldn't need to 
inputs, just one number that would be the +/-.   Does anyone have any real 
experience with this block and might have some insights?  I am using a pair of 
N320s to transmit and receive this BPSK signal that is fairly infrequent (think 
a small burst once a second).

get_tags_in_range vs get_tags_in_window

[Jason Matusiak]

I have a block that is making heavy use of tags: reading, reacting, and adding 
in new tags.  It seems like this block might be a little costly processor 
resource wise.  I am currently using get_tags_in_range, so I was wondering if 
there was a cost benefit to go with get_tags_in_window instead?

If it matters, this is a general_work block where I am taking in X samples, 
stuffing in random samples if there were any drops detected (to make up for 
them), and outputting Y samples.  The block isn't that complicated, but there 
is significant tag manipulation, and I think that that is costing me some.

Question on dropped samples

[Jason Matusiak]

I was working on a block that I thought was going to be super simple, but have 
now realized that there are a lot of little corner cases that make it tougher 
than first glance.

Basically, I want to fill in the dropped samples in a stream. So if I happen to 
have a usrp stream and get a new tag, and I realize that 6 samples were lost, I 
would like to stuff 6 dummy samples into place, and adjust the downstream tags 
accordingly.

It isn't "hard", but knowing that you have x samples in your work function, 
that you have y samples dropped, stuffing those in, but making sure that you 
don't put more samples than noutput can handle, and then adjusting all future 
tags accordingly starts to become a lesson in records management.

Does anyone know of something out there that already does this? Or maybe how I 
am way overcomplicating it.

Question on tags from multiple streams

[Jason Matusiak]

I noticed something with respect to tags that I am trying to hunt down.  This 
may end up making more sense on the USRP mailing list, but I figured I would 
try here first since tags are a GR thing.

I've noticed that if I have a simple flowgraph of a USRP block with two RX 
channels, if I change one of the frequencies, a tag is generated on both 
streams.  I believe that the act of changing a frequency cause there to be 
dopped samples, so it would make sense that there is a tag for that stream (not 
to mention that the new frequency needs to be conveyed).  But I am not sure why 
GR is generating a tag on the second stream as well.  Maybe the way the USRP 
handles the streams it ends up dropping samples on both to keep things in sync, 
but I wasn't sure if GR was doing something here instead.

Re: rational resampler fractional bandwidth error

[Jason Matusiak]

That did the trick, thanks Jeff.

rational resampler fractional bandwidth error

[Jason Matusiak]

It has been a while since I have worked with GNUradio, but I am poking around 
with it again and having some issues.  I am currently using v3.8 on an Ubuntu 
machine.

I was trying to get a custom flowgraph to work and ran up against an error for 
the rational resampler.  I then pulled out the  fm_rds_alternate.grc example 
from gr-rds and found the exact same issue.  Basically, if I use the stock 
flowgraph, when I try to run it, I get the following error:

Traceback (most recent call last):
  File "/opt/gnuradio/v3.8/src/gr-rds/examples/fm_rds_alternate.py", line 784, 
in 
main()
  File "/opt/gnuradio/v3.8/src/gr-rds/examples/fm_rds_alternate.py", line 760, 
in main
tb = top_block_cls()
  File "/opt/gnuradio/v3.8/src/gr-rds/examples/fm_rds_alternate.py", line 548, 
in __init__
fractional_bw=0)
  File 
"/opt/gnuradio/v3.8/lib/python3/dist-packages/gnuradio/filter/rational_resampler.py",
 line 150, in __init__
interpolation, decimation, taps, fractional_bw)
  File 
"/opt/gnuradio/v3.8/lib/python3/dist-packages/gnuradio/filter/rational_resampler.py",
 line 113, in __init__
taps = design_filter(interpolation, decimation, fractional_bw)
  File 
"/opt/gnuradio/v3.8/lib/python3/dist-packages/gnuradio/filter/rational_resampler.py",
 line 46, in design_filter
raise ValueError("Invalid fractional_bandwidth, must be in (0, 0.5)")
ValueError: Invalid fractional_bandwidth, must be in (0, 0.5)

>>> Done (return code 1)

Did something maybe change with the rational resampler and I need to update 
older flowgraphs?  Using a value of 0.4 allows it to run, but I am not sure if 
that is an acceptable value when it was previously set to zero (it would 
appear).

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[Jason Matusiak]

urce - WARNING - Build dir already exists:
 /home/eexmmlo/prefix/default/src/gnuradio/build
 Building: (100%) [=
 
 ]
 [ 4%] Built target volk_obj
 [ 4%] Built target volk
 [ 4%] Built target volk_test_all
 [ 4%] Built target volk_profile
 [ 5%] Built target volk-config-info
 [ 6%] Built target pygen_volk_python_volk_modtool_34493
 [ 6%] Built target pygen_volk_python_volk_modtool_04eb6
 [ 7%] Built target pmt_generated
 [ 7%] Built target gnuradio-pmt
 [ 10%] Built target gnuradio-runtime
 [ 11%] Built target test-gnuradio-runtime
 [ 11%] Built target gr_runtime_test
 [ 11%] Built target test-gnuradio-pmt
 [ 11%] Built target gr_pmt_test
 [ 11%] Built target gnuradio-config-info
 [ 11%] Built target pmt_swig_swig_doc
 [ 11%] Built target _pmt_swig_swig_tag
 [ 11%] Built target pmt_swig_gnuradio_runtime_swig_7dd5e
 [ 11%] Built target _pmt_swig
 [ 11%] Built target runtime_swig_swig_doc
 [ 11%] Built target pmt_swig
 [ 11%] Built target _runtime_swig_swig_tag
 [ 11%] Built target runtime_swig_gnuradio_runtime_swig_7dd5e
 [ 11%] Built target _runtime_swig
 [ 11%] Built target pygen_gnuradio_runtime_swig_bc893
 [ 12%] Built target pygen_gnuradio_runtime_swig_c7096
 [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_0cff0
 [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_gr_c39fa
 [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_gru_e77e9
 [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_20832
 [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_c0e39
 [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_2dcdd
 [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_a87ad
 [ 13%] Built target pygen_gnuradio_runtime_python_pmt_5fb7b
 [ 13%] Built target pygen_gnuradio_runtime_examples_mp_sched_be1cd
 [ 13%] Built target pygen_gnuradio_runtime_examples_network_14cb6
 [ 13%] Built target pygen_gnuradio_runtime_examples_volk_benchmark_0f7b0
 [ 14%] Built target blocks_generated_includes
 [ 14%] Building CXX object gr-blocks/lib/CMakeFiles/
 gnuradio-blocks.dir/float_array_to_int.cc.o
 In file included from /usr/include/c++/5/cstdint:35:0,
 from /home/eexmmlo/prefix/default/
 src/gnuradio/gr-blocks/lib/float_array_to_int.cc:30:
 /usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file
 requires compiler and library support for the ISO C++ 2011 standard. This
 support must be enabled with the -std=c++11 or -std=gnu++11 compiler
 options.
 #error This file requires compiler and library support \
 ^
 
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:32:14:
 error: ?int64_t? does not name a type
 static const int64_t MAX_INT = INT32_MAX;
 ^
 
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:33:14:
 error: ?int64_t? does not name a type
 static const int64_t MIN_INT = INT32_MIN;
 ^
 /home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:
 In function ?void float_array_to_int(const float*, int*, float, int)?:
 
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:39:5:
 error: ?int64_t? was not declared in this scope
 int64_t r = llrintf(scale * in[i]);
 ^
 
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:40:9:
 error: ?r? was not declared in this scope
 if (r < MIN_INT)
 ^
 
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:40:13:
 error: ?MIN_INT? was not declared in this scope
 if (r < MIN_INT)
 ^
 
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:42:18:
 error: ?MAX_INT? was not declared in this scope
 else if (r > MAX_INT)
 ^
 
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:44:31:
 error: ?r? was not declared in this scope
 out[i] = static_cast(r);
 ^
 gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/build.make:4635: recipe for
 target 'gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/float_array_to_int.cc.o'
 failed
 make[2]: *** 
[gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/float_array_to_int.cc.o]
 Error 1
 CMakeFiles/Makefile2:2171: recipe for target
 'gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all'
 failed
 make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2
 Makefile:160: recipe for target 'all' failed
 make: *** [all] Error 2
 PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
 messages.
 PyBOMBS.Packager.source - ERROR - Problem occurred while building package
 gnuradio:
 Build failed.
 PyBOMBS.install_manager - ERROR - Error installing package gnuradio.
 Aborting.
 
 Regards,
 Mir Lodro
 -- next part --
 An HTML attachment was scrubbed...
 URL: 
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20180607/427cb3c6/attachment.html>
 
 --
 
 Message: 6
 Date: Thu

Re: [Discuss-gnuradio] install issue with c++11

[Jason Matusiak]

OK, here is where everything stands.  I have made some headway, but it is still 
not 100% solved yet.  I found some misnamed nomenclature in the ettus wiki on 
how pybombs installs and muddled through some things to get gr-blocks to finish 
building.  I still cannot get this all to work automagically, but I am hoping 
someone can see a way, or we can patch pybombs in such a way to make it happen.
 
First - The flag in the config.yml is not "env" like the wiki states, but 
"setup_env".  This seems to be a sub-setting to the config portion of the 
config.yml files.  The setup_env flag seems to want to source a file, so what I 
did was put a path to a file in there that contains my command.  The tail of 
the config.yml mod looks like this:
- config:
 setup_env: /home/me/Downloads/flag
 
 
My file "flag", contains the one line "export CXXFLAGS=-std=c++11" (minus the 
quotes of course).
 
So now when the build process starts (via a regular pybombs install), UHD 
builds fine as always, and gnuradio start fine, then barfs on gr-blocks (the 
first place that requires ++11).  I know the environment flag took because I 
see it in one of the commands it is trying to run and fails on (below is an 
example of one of the failing commands:
[ 27%] Building CXX object 
gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/max_ss_impl.cc.o
cd /opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/gr-blocks/lib && 
/usr/local/bin/c++ -DENABLE_GR_LOG -DGR_CTRLPORT -DGR_PERFORMANCE_COUNTERS 
-DHAVE_ARPA_INET_H -DHAVE_BYTESWAP_H -DHAVE_COSF -DHAVE_LINUX_PPDEV_H 
-DHAVE_LOG4CPP -DHAVE_MALLOC_H -DHAVE_NETDB_H -DHAVE_NETINET_IN_H -DHAVE_SELECT 
-DHAVE_SIGNAL_H -DHAVE_SINCOS -DHAVE_SINCOSF -DHAVE_SINF -DHAVE_SYS_IPC_H 
-DHAVE_SYS_MMAN_H -DHAVE_SYS_SELECT_H -DHAVE_SYS_SHM_H -DHAVE_SYS_SOCKET_H 
-DHAVE_SYS_TIME_H -DHAVE_SYS_TYPES_H -DHAVE_UNISTD_H -Dgnuradio_blocks_EXPORTS 
-I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/gnuradio-runtime/include 
-I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gnuradio-runtime/include 
-I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build 
-I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/volk/include 
-I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/volk/include 
-I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/gr-blocks/include 
-I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/gr-blocks/lib 
-I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/include 
-I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib -std=c++11 
-fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -O2 -g -DNDEBUG 
-fPIC -std=gnu++98 -o CMakeFiles/gnuradio-blocks.dir/max_ss_impl.cc.o -c 
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/gr-blocks/lib/max_ss_impl.cc
 And you can see that it contains "-std=c++11" (that isn't present if I don't 
do a setup_env in the yml file, so I know pybombs is reading things properly) 
followed by the normal (for the pybombs install) command "-std=gnu++98" a 
couple of commands later.  This will fail with the normal complaint about 
needing ++11.  The interesting thing is, if I do a find and replace, and swap 
the order of those two flags within all files in src/gnuradio/build/gr-blocks, 
things build happily.  So what gives?  I can't seem to find a good way to 
override the ++98.  A workaround is to change the order of those two flags so 
that the ++11 command comes after it if they are both going to be there, but I 
can't seem to get that to work either.
 Anyone have any ideas?  I don't mind adding additional export commands to my 
"flag" file, but I haven't found one yet that seems to make a darn to the 
issue.  I have almost gone as far as I can take it.
 
 
- Original Message - Subject: Re: [Discuss-gnuradio] install 
issue with c++11
From: "Jose Ruvalcaba" 
Date: 6/5/18 7:44 pm
To: "Linda20071" 

  I encountered this issue but seemed to fix it by updating my gcc compiler 
from 5.4.0 to 6.4. However, after I did this I encountered another problem with 
the uhd drivers which I opened on a separate thread :( . I got the instructions 
on how to update the gcc compiler from the following youtube video: 
https://www.youtube.com/watch?v=vVzshfYSgRk.
Hope this information is of any help.


 On Tue, Jun 5, 2018 at 4:27 PM, Linda20071  wrote:
  Is there a good book for an "overview of C++11/14" so somebody with a very 
good background in c++ can grasp the main idea quickly? Examples in a 
programming overview book can always help!   
Thanks in advance!


 On Tue, Jun 5, 2018 at 2:39 PM, Jason Matusiak  
wrote:
  Does anyone have experience with this?  I am having trouble figuring out if 
it is not working, or if I am not doing something right.
 
The config.yml looks like this when fresh:
!!omap
- categories:
hardware:
forcebuild: true
 common:
 forcebuild: true
- packages:
 gnuradio:
 forcebuild: true
 gqrx:
 forcebuild: true
 I then added

Re: [Discuss-gnuradio] install issue with c++11

[Jason Matusiak]

Does anyone have experience with this?  I am having trouble figuring out if it 
is not working, or if I am not doing something right.
 
The config.yml looks like this when fresh:
!!omap
- categories:
hardware:
forcebuild: true
 common:
 forcebuild: true
- packages:
 gnuradio:
 forcebuild: true
 gqrx:
 forcebuild: true
 I then added the line:
 - config:
env:
export CXXFLAGS:STRING="-std=c++11"
 to the end of it.  I don't think that that is the right way to do it, but 
CXXFLAGS="-std=c++11" didn't work either (no "export" or ":STRING").
 Also tried just straight: 
 - env
CXXFLAGS: "-std=c++11"
 Any ideas?
 
 

 Check out 
https://github.com/gnuradio/pybombs#configuring-a-prefix-environment-eg-for-cross-compiling.
  You might be able to set CXXFLAGS with the `--env` flag

  On Tue, Jun 5, 2018 at 10:36 AM Dave NotTelling  wrote:
 I would suspect that PyBombs doesn't care about your env variables.  That or 
it overwrites the CMAKE_CXX_FLAGS at some point.  I have no idea how PyBombs 
builds the CMake projects.  If it's not calling the `cmake` command directly, 
then it likely will not pick up the env variable.

  On Tue, Jun 5, 2018 at 10:33 AM Philip Balister  wrote:
On 06/05/2018 10:06 AM, Marcus D. Leech wrote:
 > On 06/05/2018 09:07 AM, Jason Matusiak wrote:
 >> Thanks Dave, but that did not seem to work for me.  Here were the
 >> commands I ran (slightly different than recommended, but that was for
 >> some different recipe mods that have nothing to do with this issue):
 >>
 >> $ export CXXFLAGS="-std=c++11"
 >> $ PREFIX=/opt/gnuradio/v3.7.12.0
 >> $ yes | pybombs prefix init $PREFIX
 >> $ yes | pybombs -p $PREFIX recipes add gr-recipes
 >> git+https://github.com/gnuradio/gr-recipes.git
 >> $ source /opt/gnuradio/v3.7.12.0/setup_env.sh
 >> $ pybombs -vvv -p $PREFIX install gnuradio
 >>
 >> And currently things keep erroring out at the same place while
 >> installing UHD:
 >>
 >> [ 43%] Building CXX object
 >> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o
 >>
 >> [ 43%] Building CXX object
 >> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o
 >>
 >> c++: internal compiler error: Killed (program cc1plus)
 >> Please submit a full bug report,
 >> with preprocessed source if appropriate.
 >> See <http://bugzilla.redhat.com/bugzilla> for instructions.
 >> make[2]: ***
 >> [lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o]
 >> Error 4
 >> make[2]: *** Waiting for unfinished jobs
 >>
 >> I've also tried env CXXFLAGS=-std=c++11, but it had the same issues.
 >>
 > That error is internal to the compiler, it is failing to perform its job
 > correctly.  This has nothing to do with Gnu Radio, per se, or PyBombs
 >   or any of that.  This ordinarily means you compiler is broken in some
 > way.
 > 
 > HOWEVER.  How much memory do you have on the system?
 
 
 Run dmesg and look for messages from the OOM killer (Out of Memory)
 
 Philip
 
 > 
 > This issue used to happen on systems with small physical memory, because
 > compiling certain things requires a lot of virtual memory
 >   on the part of the compiler.
 > 
 > 
 >>
 >> Jason,
 >>  You can set the CXXFLAGS env variable to "-std=c++11" and any
 >> CMake builds you run (assuming the same shell) will check the
 >> CXXFLAGS var first.  This assumes that you don't overwrite the
 >> value of CMAKE_CXX_FLAGS.  I just tried it in a terminal with
 >> `export CXXFLAGS="-std=c++11"`, then `cmake ..`, and finally
 >> `VERBOSE=1 make -j 1`.  The verbose make command will show you if
 >> your flags are taking or not.
 >> -Dave
 >>
 >> On Tue, Jun 5, 2018 at 8:00 AM Jason Matusiak
 >> > <mailto:ja...@gardettoengineering.com>> wrote:
 >>
 >> I am trying to install gnuradio onto a Centos 7 box and am
 >> having more and more issues with packages that use c++11
 >> commands.  For some of the packages, I add the line:
 >> CMAKE_CXX_FLAGS "-std=c++11"
 >> to the module's CMakeLists.txt file.
 >> The issue is that that requires a fetch, the mod, and then a
 >> rebuild.  This worked OK with it was just gqrx I was doing it
 >> for, but now I need it for other modules it appears, and so I
 >> am trying to find a more elegant solution that covers
 >> everything that is built via a pybombs install gnuradio
 >> command (li

Re: [Discuss-gnuradio] install issue with c++11

[Jason Matusiak]

I wasn't worried about my gnuradio builds as much as my system as a whole when 
I was mucking with the actually cmake and compilers themselves to try and fix 
the problem.
 
The whole purpose of using PyBOMBS is to work in PREFIXes, so no need
 to do that - PyBOMBS does that automatically.
 On Tue, 2018-06-05 at 10:38 -0400, Dave NotTelling wrote:
 > Check out 
 > https://github.com/gnuradio/pybombs#configuring-a-prefix-environment-eg-for-cross-compiling.
 >  You might be able to set CXXFLAGS with the `--env` flag
 > 
 > On Tue, Jun 5, 2018 at 10:36 AM Dave NotTelling  wrote:
 > > I would suspect that PyBombs doesn't care about your env variables. That 
 > > or it overwrites the CMAKE_CXX_FLAGS at some point. I have no idea how 
 > > PyBombs builds the CMake projects. If it's not calling the `cmake` command 
 > > directly, then it likely will not pick up the env variable.
 > > 
 > > On Tue, Jun 5, 2018 at 10:33 AM Philip Balister  
 > > wrote:
 > > > On 06/05/2018 10:06 AM, Marcus D. Leech wrote:
 > > > > On 06/05/2018 09:07 AM, Jason Matusiak wrote:
 > > > >> Thanks Dave, but that did not seem to work for me. Here were the
 > > > >> commands I ran (slightly different than recommended, but that was for
 > > > >> some different recipe mods that have nothing to do with this issue):
 > > > >>
 > > > >> $ export CXXFLAGS="-std=c++11"
 > > > >> $ PREFIX=/opt/gnuradio/v3.7.12.0
 > > > >> $ yes | pybombs prefix init $PREFIX
 > > > >> $ yes | pybombs -p $PREFIX recipes add gr-recipes
 > > > >> git+https://github.com/gnuradio/gr-recipes.git
 > > > >> $ source /opt/gnuradio/v3.7.12.0/setup_env.sh
 > > > >> $ pybombs -vvv -p $PREFIX install gnuradio
 > > > >>
 > > > >> And currently things keep erroring out at the same place while
 > > > >> installing UHD:
 > > > >>
 > > > >> [ 43%] Building CXX object
 > > > >> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o
 > > > >>
 > > > >> [ 43%] Building CXX object
 > > > >> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o
 > > > >>
 > > > >> c++: internal compiler error: Killed (program cc1plus)
 > > > >> Please submit a full bug report,
 > > > >> with preprocessed source if appropriate.
 > > > >> See <http://bugzilla.redhat.com/bugzilla> for instructions.
 > > > >> make[2]: ***
 > > > >> [lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o]
 > > > >> Error 4
 > > > >> make[2]: *** Waiting for unfinished jobs
 > > > >>
 > > > >> I've also tried env CXXFLAGS=-std=c++11, but it had the same issues.
 > > > >>
 > > > > That error is internal to the compiler, it is failing to perform its 
 > > > > job
 > > > > correctly. This has nothing to do with Gnu Radio, per se, or PyBombs
 > > > > or any of that. This ordinarily means you compiler is broken in some
 > > > > way.
 > > > > 
 > > > > HOWEVER. How much memory do you have on the system?
 > > > 
 > > > 
 > > > Run dmesg and look for messages from the OOM killer (Out of Memory)
 > > > 
 > > > Philip
 > > > 
 > > > > 
 > > > > This issue used to happen on systems with small physical memory, 
 > > > > because
 > > > > compiling certain things requires a lot of virtual memory
 > > > > on the part of the compiler.
 > > > > 
 > > > > 
 > > > >>
 > > > >> Jason,
 > > > >> You can set the CXXFLAGS env variable to "-std=c++11" and any
 > > > >> CMake builds you run (assuming the same shell) will check the
 > > > >> CXXFLAGS var first. This assumes that you don't overwrite the
 > > > >> value of CMAKE_CXX_FLAGS. I just tried it in a terminal with
 > > > >> `export CXXFLAGS="-std=c++11"`, then `cmake ..`, and finally
 > > > >> `VERBOSE=1 make -j 1`. The verbose make command will show you if
 > > > >> your flags are taking or not.
 > > > >> -Dave
 > > > >>
 > > > >> On Tue, Jun 5, 2018 at 8:00 AM Jason Matusiak
 > > > >>  > > >> <mailto:ja...@gardettoengineering.com>> wrote:
 > > > >>
 > > > >> 

Re: [Discuss-gnuradio] install issue with c++11

[Jason Matusiak]

So, the host machine performed much better (and of course much faster), so that 
got me past the UHD problem, but I still see the c++11 issue that I was trying 
to solve (I attempted to use Dave's fix.
 
Here is the error I see:
[ 12%] Building CXX object 
gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/float_array_to_int.cc.o
In file included from /usr/local/include/c++/4.9.2/cstdint:35:0,
 from 
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:30:
/usr/local/include/c++/4.9.2/bits/c++0x_warning.h:32:2: error: #error This file 
requires compiler and library support for the ISO C++ 2011 standard. This 
support is currently experimental, and must be enabled with the -std=c++11 or 
-std=gnu++11 compiler options.
 #error This file requires compiler and library support for the \
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:32:14:
 error: 'int64_t' does not name a type
 static const int64_t MAX_INT = INT32_MAX;
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:33:14:
 error: 'int64_t' does not name a type
 static const int64_t MIN_INT = INT32_MIN;
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc: 
In function 'void float_array_to_int(const float*, int*, float, int)':
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:39:5:
 error: 'int64_t' was not declared in this scope
 int64_t r = llrintf(scale * in[i]);
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:40:9:
 error: 'r' was not declared in this scope
 if (r < MIN_INT)
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:40:13:
 error: 'MIN_INT' was not declared in this scope
 if (r < MIN_INT)
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:42:18:
 error: 'MAX_INT' was not declared in this scope
 else if (r > MAX_INT)
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:44:31:
 error: 'r' was not declared in this scope
 out[i] = static_cast(r);
 ^
make[2]: *** 
[gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/float_array_to_int.cc.o] Error 1
make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2
make: *** [all] Error 2
 
 
 
 

 Marcus, I started to suspect after the thread started that that was the case.  
I was doing this work in a VM so as to not hose my host system too much, but I 
just started another install on my host system to do the work without memory 
being an issue.
 
That said, the c++11 concerns are definitely there, and the new change to 
gr-blocks that was committed about 7 days ago was when we decided we need to 
come up with a good solution since I couldn't simply fetch/mod/rebuild that as 
easy as I could gqrx.
 
Fingers crossed that Dave's advice works on my beefier setup (sadly, one of my 
100 other attempts might have worked, I don't recall when this memory issue 
started cropping up after I took on the c++11 task, but it wasn't there the 
other day).
 
 

 On 06/05/2018 09:07 AM, Jason Matusiak wrote:
 Thanks Dave, but that did not seem to work for me.  Here were the commands I 
ran (slightly different than recommended, but that was for some different 
recipe mods that have nothing to do with this issue):
$ export CXXFLAGS="-std=c++11"
 $ PREFIX=/opt/gnuradio/v3.7.12.0
 $ yes | pybombs prefix init $PREFIX
 $ yes | pybombs -p $PREFIX recipes add gr-recipes 
git+https://github.com/gnuradio/gr-recipes.git
 $ source /opt/gnuradio/v3.7.12.0/setup_env.sh
 $ pybombs -vvv -p $PREFIX install gnuradio
 And currently things keep erroring out at the same place while installing UHD:
 [ 43%] Building CXX object 
lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o
 [ 43%] Building CXX object 
lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o
 c++: internal compiler error: Killed (program cc1plus)
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See <http://bugzilla.redhat.com/bugzilla> for instructions.
 make[2]: *** 
[lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o] 
Error 4
 make[2]: *** Waiting for unfinished jobs
 I've also tried env CXXFLAGS=-std=c++11, but it had the same issues.
 
 
 That error is internal to the compiler, it is failing to perform its job 
correctly.  This has nothing to do with Gnu Radio, per se, or PyBombs
   or any of that.  This ordinarily means you compiler is broken in some way.
 
 HOWEVER.  How much memory do you have on the system?
 
 This issue used to happen on systems with small physical memory, because 
compiling certain things requires a lot of virtual memory
   on the part of the compiler.
 
 
   
 Jason,  
 You can set the CXXFLAGS env variable to "-std=c++11" and any CMake builds 
you run (assuming the same shell) will check the CXXFLAGS var first.  This 
assumes

Re: [Discuss-gnuradio] install issue with c++11

[Jason Matusiak]

Marcus, I started to suspect after the thread started that that was the case.  
I was doing this work in a VM so as to not hose my host system too much, but I 
just started another install on my host system to do the work without memory 
being an issue.
 
That said, the c++11 concerns are definitely there, and the new change to 
gr-blocks that was committed about 7 days ago was when we decided we need to 
come up with a good solution since I couldn't simply fetch/mod/rebuild that as 
easy as I could gqrx.
 
Fingers crossed that Dave's advice works on my beefier setup (sadly, one of my 
100 other attempts might have worked, I don't recall when this memory issue 
started cropping up after I took on the c++11 task, but it wasn't there the 
other day).
 
 

 On 06/05/2018 09:07 AM, Jason Matusiak wrote:
 Thanks Dave, but that did not seem to work for me.  Here were the commands I 
ran (slightly different than recommended, but that was for some different 
recipe mods that have nothing to do with this issue):
$ export CXXFLAGS="-std=c++11"
 $ PREFIX=/opt/gnuradio/v3.7.12.0
 $ yes | pybombs prefix init $PREFIX
 $ yes | pybombs -p $PREFIX recipes add gr-recipes 
git+https://github.com/gnuradio/gr-recipes.git
 $ source /opt/gnuradio/v3.7.12.0/setup_env.sh
 $ pybombs -vvv -p $PREFIX install gnuradio
 And currently things keep erroring out at the same place while installing UHD:
 [ 43%] Building CXX object 
lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o
 [ 43%] Building CXX object 
lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o
 c++: internal compiler error: Killed (program cc1plus)
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See <http://bugzilla.redhat.com/bugzilla> for instructions.
 make[2]: *** 
[lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o] 
Error 4
 make[2]: *** Waiting for unfinished jobs
 I've also tried env CXXFLAGS=-std=c++11, but it had the same issues.
 
 
 That error is internal to the compiler, it is failing to perform its job 
correctly.  This has nothing to do with Gnu Radio, per se, or PyBombs
   or any of that.  This ordinarily means you compiler is broken in some way.
 
 HOWEVER.  How much memory do you have on the system?
 
 This issue used to happen on systems with small physical memory, because 
compiling certain things requires a lot of virtual memory
   on the part of the compiler.
 
 
   
 Jason,  
 You can set the CXXFLAGS env variable to "-std=c++11" and any CMake builds 
you run (assuming the same shell) will check the CXXFLAGS var first.  This 
assumes that you don't overwrite the value of CMAKE_CXX_FLAGS.  I just tried it 
in a terminal with `export CXXFLAGS="-std=c++11"`, then `cmake ..`, and finally 
`VERBOSE=1 make -j 1`.  The verbose make command will show you if your flags 
are taking or not.
 
-Dave


  On Tue, Jun 5, 2018 at 8:00 AM Jason Matusiak  
wrote:
 I am trying to install gnuradio onto a Centos 7 box and am having more and 
more issues with packages that use c++11 commands.  For some of the packages, I 
add the line:
CMAKE_CXX_FLAGS "-std=c++11"
to the module's CMakeLists.txt file.
 
The issue is that that requires a fetch, the mod, and then a rebuild.  This 
worked OK with it was just gqrx I was doing it for, but now I need it for other 
modules it appears, and so I am trying to find a more elegant solution that 
covers everything that is built via a pybombs install gnuradio command (like 
gr-blocks, which I can't use this trick for).
 
If I understand the problem correctly, Ubuntu uses new enough tools to realize 
that it needs to use the c++11 version (or newer I assume) to build since it is 
needed.  It seems like even though Centos 7 has the c++11 capability, it does 
not smartly trying to use it, and must be directed to for the installs to work.
 
Is there something I can do at an upper level to make things happy on an 
install?
___
 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
  
___ 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] install issue with c++11

[Jason Matusiak]

Thanks Dave, but that did not seem to work for me.  Here were the commands I 
ran (slightly different than recommended, but that was for some different 
recipe mods that have nothing to do with this issue):
$ export CXXFLAGS="-std=c++11"
 $ PREFIX=/opt/gnuradio/v3.7.12.0
$ yes | pybombs prefix init $PREFIX
$ yes | pybombs -p $PREFIX recipes add gr-recipes 
git+https://github.com/gnuradio/gr-recipes.git
$ source /opt/gnuradio/v3.7.12.0/setup_env.sh
$ pybombs -vvv -p $PREFIX install gnuradio
 And currently things keep erroring out at the same place while installing UHD:
 [ 43%] Building CXX object 
lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o
[ 43%] Building CXX object 
lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
make[2]: *** 
[lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o] 
Error 4
make[2]: *** Waiting for unfinished jobs
 I've also tried env CXXFLAGS=-std=c++11, but it had the same issues.
 
 
 
 Jason,  
 You can set the CXXFLAGS env variable to "-std=c++11" and any CMake builds 
you run (assuming the same shell) will check the CXXFLAGS var first.  This 
assumes that you don't overwrite the value of CMAKE_CXX_FLAGS.  I just tried it 
in a terminal with `export CXXFLAGS="-std=c++11"`, then `cmake ..`, and finally 
`VERBOSE=1 make -j 1`.  The verbose make command will show you if your flags 
are taking or not.
 
-Dave


  On Tue, Jun 5, 2018 at 8:00 AM Jason Matusiak  
wrote:
 I am trying to install gnuradio onto a Centos 7 box and am having more and 
more issues with packages that use c++11 commands.  For some of the packages, I 
add the line:
CMAKE_CXX_FLAGS "-std=c++11"
to the module's CMakeLists.txt file.
 
The issue is that that requires a fetch, the mod, and then a rebuild.  This 
worked OK with it was just gqrx I was doing it for, but now I need it for other 
modules it appears, and so I am trying to find a more elegant solution that 
covers everything that is built via a pybombs install gnuradio command (like 
gr-blocks, which I can't use this trick for).
 
If I understand the problem correctly, Ubuntu uses new enough tools to realize 
that it needs to use the c++11 version (or newer I assume) to build since it is 
needed.  It seems like even though Centos 7 has the c++11 capability, it does 
not smartly trying to use it, and must be directed to for the installs to work.
 
Is there something I can do at an upper level to make things happy on an 
install?
___
 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

[Discuss-gnuradio] install issue with c++11

[Jason Matusiak]

I am trying to install gnuradio onto a Centos 7 box and am having more and more 
issues with packages that use c++11 commands.  For some of the packages, I add 
the line:
CMAKE_CXX_FLAGS "-std=c++11"
to the module's CMakeLists.txt file.
 
The issue is that that requires a fetch, the mod, and then a rebuild.  This 
worked OK with it was just gqrx I was doing it for, but now I need it for other 
modules it appears, and so I am trying to find a more elegant solution that 
covers everything that is built via a pybombs install gnuradio command (like 
gr-blocks, which I can't use this trick for).
 
If I understand the problem correctly, Ubuntu uses new enough tools to realize 
that it needs to use the c++11 version (or newer I assume) to build since it is 
needed.  It seems like even though Centos 7 has the c++11 capability, it does 
not smartly trying to use it, and must be directed to for the installs to work.
 
Is there something I can do at an upper level to make things happy on an 
install?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] problem with Tagged File Sink

[Jason Matusiak]

I have a custom block that is adding the "burst" "True" and "False" tags 
via:

add_item_tag(0, d_total_passed_samples, pmt::mp("burst"), pmt::mp("True"));
and
add_item_tag(0, d_total_passed_samples-1, pmt::mp("burst"), 
pmt::mp("False"));


When I run it and look at the output via Tag Debug, I see:
--
Tag Debug: burst
Input Stream: 00
  Offset: 0  Source: n/a Key: burst   Value: True
--

--
Tag Debug: burst
Input Stream: 00
  Offset: 499  Source: n/a Key: burst   Value: False
--

Which seems correct to me.  I have a sample rate of 5Msps, and was 
attempting to save 1 seconds worth of data, so 500 seems like the 
right number of samples to pass through.


Yet if I look at what gets generated by Tagged File Sink, I see this file:
file4_0_0..dat of size 39997440

Then when I close the flowgraph, it appears that it finishes writing the 
file and it looks like this:

file4_0_0..dat of size 4000

If I don't close the flowgraph and send another burst through, I get the 
Tag Debug of:

--
Tag Debug: burst
Input Stream: 00
  Offset: 500  Source: n/a Key: burst   Value: True
--

--
Tag Debug: burst
Input Stream: 00
  Offset: 999  Source: n/a Key: burst   Value: False
--


and the file is the same name and now has a size of 39997440 until I 
close it, then it has a size of 4000.


So this leads me to believe that my Flase tag is not making it through 
the stream, but I think I am pringing it right.


Is there a bug in Tagged File Sink (not likely)?  Or am I doing 
something wrong (where my money is)?


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem understanding the ninput_items/noutput_items

[Jason Matusiak]

Makes perfect sense, thanks!!!


On 11/07/2017 08:03 AM, Michael Dickens wrote:

Hi Jason - This behavior is normal. If you're curious, read through the
code in gnuradio-runtime/lib/block_executor.cc, specifically here: <
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/block_executor.cc#L395

. Note the comments: "not enough input on input[i]" and "if we can, try

reducing the size of our output request" coupled with dividing the
number of output items to test for (in ::forecast). The implication is
that some upstream block isn't providing data as fast as this block is
consuming it. So it's not the downstream null sink that's causing this
behavior, it's whatever is upstream. Hope this helps! - MLD

On Mon, Nov 6, 2017, at 12:46 PM, Jason Matusiak wrote:

I am having a problem understanding something simple in my general_work
function.

I have a forecast function, but I seem to get different sizes for
ninput_items/noutput_items in general_work.  What I currently do is find
the minimum of the two values and work off of that: int min_items =
(ninput_items[0] < noutput_items) ? ninput_items[0] : noutput_items;.

In my mind that makes sense, but if I print out the values of
ninput_items/noutput_items, I see something I think is odd.  Over and
over it looks like this (where this is ninput_items/noutput_items=
min(ninput_items,noutput_items):
2044/1024=1024
1020/512=512
508/256=256
252/128=128
124/64=64
60/32=32
28/16=16
12/8=8
4/4=4
2044/1024=1024
1020/512=512
508/256=256
252/128=128
124/64=64
60/32=32
28/16=16
12/8=8
4/4=4

Is this divide-by-two on the output port action what is supposed to
happen?  I don't understand why it keeps dropping and then jumps up in
size again.  I am driving a null sink, so it should be able to keep up
no problem



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] problem understanding the ninput_items/noutput_items

[Jason Matusiak]

I am having a problem understanding something simple in my general_work 
function.


I have a forecast function, but I seem to get different sizes for 
ninput_items/noutput_items in general_work.  What I currently do is find 
the minimum of the two values and work off of that: int min_items = 
(ninput_items[0] < noutput_items) ? ninput_items[0] : noutput_items;.


In my mind that makes sense, but if I print out the values of 
ninput_items/noutput_items, I see something I think is odd.  Over and 
over it looks like this (where this is ninput_items/noutput_items= 
min(ninput_items,noutput_items):

2044/1024=1024
1020/512=512
508/256=256
252/128=128
124/64=64
60/32=32
28/16=16
12/8=8
4/4=4
2044/1024=1024
1020/512=512
508/256=256
252/128=128
124/64=64
60/32=32
28/16=16
12/8=8
4/4=4

Is this divide-by-two on the output port action what is supposed to 
happen?  I don't understand why it keeps dropping and then jumps up in 
size again.  I am driving a null sink, so it should be able to keep up 
no problem


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Python Block module file location

[Jason Matusiak]

I have been experimenting with the Python Block (in core>misc) for 
something I was trying to gen up quickly.  I have it working, but it 
seems to like creating random file names for the "block" and storing 
them in /tmp.


Is there anyway to point to a different file in a different location and 
have the block open /that/ in its editor?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] pybombs gnuradio install error

[Jason Matusiak]

Tried to install gnuradio on a fresh Ubuntu 14.04 box today but ran into 
an error:


$ pybombs prefix init ~/SDR -a SDR -R gnuradio-default
Exception ruamel.yaml.constructor.ConstructorError: ConstructorError() 
in  ignored

Traceback (most recent call last):
  File "/usr/local/bin/pybombs", line 11, in 
load_entry_point('PyBOMBS==2.3.1a0', 'console_scripts', 'pybombs')()
  File 
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
561, in load_entry_point

return get_distribution(dist).load_entry_point(group, name)
  File 
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
2649, in load_entry_point

return ep.load()
  File 
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
2303, in load

return self.resolve()
  File 
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
2309, in resolve

module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/local/lib/python2.7/dist-packages/pybombs/main.py", line 
26, in 

from pybombs.commands import dispatch
  File 
"/usr/local/lib/python2.7/dist-packages/pybombs/commands/__init__.py", 
line 23, in 

from .base import CommandBase, SubCommandBase, dispatch
  File 
"/usr/local/lib/python2.7/dist-packages/pybombs/commands/base.py", line 
27, in 

from pybombs.config_manager import config_manager
  File 
"/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py", line 
654, in 

config_manager = ConfigManager()
  File 
"/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py", line 
330, in __init__

self.load(select_prefix)
  File 
"/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py", line 
370, in load

if self._append_cfg_from_file(self.local_cfg):
  File 
"/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py", line 
446, in _append_cfg_from_file

cfg_data = PBConfigFile(cfg_filename).get()
  File "/usr/local/lib/python2.7/dist-packages/pybombs/config_file.py", 
line 42, in __init__

raise PBException("Error loading {0}: {1}".format(filename, str(e)))
pybombs.pb_exception.PBException: Error loading 
/home/sidekiq/.pybombs/config.yml: could not determine a constructor for 
the tag '!!python/tuple'

  in "", line 3, column 3:
- !!python/tuple []
  ^ (line: 3)

Any idea what the issue is?  Seems like an issue with pybombs itself, 
but I am not sure how to fix it.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] "Could not find port: cfg in:" error

[Jason Matusiak]

This is the same problem I had once before, but I am not sure why I 
can't fix it this time.  I have an RFNoC OOT module that wants to have a 
msg port input.  I called this port 'cfg'.


Attached is my freqShift_impl.cc file where I declare the message port 
"cfg".  I also included multiaperture_freqShift.xml where the port gets 
declared as a sink.


When I make and make install, everything seems to run fine.  I do a sudo 
ldconfig, and then refresh GRC.  When I build it is happy, then when I 
run I get the following error:


Could not find port: cfg in:
rfnoc
system

Traceback (most recent call last):
  File "/home/jmat/rfnoc-ma/examples/CPremoval.py", line 278, in 
main()
  File "/home/jmat/rfnoc-ma/examples/CPremoval.py", line 266, in main
tb = top_block_cls()
  File "/home/jmat/rfnoc-ma/examples/CPremoval.py", line 219, in __init__
self.msg_connect((self.qtgui_edit_box_msg_1, 'msg'), 
(self.uhd_rfnoc_streamer_freqShift_0, 'cfg'))
  File 
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", 
line 59, in wrapped
func(self, src.to_basic_block(), srcport, dst.to_basic_block(), 
dstport)
  File 
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", 
line 131, in msg_connect

self.primitive_msg_connect(*args)
  File 
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", 
line 3489, in primitive_msg_connect

return _runtime_swig.top_block_sptr_primitive_msg_connect(self, *args)
RuntimeError: invalid msg port in connect() or disconnect()

>>> Done

The last time I had this issue with a block it was because I didn't make 
the changes to my .cpp and .h files, but I did that this time. What else 
could I be missing???
/* -*- c++ -*- */
/* 
 * Copyright 2017 <+YOU OR YOUR COMPANY+>.
 * 
 * This is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3, or (at your option)
 * any later version.
 * 
 * This software is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this software; see the file COPYING.  If not, write to
 * the Free Software Foundation, Inc., 51 Franklin Street,
 * Boston, MA 02110-1301, USA.
 */

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include 
#include "freqShift_impl.h"
namespace gr {
  namespace multiaperture {

freqShift::sptr
freqShift::make(
const gr::ettus::device3::sptr ,
const ::uhd::stream_args_t _stream_args,
const ::uhd::stream_args_t _stream_args,
const int block_select,
const int device_select
)
{
  return gnuradio::get_initial_sptr(
new freqShift_impl(
dev,
tx_stream_args,
rx_stream_args,
block_select,
device_select
)
  );
}

/*
 * The private constructor
 */
freqShift_impl::freqShift_impl(
 const gr::ettus::device3::sptr ,
 const ::uhd::stream_args_t _stream_args,
 const ::uhd::stream_args_t _stream_args,
 const int block_select,
 const int device_select
)
  : gr::ettus::rfnoc_block("freqShift"),
gr::ettus::rfnoc_block_impl(
dev,
gr::ettus::rfnoc_block_impl::make_block_id("freqShift",  block_select, device_select),
tx_stream_args, rx_stream_args
)
{
	//JJM 5/17/2017
  message_port_register_in(pmt::mp("cfg"));
  set_msg_handler(
pmt::mp("cfg"),
boost::bind(_impl::handle_cfg_message, this, _1)
  );
}

/*
 * Our virtual destructor.
 */
freqShift_impl::~freqShift_impl()
{
}


	//JJM 5/3/2017
void freqShift_impl::handle_cfg_message(pmt::pmt_t msg)
{
  /* If the PMT is a list, assume it's a list of pairs and recurse for each */
  /* Works for dict too */
  try {
/* Because of PMT is just broken you and can't distinguish between
 * pair and dict, we have to call length() and see if it will throw
 * or not ... */
if (pmt::length(msg) > 0)
{
  for (int i=0; ihandle_cfg_message(pmt::nth(i, msg));
  return;
}
  } catch(...) { }

  /* Handle the pairs */
  if (pmt::is_pair(msg))
  {
pmt::pmt_t key(pmt::car(msg));
pmt::pmt_t val(pmt::cdr(msg));
int val_i;

if (!pmt::is_symbol(key) || !pmt::is_integer(val))
  return;

val_i = pmt::to_long(val);

try {
const std::string key_str = pmt::symbol_to_string(key);
this->set_arg(key_str, val_i);
}
catch (...) {

Re: [Discuss-gnuradio] implementing message ports on an OOT module

[Jason Matusiak]

Got it.  I fat fingered the register location in the XML, so my verilog 
was never catching the message.  Once I got them synced up it seems to 
take the message.  Thanks!


On 05/04/2017 01:40 PM, Jason Matusiak wrote:

EJ,

I made modifications to my C++ files and now GRC isn't complaining 
anymore!!!  Thank so much, that was a huge help.


Now I am trying to strobe some values into my block to make sure it is 
working, but I am not getting the results I expect.  So I believe that 
my block is expecting a PMT value with a name of "offset" and an 
integer value to follow.  What i tried to do in a Message Strobe block 
(as well as a Periodic Message Source), was to set the Message PMT to be:

pmt.cons(pmt.intern("offset"), pmt.to_pmt(10))

If I connect it to the print input of the Message Debug block, I see 
the output:

*** MESSAGE DEBUG PRINT 
(offset . 10)


But I am not sure why there is a '.' in the middle there.  Is there 
some other way that I should be setting up the PMT message?


TIA!


On 05/03/2017 10:17 AM, EJ Kreinar wrote:

Hi Jason,

I believe I have seen this issue when I did not register the message 
port correctly, or when names did not match between GRC and the 
message port name.


You may need to modify the C++ code to add a message handler, if you 
have not already. Do you have a message port registered in your 
multiaperture_cpremoval block named 'msg'? Does this have a message 
handler? 
https://wiki.gnuradio.org/index.php/Guided_Tutorial_Programming_Topics#5.3.2_Adding_Message_Passing_to_the_Code 
<https://wiki.gnuradio.org/index.php/Guided_Tutorial_Programming_Topics#5.3.2_Adding_Message_Passing_to_the_Code>


Hope this helps,
EJ

On Wed, May 3, 2017 at 9:14 AM, Jason Matusiak 
<ja...@gardettoengineering.com 
<mailto:ja...@gardettoengineering.com>> wrote:


I had originally asked this question on the USRP site, but it was
recommended by someone from Ettus to post over here since there
is a chance it is more of a GNURadio issue than USRP.

I am attempting to create an RFNoC block for the X310 and it
works fine.  I then wanted to add a message port to the block to
pass variable into it.  The message port shows up in GRC and the
flowgraph runs fine as long as I leave the message port
disconnected.  Once I try to connect something to it, I see the
following error:
Could not find port: msg in:
rfnoc
system

Traceback (most recent call last):
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py",
line 253, in 
main()
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py",
line 241, in main
tb = top_block_cls()
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py",
line 196, in __init__
self.msg_connect((self.foo_periodic_msg_source_0, 'out'),
(self.multiaperture_cpremoval_0, 'msg'))
  File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 59, in wrapped
func(self, src.to_basic_block(), srcport,
dst.to_basic_block(), dstport)
  File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 131, in msg_connect
self.primitive_msg_connect(*args)
  File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
line 3489, in primitive_msg_connect
return
_runtime_swig.top_block_sptr_primitive_msg_connect(self, *args)
RuntimeError: invalid msg port in connect() or disconnect()

>>> Done


I can't for the life of me figure out what GR "could not find." 
I see other people with similar posts in the past, but I never

found a good resolution.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<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] implementing message ports on an OOT module

[Jason Matusiak]

EJ,

I made modifications to my C++ files and now GRC isn't complaining 
anymore!!!  Thank so much, that was a huge help.


Now I am trying to strobe some values into my block to make sure it is 
working, but I am not getting the results I expect.  So I believe that 
my block is expecting a PMT value with a name of "offset" and an integer 
value to follow.  What i tried to do in a Message Strobe block (as well 
as a Periodic Message Source), was to set the Message PMT to be:

pmt.cons(pmt.intern("offset"), pmt.to_pmt(10))

If I connect it to the print input of the Message Debug block, I see the 
output:

*** MESSAGE DEBUG PRINT 
(offset . 10)


But I am not sure why there is a '.' in the middle there.  Is there some 
other way that I should be setting up the PMT message?


TIA!


On 05/03/2017 10:17 AM, EJ Kreinar wrote:

Hi Jason,

I believe I have seen this issue when I did not register the message 
port correctly, or when names did not match between GRC and the 
message port name.


You may need to modify the C++ code to add a message handler, if you 
have not already. Do you have a message port registered in your 
multiaperture_cpremoval block named 'msg'? Does this have a message 
handler? 
https://wiki.gnuradio.org/index.php/Guided_Tutorial_Programming_Topics#5.3.2_Adding_Message_Passing_to_the_Code 
<https://wiki.gnuradio.org/index.php/Guided_Tutorial_Programming_Topics#5.3.2_Adding_Message_Passing_to_the_Code>


Hope this helps,
EJ

On Wed, May 3, 2017 at 9:14 AM, Jason Matusiak 
<ja...@gardettoengineering.com <mailto:ja...@gardettoengineering.com>> 
wrote:


I had originally asked this question on the USRP site, but it was
recommended by someone from Ettus to post over here since there is
a chance it is more of a GNURadio issue than USRP.

I am attempting to create an RFNoC block for the X310 and it works
fine.  I then wanted to add a message port to the block to pass
variable into it.  The message port shows up in GRC and the
flowgraph runs fine as long as I leave the message port
disconnected.  Once I try to connect something to it, I see the
following error:
Could not find port: msg in:
rfnoc
system

Traceback (most recent call last):
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py",
line 253, in 
main()
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py",
line 241, in main
tb = top_block_cls()
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py",
line 196, in __init__
self.msg_connect((self.foo_periodic_msg_source_0, 'out'),
(self.multiaperture_cpremoval_0, 'msg'))
  File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 59, in wrapped
func(self, src.to_basic_block(), srcport,
dst.to_basic_block(), dstport)
  File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 131, in msg_connect
self.primitive_msg_connect(*args)
  File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
line 3489, in primitive_msg_connect
return
_runtime_swig.top_block_sptr_primitive_msg_connect(self, *args)
RuntimeError: invalid msg port in connect() or disconnect()

>>> Done


I can't for the life of me figure out what GR "could not find."  I
see other people with similar posts in the past, but I never found
a good resolution.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<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] implementing message ports on an OOT module

[Jason Matusiak]

EJ, Here is where things go off the rails a little.  There is no C++ for 
my RFNoC block, it is purely FPGA code (and the two XML files I had to 
create for GRC).


Somehow the fosphor message passing is working for Sylvain for message 
handling, and I tried to mimic his, but I can't seem to get past this issue.


H, after typing that last sentence, I just did a search through 
gr-ettus for *fosphor*.cc and he has two files.  So maybe I DO need to 
have those in order to do message passing  I will look into it next.


Thanks for jumping in!


On 05/03/2017 10:17 AM, EJ Kreinar wrote:

Hi Jason,

I believe I have seen this issue when I did not register the message 
port correctly, or when names did not match between GRC and the 
message port name.


You may need to modify the C++ code to add a message handler, if you 
have not already. Do you have a message port registered in your 
multiaperture_cpremoval block named 'msg'? Does this have a message 
handler? 
https://wiki.gnuradio.org/index.php/Guided_Tutorial_Programming_Topics#5.3.2_Adding_Message_Passing_to_the_Code 
<https://wiki.gnuradio.org/index.php/Guided_Tutorial_Programming_Topics#5.3.2_Adding_Message_Passing_to_the_Code>


Hope this helps,
EJ

On Wed, May 3, 2017 at 9:14 AM, Jason Matusiak 
<ja...@gardettoengineering.com <mailto:ja...@gardettoengineering.com>> 
wrote:


I had originally asked this question on the USRP site, but it was
recommended by someone from Ettus to post over here since there is
a chance it is more of a GNURadio issue than USRP.

I am attempting to create an RFNoC block for the X310 and it works
fine.  I then wanted to add a message port to the block to pass
variable into it.  The message port shows up in GRC and the
flowgraph runs fine as long as I leave the message port
disconnected.  Once I try to connect something to it, I see the
following error:
Could not find port: msg in:
rfnoc
system

Traceback (most recent call last):
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py",
line 253, in 
main()
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py",
line 241, in main
tb = top_block_cls()
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py",
line 196, in __init__
self.msg_connect((self.foo_periodic_msg_source_0, 'out'),
(self.multiaperture_cpremoval_0, 'msg'))
  File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 59, in wrapped
func(self, src.to_basic_block(), srcport,
dst.to_basic_block(), dstport)
  File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 131, in msg_connect
self.primitive_msg_connect(*args)
  File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
line 3489, in primitive_msg_connect
return
_runtime_swig.top_block_sptr_primitive_msg_connect(self, *args)
RuntimeError: invalid msg port in connect() or disconnect()

>>> Done


I can't for the life of me figure out what GR "could not find."  I
see other people with similar posts in the past, but I never found
a good resolution.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] implementing message ports on an OOT module

[Jason Matusiak]

I had originally asked this question on the USRP site, but it was 
recommended by someone from Ettus to post over here since there is a 
chance it is more of a GNURadio issue than USRP.


I am attempting to create an RFNoC block for the X310 and it works 
fine.  I then wanted to add a message port to the block to pass variable 
into it.  The message port shows up in GRC and the flowgraph runs fine 
as long as I leave the message port disconnected.  Once I try to connect 
something to it, I see the following error:

Could not find port: msg in:
rfnoc
system

Traceback (most recent call last):
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py", line 
253, in 

main()
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py", line 
241, in main

tb = top_block_cls()
  File "/home/jmat/rfnoc-multiaperture/examples/CPremoval.py", line 
196, in __init__
self.msg_connect((self.foo_periodic_msg_source_0, 'out'), 
(self.multiaperture_cpremoval_0, 'msg'))
  File 
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", 
line 59, in wrapped
func(self, src.to_basic_block(), srcport, dst.to_basic_block(), 
dstport)
  File 
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", 
line 131, in msg_connect

self.primitive_msg_connect(*args)
  File 
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", 
line 3489, in primitive_msg_connect

return _runtime_swig.top_block_sptr_primitive_msg_connect(self, *args)
RuntimeError: invalid msg port in connect() or disconnect()

>>> Done


I can't for the life of me figure out what GR "could not find."  I see 
other people with similar posts in the past, but I never found a good 
resolution.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] pybombs install with a space in directory name

[Jason Matusiak]

OK, I see where things are bailing now (I added verbosity to the 
install).  It seems like the offending command is:

PyBOMBS.Inventory - DEBUG - Setting state to `fetched'
PyBOMBS.Inventory - DEBUG - Saving inventory to file 
/sharing/shared/Research 
Projects/Projects/projs/jmatus/prefixes/E310/.pybombs/inventory.yml...

PyBOMBS.prefix - INFO - Installing SDK `e3xx-release4-sdk'
PyBOMBS._process_thread() - DEBUG - Executing command `$ sh 
./oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh -y -d 
/sharing/shared/Research Projects/Projects/projs/jmatus/prefixes/E310'
You are about to install the SDK to "/sharing/shared/Research". 
Proceed[Y/n]?Y


And that is where it hangs (you'd notice the space in the directory is 
not longer escaped).  I might try to look into the underlying scripts to 
see if I can make a one-off change that can get me past this issue 
(unless someone has an environment variable or something like that I can 
run to make the command happy)



On 04/25/2017 01:05 PM, Jason Matusiak wrote:
Hey Nathan.  tried that as well (first actually since that is what 
tabbed out), no dice.  IT hangs right here:

PyBOMBS.prefix - INFO - Installing SDK `e3xx-release4-sdk'
You are about to install the SDK to "/sharing/shared/Research". 
Proceed[Y/n]?Y


I have a feeling that when I escape it the first time, it gets passed 
into pybombs correctly,  Then when something actually goes to use it, 
the escape sequence has been stripped and it sees the space and stops 
working.  That seem possible?



On 04/25/2017 12:56 PM, West, Nathan wrote:

Where do you actually get stuck? Try Research\ Projects

On Tue, Apr 25, 2017 at 12:20 PM, Jason Matusiak 
<ja...@gardettoengineering.com 
<mailto:ja...@gardettoengineering.com>> wrote:


I am trying to do an install of gnuradio into a directory on my
company's share that I don't have the ability to change. I
thought it was working until it hung for a while.  After looking
at it a bit, I have a feeling that the issue is that there is a
folder called "Research Projects" in my directory structure.  I
am thinking that pybombs is having an issue with the space (which
I try to never use in Linux myself).  Is there a way to work
around that issue? (I tried putting the folder name in double
quotes, but that didn't helps any).

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<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] pybombs install with a space in directory name

[Jason Matusiak]

Hey Nathan.  tried that as well (first actually since that is what 
tabbed out), no dice.  IT hangs right here:

PyBOMBS.prefix - INFO - Installing SDK `e3xx-release4-sdk'
You are about to install the SDK to "/sharing/shared/Research". 
Proceed[Y/n]?Y


I have a feeling that when I escape it the first time, it gets passed 
into pybombs correctly,  Then when something actually goes to use it, 
the escape sequence has been stripped and it sees the space and stops 
working.  That seem possible?



On 04/25/2017 12:56 PM, West, Nathan wrote:

Where do you actually get stuck? Try Research\ Projects

On Tue, Apr 25, 2017 at 12:20 PM, Jason Matusiak 
<ja...@gardettoengineering.com <mailto:ja...@gardettoengineering.com>> 
wrote:


I am trying to do an install of gnuradio into a directory on my
company's share that I don't have the ability to change.  I
thought it was working until it hung for a while.  After looking
at it a bit, I have a feeling that the issue is that there is a
folder called "Research Projects" in my directory structure.  I am
thinking that pybombs is having an issue with the space (which I
try to never use in Linux myself). Is there a way to work around
that issue? (I tried putting the folder name in double quotes, but
that didn't helps any).

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] pybombs install with a space in directory name

[Jason Matusiak]

I am trying to do an install of gnuradio into a directory on my 
company's share that I don't have the ability to change.  I thought it 
was working until it hung for a while.  After looking at it a bit, I 
have a feeling that the issue is that there is a folder called "Research 
Projects" in my directory structure.  I am thinking that pybombs is 
having an issue with the space (which I try to never use in Linux 
myself).  Is there a way to work around that issue? (I tried putting the 
folder name in double quotes, but that didn't helps any).


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with gnuradio-companion execution after Pybombs installation

[Jason Matusiak]

Did you remove the gnuradio binaries that were originally installed when 
you built it from GIT (as opposed to just removing the build folder)?


On 04/21/2017 02:16 PM, kon...@tigerinnovations.com wrote:

Hi,

I recently reinstalled gnuradio through PyBOMBS through pip. My 
previous installation was a clone of the git repository. I am having 
trouble runinng gnuradio companion from a prefix.


$ source ~/prefix/setup_env.sh
$ gnuradio-companion

When I run the above commands, I get the following error:

Traceback (most recent call last):
  File "/home/gnuradio/default/bin/gnuradio-companion", line 99, in 


run_main()
  File "/home/gnuradio/default/bin/gnuradio-companion", line 92, in 
run_main

exit(main())
  File 
"/home/gnuradio/default/lib/python2.7/dist-packages/gnuradio/grc/main.py", 
line 53, in main

ActionHandler(args, platform)
  File 
"/home/gnuradio/default/lib/python2.7/dist-packages/gnuradio/grc/gui/ActionHandler.py", 
line 60, in __init__

self.main_window = MainWindow(platform, self._handle_action)
  File 
"/home/gnuradio/default/lib/python2.7/dist-packages/gnuradio/grc/gui/MainWindow.py", 
line 80, in __init__

gen_opts = platform.blocks['options'].get_param('generate_options')
  File 
"/home/gnuradio/default/lib/python2.7/dist-packages/gnuradio/grc/core/utils/odict.py", 
line 35, in __getitem__

return self._data[key]
KeyError: 'options'


I can execute gnuradio companion through the following command:
$ pybombs run gnuradio-companion

But before reinstalling PyBOMBS, I was able to run gnuradio companion 
through the prefix (running setup_env.sh and then calling 
gnuradio-companion) and I'm wondering why that's no longer possible. I 
have tried removing and reinstalling gnuradio to the prefix, but that 
did not work. Has anyone else has this problem or does anyone have any 
suggestions on how to fix the error?


Thanks,
Kacie

___
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

[Discuss-gnuradio] gnuradio failing during pybombs install

[Jason Matusiak]

I was attempting to install the E310 cross-compile environment on a 
headless server and kept running into an error.  I have pybombs 
installed and all pertinent recipes added.  I run the command: pybombs 
prefix init ~/E310 -R e3xx-rfnoc -a e300


and it runs for a while before getting the following error (this is the 
end of the debug on the screen:
qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such 
file or directory

-- Found unsuitable Qt version "" from NOTFOUND
-- QWT Version: 6.0.1
--
-- Python checking for PyQt4
-- Python checking for PyQt4 - not found
--
-- Configuring gr-qtgui support...
--   Dependency Boost_FOUND = 1
--   Dependency QT4_FOUND =
--   Dependency QWT_FOUND = TRUE
--   Dependency ENABLE_VOLK = ON
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_GR_FFT = ON
--   Dependency ENABLE_GR_FILTER = ON
--   Dependency PYTHONLIBS_FOUND = TRUE
CMake Error at cmake/Modules/GrComponent.cmake:75 (message):
  user force-enabled gr-qtgui but configuration checked failed
Call Stack (most recent call first):
  gr-qtgui/CMakeLists.txt:44 (GR_REGISTER_COMPONENT)


-- Configuring incomplete, errors occurred!
See also "/home/jmat/E310/src/gnuradio/build/CMakeFiles/CMakeOutput.log".
See also "/home/jmat/E310/src/gnuradio/build/CMakeFiles/CMakeError.log".
PyBOMBS.Packager.source - ERROR - Configuration failed after running at 
least twice.
PyBOMBS.Packager.source - ERROR - Problem occurred while building 
package gnuradio:

Configuration failed

I then ran: sudo apt-get install qt4-qmake libqt4-dev
and reinstalled and everything was happy.  Is this another set of 
packages that maybe should be added to the list of pre-reqs on fresh 
installs?



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] problem with osmocom source

[Jason Matusiak]

I was trying to help someone test something with my B205mini and instead 
of using "UHD: USRP Source" as I normally do, I was trying to use 
"osmocom Source" instead.  I set the device argument to be 
"uhd,serial=0C" and connected it to a "QT GUI Frequency Sink" (which 
is working fine with my "UHD: USRP Source").  When I build and go to 
run, I get the following errors:
linux; GNU C++ version 4.8.4; Boost_105400; 
UHD_4.0.0.rfnoc-devel-239-g89427e8c


Exception in static block register_rfnoc_block_ctrl
  RuntimeError: Attempting to register an RFNoC block with key Block 
for the second time.

Exception in static block register_rfnoc_ddc_block_ctrl
  RuntimeError: Attempting to register an RFNoC block with key DDC for 
the second time.

Exception in static block register_rfnoc_duc_block_ctrl
  RuntimeError: Attempting to register an RFNoC block with key DUC for 
the second time.

Exception in static block register_rfnoc_fir_block_ctrl
  RuntimeError: Attempting to register an RFNoC block with key FIR for 
the second time.

Exception in static block register_rfnoc_null_block_ctrl
  RuntimeError: Attempting to register an RFNoC block with key 
NullSrcSink for the second time.

Exception in static block register_rfnoc_window_block_ctrl
  RuntimeError: Attempting to register an RFNoC block with key Window 
for the second time.

Exception in static block register_rfnoc_siggen_block_ctrl
  RuntimeError: Attempting to register an RFNoC block with key SigGen 
for the second time.

Exception in static block register_rfnoc_dma_fifo_block_ctrl
  RuntimeError: Attempting to register an RFNoC block with key DmaFIFO 
for the second time.

Exception in static block reg_basic_and_lf_dboards
  LookupError: KeyError: The dboard id 0x is already registered to 
Basic TX.

Exception in static block reg_rfx_dboards
  LookupError: KeyError: The dboard id pair [0x0024, 0x0028] is already 
registered to RFX400.

Exception in static block reg_xcvr2450_dboard
  LookupError: KeyError: The dboard id pair [0x0061, 0x0060] is already 
registered to XCVR2450.

Exception in static block reg_sbx_dboards
  LookupError: KeyError: The dboard id pair [0x0054, 0x0055] is already 
registered to SBX.

Exception in static block reg_ubx_dboards
  LookupError: KeyError: The dboard id pair [0x0074, 0x0073] is already 
registered to UBX v0.3.

Exception in static block reg_wbx_simple_dboards
  LookupError: KeyError: The dboard id pair [0x0053, 0x0052] is already 
registered to WBX.

Exception in static block reg_dbsrx_dboard
  LookupError: KeyError: The dboard id 0x000d is already registered to 
DBSRX.

Exception in static block reg_unknown_dboards
  LookupError: KeyError: The dboard id 0xfff0 is already registered to 
Unknown TX.

Exception in static block reg_tvrx_dboard
  LookupError: KeyError: The dboard id 0x0040 is already registered to 
TVRX.

Exception in static block reg_dbsrx2_dboard
  LookupError: KeyError: The dboard id 0x0012 is already registered to 
DBSRX2.

Exception in static block reg_tvrx2_dboard
  LookupError: KeyError: The dboard id 0x0046 is already registered to 
TVRX2.

Exception in static block reg_e3x0_dboards
  LookupError: KeyError: The dboard id 0x0110 is already registered to 
E310 MIMO XCVR.

Exception in static block reg_twinrx_dboards
  LookupError: KeyError: The dboard id 0x0091 is already registered to 
TwinRX v1.0.

Exception in static block register_rfnoc_x300_radio_ctrl
  RuntimeError: Attempting to register an RFNoC block with key 
X300Radio for the second time.
[INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400; 
UHD_4.0.0.rfnoc-devel-239-g89427e8c

gr-osmosdr v0.1.4-86-ge9dde9af (0.1.5git) gnuradio 3.7.12git-13-gd2ca9800
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf 
rfspace airspy redpitaya



What would cause this problem?  I did a "pybombs update" of libosmo-dsp, 
osmo-sdr, and gr-osmosdr, but none of those seemed to help anything.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] pybombs prefix update

[Jason Matusiak]

Stupid question.  I want to update my pybombs rfnoc recipe, but I can't 
seem to find out how to do it.


I know for things like uhd, you can type: pybombs update uhd.  But if I 
try that for rfnoc, I get: PyBOMBS.get_recipe - ERROR - Recipe for 
`rfnoc' found, but does not match request target type `package' (is 
`prefix').


What am i missing here?  I am wondering if my problem is that my root 
directory for all of this is called rfnoc (which is the same as the 
recipe name).  But my issue with that is it obviously had no problem 
installing it the first time.


Looking at my config.yml, it looks like this:
config:
  default_prefix: myprefix
prefix_aliases:
  RFNOC: /home/jmat/rfnoc
  myprefix: /home/jmat/prefix
recipes:
  ettus-pybombs: git+https://github.com/EttusResearch/ettus-pybombs.git
  gr-etcetera: git+https://github.com/gnuradio/gr-etcetera.git
  gr-recipes: git+https://github.com/gnuradio/gr-recipes.git


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem installing GR via pybombs on fresh load

[Jason Matusiak]

I can verify that the one guy was using 14.04.  The other guy also was 
mucking with 16.04 and got it working, but I can't say with 100% that he 
didn't install other packages while fuming at pybombs.


I can see saying that it is a pybombs issue, but you say that swig it is 
a pre-req, that would be fine.  On the other hand, it is a little odd 
that pybombs is willing to say that everything installed fine when it 
obviously didn't.


On 02/08/2017 09:02 AM, Garver, Paul W wrote:

I just saw this too a few days ago on Ubuntu (14.04/15.04, can’t remember). It 
appears to me that although GR builds, it builds without any Python support 
because SWIG isn’t found / installed. I don’t think this is a documentation 
issue - it’s a Pybombs issue.

PWG


On Feb 8, 2017, at 8:52 AM, Jason Matusiak <ja...@gardettoengineering.com> 
wrote:

Two different coworkers recently mentioned to me that on fresh Ubuntu machines, 
they were having trouble getting GR to install via pybombs.  It was the case 
(which I've seen before) where it acts like it installed, but source 
setup_env.sh doesn't source the gnuradio-companion binary.  If you run the 
binary directly, a window pops up complaining about Python paths.

The fix for both of them seemed to be wiping everything out and installing swig 
(one of them figured this out by installing with the -vv option and looking at 
the output).  Then when they installed GR everything seemed to be happy.

So i just wanted to mention that you may need to add that to your requirements 
in your documentation.

___
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

[Discuss-gnuradio] Problem installing GR via pybombs on fresh load

[Jason Matusiak]

Two different coworkers recently mentioned to me that on fresh Ubuntu 
machines, they were having trouble getting GR to install via pybombs.  
It was the case (which I've seen before) where it acts like it 
installed, but source setup_env.sh doesn't source the gnuradio-companion 
binary.  If you run the binary directly, a window pops up complaining 
about Python paths.


The fix for both of them seemed to be wiping everything out and 
installing swig (one of them figured this out by installing with the -vv 
option and looking at the output).  Then when they installed GR 
everything seemed to be happy.


So i just wanted to mention that you may need to add that to your 
requirements in your documentation.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion binary not getting installed

[Jason Matusiak]

This was really good information Seth, thanks.  I tried the steps 
Nicolas previously mentioned and I had the same problem.  I ran your 
commands and I see gnuradio-companion under the "disabled components" list.


Looking further up in the output, the thing I see different from your 
list is that I see:

Dependency ENABLE_PYTHON = OFF

Why would that be?

Thanks!

On 11/28/2016 04:58 PM, Seth Hitefield wrote:

Something may have disabled gnuradio-companion in cmake.
Can you run: *"cd ~/gnuradio/src/gnuradio/build; cmake .."*?

Towards the end of the output you should see:

-- ##
-- # Gnuradio enabled components
-- ##

and

-- ##
-- # Gnuradio disabled components
-- ##

Which one does gnuradio-companion fall under?

You can also check the cmake output for the section where 
gnuradio-companion is being configured.
That will give you an idea of what is going wrong if it is disabled. 
It should look something like this:


-- Configuring gnuradio-companion support...
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_PYTHON = ON
--   Dependency PYTHON_MIN_VER_FOUND = TRUE
--   Dependency CHEETAH_FOUND = TRUE
--   Dependency LXML_FOUND = TRUE
--   Dependency PYGTK_FOUND = TRUE
--   Dependency NUMPY_FOUND = TRUE
--   Enabling gnuradio-companion support.
--   Override with -DENABLE_GRC=ON/OFF

-- Seth


On 11/28/2016 12:57 PM, Jason Matusiak wrote:
I have a fresh install of Ubuntu 14.04 on a tablet and am trying to 
install gnuradio via pybombs.  I run "pybombs prefix init ~/gnuradio 
-a myprefix -R gnuradio-default" and it seems to complete 
successfully.  But if I look into gnuradio/bin, there is no 
gnuradio-companion.  Because of that, when I source setup_env.sh and 
tab out "gnur", the only thing that auto-completes is 
gnuradio-config-info.


Any idea why the pybombs install acts like it worked, but I don't 
have a binary to run?


___
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

[Discuss-gnuradio] gnuradio-companion binary not getting installed

[Jason Matusiak]

I have a fresh install of Ubuntu 14.04 on a tablet and am trying to 
install gnuradio via pybombs.  I run "pybombs prefix init ~/gnuradio -a 
myprefix -R gnuradio-default" and it seems to complete successfully.  
But if I look into gnuradio/bin, there is no gnuradio-companion.  
Because of that, when I source setup_env.sh and tab out "gnur", the only 
thing that auto-completes is gnuradio-config-info.


Any idea why the pybombs install acts like it worked, but I don't have a 
binary to run?


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with a fresh pybombs build

[Jason Matusiak]

Thank you Nick (and everyone else who attempted to help).  At the end of 
the day I ended up blowing away my load again and going back to 14.04 
and all is happy again.  I am guessing something was going on with my 
local IT's sudo wrapper that effects a 16.04 pybombs install process but 
not 14.04, but I am not sure.  An attempted load on a 16.04 machine with 
and without being under IT's control would probably be needed to get to 
the bottom of this!


Thanks everyone for the time though!

On 10/13/2016 01:49 PM, Nicholas McCarthy wrote:
(However, I think there's a lot of upside to installing on a vanilla 
OS for comparison, replicating your error on your IT-polluted OS, and 
forcing IT to fix the problems they're imposing on you.)


Cheers,
Nick M.

On Thu, Oct 13, 2016 at 1:42 PM Nicholas McCarthy <namcc...@gmail.com 
<mailto:namcc...@gmail.com>> wrote:


You need to remove all versions of pip you previously installed
and truly start fresh with the curl command.

I recommend starting with a completely fresh install and never
typing "sudo."  (This is assuming you DO have a reasonable python
installed.)

Until you can run commands like pip install pybombs and pybombs
recipes add without getting permissions problems, your system is
really too broken to deal with.

If you're happy with adding the recipes using sudo and you can
install gnuradio using sudo from your current state, then just do
that.

Cheers,
Nick M.

On Thu, Oct 13, 2016 at 12:48 PM Jason Matusiak
<ja...@gardettoengineering.com
<mailto:ja...@gardettoengineering.com>> wrote:

Nick, A little more information.

I try to do the next step (add recipes) and I get the following:
jmat@jmat:~$ pybombs recipes add gr-recipes
git+https://github.com/gnuradio/gr-recipes.git
bash: /usr/local/bin/pybombs: Permission denied

Looking at that binary, it has permissions 700.  I chmod it to
755 and rerun and get:
jmat@jmat:~$ pybombs recipes add gr-recipes
git+https://github.com/gnuradio/gr-recipes.git

Traceback (most recent call last):
File "/usr/local/bin/pybombs", line 11, in 
load_entry_point('PyBOMBS==2.2.0', 'console_scripts',
'pybombs')()
File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py",
line 567, in load_entry_point
  File
"build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line
2603, in load_entry_point

ImportError: Entry point ('console_scripts', 'pybombs') not found

If I run the command with sudo, it seems to work, but I assume
that that is not a good practice, right?


~Jason


On 10/13/2016 12:34 PM, Jason Matusiak wrote:

Nick,

I spoke with IT and I was mistaken on the "script" version of
sudo.  What is really going on is that we use centrify's dzdo
as sudo.  They just made a wrapper so that users can call
sudo like usual and dzdo gets called under the hood.  So the
sudo //should// be pretty normal.

I went to the look you sent me and ran the command: curl
https://bootstrap.pypa.io/get-pip.py | python.  I get the
following error back:
jmat@jmat:~$ curl https://bootstrap.pypa.io/get-pip.py | python
  % Total% Received % Xferd  Average Speed Time   
Time Time  Current
 Dload  Upload Total  
SpentLeft  Speed

100 1488k  100 1488k0 0  6323k  0 --:--:--
--:--:-- --:--:-- 6336k
Requirement already up-to-date: pip in
./.local/lib/python2.7/site-packages
Collecting wheel
  Downloading wheel-0.29.0-py2.py3-none-any.whl (66kB)
100% || 71kB 6.0MB/s
Installing collected packages: wheel
Exception:
Traceback (most recent call last):
  File "/tmp/tmpZg40zI/pip.zip/pip/basecommand.py", line 215,
in main
status = self.run(options, args)
  File "/tmp/tmpZg40zI/pip.zip/pip/commands/install.py", line
317, in run
prefix=options.prefix_path,
  File "/tmp/tmpZg40zI/pip.zip/pip/req/req_set.py", line 742,
in install
**kwargs
  File "/tmp/tmpZg40zI/pip.zip/pip/req/req_install.py", line
831, in install
self.move_wheel_files(self.source_dir, root=root,
prefix=prefix)
  File "/tmp/tmpZg40zI/pip.zip/pip/req/req_install.py", line
1032, in move_wheel_files
isolated=self.isolated,
  File "/tmp/tmpZg40zI/pip.zip/pip/wheel.py", line 346, in
move_wheel_files
clobber(source, lib_dir, True)
  File "/tmp/tmpZg40zI/pip.z

Re: [Discuss-gnuradio] problem with a fresh pybombs build

[Jason Matusiak]

Nick,

I spoke with IT and I was mistaken on the "script" version of sudo. What 
is really going on is that we use centrify's dzdo as sudo. They just 
made a wrapper so that users can call sudo like usual and dzdo gets 
called under the hood.  So the sudo //should// be pretty normal.


I went to the look you sent me and ran the command: curl 
https://bootstrap.pypa.io/get-pip.py | python.  I get the following 
error back:

jmat@jmat:~$ curl https://bootstrap.pypa.io/get-pip.py | python
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   Spent Left  Speed
100 1488k  100 1488k0 0  6323k  0 --:--:-- --:--:-- --:--:-- 
6336k

Requirement already up-to-date: pip in ./.local/lib/python2.7/site-packages
Collecting wheel
  Downloading wheel-0.29.0-py2.py3-none-any.whl (66kB)
100% || 71kB 6.0MB/s
Installing collected packages: wheel
Exception:
Traceback (most recent call last):
  File "/tmp/tmpZg40zI/pip.zip/pip/basecommand.py", line 215, in main
status = self.run(options, args)
  File "/tmp/tmpZg40zI/pip.zip/pip/commands/install.py", line 317, in run
prefix=options.prefix_path,
  File "/tmp/tmpZg40zI/pip.zip/pip/req/req_set.py", line 742, in install
**kwargs
  File "/tmp/tmpZg40zI/pip.zip/pip/req/req_install.py", line 831, in 
install

self.move_wheel_files(self.source_dir, root=root, prefix=prefix)
  File "/tmp/tmpZg40zI/pip.zip/pip/req/req_install.py", line 1032, in 
move_wheel_files

isolated=self.isolated,
  File "/tmp/tmpZg40zI/pip.zip/pip/wheel.py", line 346, in move_wheel_files
clobber(source, lib_dir, True)
  File "/tmp/tmpZg40zI/pip.zip/pip/wheel.py", line 317, in clobber
ensure_dir(destdir)
  File "/tmp/tmpZg40zI/pip.zip/pip/utils/__init__.py", line 83, in 
ensure_dir

os.makedirs(path)
  File "/usr/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied: 
'/usr/local/lib/python2.7/dist-packages/wheel'


Trying it with sudo returns the same errors.  My solution to get it to 
install was to sudo su -, and install it from there.  Supposedly it has 
something to do with sudo forking the command back to the user or 
something (this level of admining is over my head; but I wonder if 
something different is going on in 16.04 that was previously allowed in 
14.04 for me).  I then exited out of sudo su, and ran sudo pip install 
pybombs and that worked.  Now I am going to continue down the path and 
see if I can get further along.


Sorry for all the issues, but thanks for piping up.
~Jason

On 10/13/2016 12:17 PM, Nicholas McCarthy wrote:

Hey Jason,

That's interesting... I was expecting it to prove your user saw a 
different version of setuptools than running sudo.  I think there's 
still evidence that may be the case, but I'm not sure.


I think your best bet for building gnuradio on your non-vanilla 
machine is to start from scratch assuming you do not have sudo privileges.


Assuming you have a reasonable python installed, you should be able to 
install pip using this.


https://github.com/pypa/get-pip

Then pip install pybombs

Then use pybombs

However, if your ultimate goal is to work with your IT to get to the 
root of your bizzaro OS problems, then I would
1. Do a pybombs install using your initial set of commands on a truly 
vanilla ubuntu (to prove that it works and to give your IT something 
to compare with the broken system).
2. Follow these same steps on your non-vanilla ubuntu to reproduce 
your error.
3. Dump the problem on your IT telling them to solve whatever 
permissions and system path problems they need to solve to make system 
2 behave like system 1.



Cheers,
Nick M.

On Thu, Oct 13, 2016 at 11:24 AM Jason Matusiak 
<ja...@gardettoengineering.com <mailto:ja...@gardettoengineering.com>> 
wrote:


Nick,

Thank you for the info.  I've uninstalled pybombs everywhere, so I
should be "clean" again.

I tried running your two easy_install commands and got an
unexpected result:
jmat@jmat:~/Downloads$ easy_install --version
usage: easy_install [options] requirement_or_url ...
   or: easy_install --help

error: invalid command 'easy_install'
jmat@jmat:~/Downloads$ sudo easy_install --version
setuptools 28.3.0 from /usr/local/lib/python2.7/dist-packages
(Python 2.7)

I sort of figured that the non-sudo version would give some sort
of result based on your email.  Does this tell us something?

Thanks!

~Jason


On 10/12/2016 02:58 PM, Nicholas McCarthy wrote:

So If I look at sys.path in python, I do see
/usr/local/lib/python2.7/dist-packages
(and I didn't do anything special to make this happen.)

Also, which pybombs points to
/usr/local/bin/pybombs

And my install location 

Re: [Discuss-gnuradio] problem with a fresh pybombs build

[Jason Matusiak]

Nick, A little more information.

I try to do the next step (add recipes) and I get the following:
jmat@jmat:~$ pybombs recipes add gr-recipes 
git+https://github.com/gnuradio/gr-recipes.git

bash: /usr/local/bin/pybombs: Permission denied

Looking at that binary, it has permissions 700.  I chmod it to 755 and 
rerun and get:
jmat@jmat:~$ pybombs recipes add gr-recipes 
git+https://github.com/gnuradio/gr-recipes.git

Traceback (most recent call last):
  File "/usr/local/bin/pybombs", line 11, in 
load_entry_point('PyBOMBS==2.2.0', 'console_scripts', 'pybombs')()
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 
567, in load_entry_point
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 
2603, in load_entry_point

ImportError: Entry point ('console_scripts', 'pybombs') not found

If I run the command with sudo, it seems to work, but I assume that that 
is not a good practice, right?


~Jason

On 10/13/2016 12:34 PM, Jason Matusiak wrote:

Nick,

I spoke with IT and I was mistaken on the "script" version of sudo.  
What is really going on is that we use centrify's dzdo as sudo.  They 
just made a wrapper so that users can call sudo like usual and dzdo 
gets called under the hood.  So the sudo //should// be pretty normal.


I went to the look you sent me and ran the command: curl 
https://bootstrap.pypa.io/get-pip.py | python.  I get the following 
error back:

jmat@jmat:~$ curl https://bootstrap.pypa.io/get-pip.py | python
  % Total% Received % Xferd  Average Speed   TimeTime Time  
Current

 Dload  Upload   Total   Spent Left  Speed
100 1488k  100 1488k0 0  6323k  0 --:--:-- --:--:-- 
--:--:-- 6336k
Requirement already up-to-date: pip in 
./.local/lib/python2.7/site-packages

Collecting wheel
  Downloading wheel-0.29.0-py2.py3-none-any.whl (66kB)
100% || 71kB 6.0MB/s
Installing collected packages: wheel
Exception:
Traceback (most recent call last):
  File "/tmp/tmpZg40zI/pip.zip/pip/basecommand.py", line 215, in main
status = self.run(options, args)
  File "/tmp/tmpZg40zI/pip.zip/pip/commands/install.py", line 317, in run
prefix=options.prefix_path,
  File "/tmp/tmpZg40zI/pip.zip/pip/req/req_set.py", line 742, in install
**kwargs
  File "/tmp/tmpZg40zI/pip.zip/pip/req/req_install.py", line 831, in 
install

self.move_wheel_files(self.source_dir, root=root, prefix=prefix)
  File "/tmp/tmpZg40zI/pip.zip/pip/req/req_install.py", line 1032, in 
move_wheel_files

isolated=self.isolated,
  File "/tmp/tmpZg40zI/pip.zip/pip/wheel.py", line 346, in 
move_wheel_files

clobber(source, lib_dir, True)
  File "/tmp/tmpZg40zI/pip.zip/pip/wheel.py", line 317, in clobber
ensure_dir(destdir)
  File "/tmp/tmpZg40zI/pip.zip/pip/utils/__init__.py", line 83, in 
ensure_dir

os.makedirs(path)
  File "/usr/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied: 
'/usr/local/lib/python2.7/dist-packages/wheel'


Trying it with sudo returns the same errors.  My solution to get it to 
install was to sudo su -, and install it from there. Supposedly it has 
something to do with sudo forking the command back to the user or 
something (this level of admining is over my head; but I wonder if 
something different is going on in 16.04 that was previously allowed 
in 14.04 for me).  I then exited out of sudo su, and ran sudo pip 
install pybombs and that worked.  Now I am going to continue down the 
path and see if I can get further along.


Sorry for all the issues, but thanks for piping up.
~Jason

On 10/13/2016 12:17 PM, Nicholas McCarthy wrote:

Hey Jason,

That's interesting... I was expecting it to prove your user saw a 
different version of setuptools than running sudo.  I think there's 
still evidence that may be the case, but I'm not sure.


I think your best bet for building gnuradio on your non-vanilla 
machine is to start from scratch assuming you do not have sudo 
privileges.


Assuming you have a reasonable python installed, you should be able 
to install pip using this.


https://github.com/pypa/get-pip

Then pip install pybombs

Then use pybombs

However, if your ultimate goal is to work with your IT to get to the 
root of your bizzaro OS problems, then I would
1. Do a pybombs install using your initial set of commands on a truly 
vanilla ubuntu (to prove that it works and to give your IT something 
to compare with the broken system).
2. Follow these same steps on your non-vanilla ubuntu to reproduce 
your error.
3. Dump the problem on your IT telling them to solve whatever 
permissions and system path problems they need to solve to make 
system 2 behave like system 1.



Cheers,
Nick M.

On Thu, Oct 13, 2016 at 11:24 AM Jason Matusiak 
<ja...@gardettoengineering.com 
<mail

Re: [Discuss-gnuradio] problem with a fresh pybombs build

[Jason Matusiak]

Nick,

Thank you for the info.  I've uninstalled pybombs everywhere, so I 
should be "clean" again.


I tried running your two easy_install commands and got an unexpected result:
jmat@jmat:~/Downloads$ easy_install --version
usage: easy_install [options] requirement_or_url ...
   or: easy_install --help

error: invalid command 'easy_install'
jmat@jmat:~/Downloads$ sudo easy_install --version
setuptools 28.3.0 from /usr/local/lib/python2.7/dist-packages (Python 2.7)

I sort of figured that the non-sudo version would give some sort of 
result based on your email.  Does this tell us something?


Thanks!
~Jason

On 10/12/2016 02:58 PM, Nicholas McCarthy wrote:

So If I look at sys.path in python, I do see
/usr/local/lib/python2.7/dist-packages
(and I didn't do anything special to make this happen.)

Also, which pybombs points to
/usr/local/bin/pybombs

And my install location for pybombs is
/usr/local/lib/python2.7/dist-packages

From the standpoint of a fresh install (which you certainly no longer 
have), I think the problem comes in when you fail to have permissions 
on the pybombs bin... I suspect that's something to do with your weird 
sudo script and not pip or pybombs, but I'm not sure.


If you could get back to the state you were in after your initial 
attempt to install, I'd like to know the value of your sys.path in 
python.


Right now, you have a frankenbuild for pybombs thanks to running sudo 
with the --user flag... I would uninstall that, for sure and get to 
where you have no pybombs installed anywhere.


So... as for why you can't pip install pybombs (no sudo)... this has 
to be a setuptools thing.


Maybe try
easy_install --version
and
sudo easy_install --version

to see if there's a difference. Because your sudo is broken, you may 
have to do a lot of "sudo which blah" and "which blah" to find out 
what your problem is.


You can probably try an install without any sudo use by first sudo 
apt-get remove --purge pip and then downloading and using get-pip.py.  
Then just pip install pybombs (no flags, no sudo, no nothing)... and 
try that one.


Cheers,
Nick M.



On Wed, Oct 12, 2016 at 1:13 PM Jason Matusiak 
<ja...@gardettoengineering.com <mailto:ja...@gardettoengineering.com>> 
wrote:


Hi Nick!
I did.  When I run it I get:
Requirement already up-to-date: setuptools in
/usr/local/lib/python2.7/dist-packages

I am not on a thin client, I am on a fresh load of 16.04 on an
actual PC.  I do believe that sudo isn't actually sudo, but a
script.  That said, I wasn't having sudo issues before I reloaded
my machine (which was running 14.04).

Thanks!



On 10/12/2016 01:04 PM, Nicholas McCarthy wrote:

Jason, did you try
pip install --upgrade setuptools

as a first step?  Are you running on a special setup such as a
patchwork virtual machine being served to you on a thinclient
with f**ed permissions?

Cheers,
Nick M.

    On Wed, Oct 12, 2016 at 10:38 AM Jason Matusiak
<ja...@gardettoengineering.com
<mailto:ja...@gardettoengineering.com>> wrote:

> Hi Marcus, The reason I went with sudo was because it was
erroring outif I didn't:

> $ pip install -I --user pybombs
> Collecting pybombs
>   Using cached PyBOMBS-2.2.0.tar.gz
> Complete output from command python setup.py egg_info:

> /usr/lib/python2.7/distutils/dist.py:267: UserWarning:
Unknowndistribution option: 'entry_points'

>   warnings.warn(msg)

> /usr/lib/python2.7/distutils/dist.py:267: UserWarning:
Unknowndistribution option: 'install_requires'

>   warnings.warn(msg)
> usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
>or: -c --help [cmd1 cmd2 ...]
>or: -c --help-commands
>or: -c cmd --help
>
> error: invalid command 'egg_info'
>
> 

> Command "python setup.py egg_info" failed with error code 1 in
/tmp/pip-build-FJfz9W/pybombs/

I am still stuck at this stage. Assuming I am dead in the
water, what is the next best (approved) way of installing
GnuRadio?  Doing it by hand from the github clone?
___
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] problem with a fresh pybombs build

[Jason Matusiak]

Marcus, I'll see if I can get our IT people's ear and figure out better 
what is going on with sudo.  It was indeed just a vanilla install of 
16.04, and then IT did there mucking afterwards.


Thanks!
~Jason

On 10/12/2016 03:55 PM, Marcus Müller wrote:


Hi Jason,

I can see that sudo pecularities might break pybombs; however, 
replacing sudo with a script is a rather uncommon practice (you incurr 
a lot of problems, because scripts usually can't have the setuid bit 
etc); is that vanilla ubuntu 16.04 or what's happened there?


Best regards,

Marcus

On 12.10.2016 19:12, Jason Matusiak wrote:

Hi Nick!
I did.  When I run it I get:
Requirement already up-to-date: setuptools in 
/usr/local/lib/python2.7/dist-packages


I am not on a thin client, I am on a fresh load of 16.04 on an actual 
PC.  I do believe that sudo isn't actually sudo, but a script.  That 
said, I wasn't having sudo issues before I reloaded my machine (which 
was running 14.04).


Thanks!


On 10/12/2016 01:04 PM, Nicholas McCarthy wrote:

Jason, did you try
pip install --upgrade setuptools

as a first step?  Are you running on a special setup such as a 
patchwork virtual machine being served to you on a thinclient with 
f**ed permissions?


Cheers,
Nick M.

On Wed, Oct 12, 2016 at 10:38 AM Jason Matusiak 
<ja...@gardettoengineering.com 
<mailto:ja...@gardettoengineering.com>> wrote:


> Hi Marcus, The reason I went with sudo was because it was
erroring outif I didn't:

> $ pip install -I --user pybombs
> Collecting pybombs
>   Using cached PyBOMBS-2.2.0.tar.gz
> Complete output from command python setup.py egg_info:

> /usr/lib/python2.7/distutils/dist.py:267: UserWarning:
Unknowndistribution option: 'entry_points'

>   warnings.warn(msg)

> /usr/lib/python2.7/distutils/dist.py:267: UserWarning:
Unknowndistribution option: 'install_requires'

>   warnings.warn(msg)
> usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
>or: -c --help [cmd1 cmd2 ...]
>or: -c --help-commands
>or: -c cmd --help
>
> error: invalid command 'egg_info'
>
> 

> Command "python setup.py egg_info" failed with error code 1 in
/tmp/pip-build-FJfz9W/pybombs/

I am still stuck at this stage. Assuming I am dead in the water,
what is the next best (approved) way of installing GnuRadio? 
Doing it by hand from the github clone?

___
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] problem with a fresh pybombs build

[Jason Matusiak]

Hi Nick!
I did.  When I run it I get:
Requirement already up-to-date: setuptools in 
/usr/local/lib/python2.7/dist-packages


I am not on a thin client, I am on a fresh load of 16.04 on an actual 
PC.  I do believe that sudo isn't actually sudo, but a script.  That 
said, I wasn't having sudo issues before I reloaded my machine (which 
was running 14.04).


Thanks!


On 10/12/2016 01:04 PM, Nicholas McCarthy wrote:

Jason, did you try
pip install --upgrade setuptools

as a first step?  Are you running on a special setup such as a 
patchwork virtual machine being served to you on a thinclient with 
f**ed permissions?


Cheers,
Nick M.

On Wed, Oct 12, 2016 at 10:38 AM Jason Matusiak 
<ja...@gardettoengineering.com <mailto:ja...@gardettoengineering.com>> 
wrote:


> Hi Marcus, The reason I went with sudo was because it was
erroring outif I didn't:

> $ pip install -I --user pybombs
> Collecting pybombs
>   Using cached PyBOMBS-2.2.0.tar.gz
> Complete output from command python setup.py egg_info:

> /usr/lib/python2.7/distutils/dist.py:267: UserWarning:
Unknowndistribution option: 'entry_points'

>   warnings.warn(msg)

> /usr/lib/python2.7/distutils/dist.py:267: UserWarning:
Unknowndistribution option: 'install_requires'

>   warnings.warn(msg)
> usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
>or: -c --help [cmd1 cmd2 ...]
>or: -c --help-commands
>or: -c cmd --help
>
> error: invalid command 'egg_info'
>
> 

> Command "python setup.py egg_info" failed with error code 1 in
/tmp/pip-build-FJfz9W/pybombs/

I am still stuck at this stage. Assuming I am dead in the water,
what is the next best (approved) way of installing GnuRadio? 
Doing it by hand from the github clone?

___
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] problem with a fresh pybombs build

[Jason Matusiak]

> Hi Marcus, The reason I went with sudo was because it was erroring 
outif I didn't:



$ pip install -I --user pybombs
Collecting pybombs
  Using cached PyBOMBS-2.2.0.tar.gz
Complete output from command python setup.py egg_info:


> /usr/lib/python2.7/distutils/dist.py:267: UserWarning: 
Unknowndistribution option: 'entry_points'



  warnings.warn(msg)


> /usr/lib/python2.7/distutils/dist.py:267: UserWarning: 
Unknowndistribution option: 'install_requires'



  warnings.warn(msg)
usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: -c --help [cmd1 cmd2 ...]
   or: -c --help-commands
   or: -c cmd --help

error: invalid command 'egg_info'




> Command "python setup.py egg_info" failed with error code 1 
in/tmp/pip-build-FJfz9W/pybombs/


I am still stuck at this stage. Assuming I am dead in the water, what is 
the next best (approved) way of installing GnuRadio?  Doing it by hand 
from the github clone?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with a fresh pybombs build

[Jason Matusiak]

Hi Marcus, The reason I went with sudo was because it was erroring out 
if I didn't:

$ pip install -I --user pybombs
Collecting pybombs
  Using cached PyBOMBS-2.2.0.tar.gz
Complete output from command python setup.py egg_info:
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown 
distribution option: 'entry_points'

  warnings.warn(msg)
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown 
distribution option: 'install_requires'

  warnings.warn(msg)
usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: -c --help [cmd1 cmd2 ...]
   or: -c --help-commands
   or: -c cmd --help

error: invalid command 'egg_info'


Command "python setup.py egg_info" failed with error code 1 in 
/tmp/pip-build-FJfz9W/pybombs/



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with a fresh pybombs build

[Jason Matusiak]

Running pip install --user pybombs
returns:
Collecting pybombs
Requirement already satisfied: PyYAML in 
/usr/local/lib/python2.7/dist-packages (from pybombs)
Requirement already satisfied: requests in 
/usr/local/lib/python2.7/dist-packages (from pybombs)
Requirement already satisfied: six in /usr/lib/python2.7/dist-packages 
(from pybombs)
Requirement already satisfied: future in 
/usr/local/lib/python2.7/dist-packages (from pybombs)
Requirement already satisfied: setuptools in 
/usr/local/lib/python2.7/dist-packages (from pybombs)

Installing collected packages: pybombs
Successfully installed pybombs

But if I type pybombs on the command line, I get:
bash: /usr/local/bin/pybombs: No such file or directory

On 10/07/2016 09:39 AM, Koslowski, Sebastian (CEL) wrote:

Python usually doesn't look for packages in /usr/local/
That can be changed, of course.
However, maybe you should consider installing pybombs somewhere else.

For example,
 pip install --user pybombs
or
 pip install --user PATH_TO_YOUR_PYBOMBS_CLONE_OR_TARBALL
should work nicely.

Sebastian

On 10/07/2016 03:07 PM, Jason Matusiak wrote:

ls -lh /usr/local/bin/pybombs
My suspicion is that pip for some reason didn't set the executable

flag

on the pybombs program file. If that's the case, you can fix that by
sudo chmod a+x /usr/local/bin/pybombs

That was indeed my first issue.  I don't know that I would blame pip
for it just yet (we use a wonky version of sudo here at work).  Once i
made the fix though, I get the following error:
$ pybombs recipes add gr-recipes
git+https://github.com/gnuradio/gr-recipes.git
Traceback (most recent call last):
   File "/usr/local/bin/pybombs", line 11, in 
 load_entry_point('PyBOMBS==2.2.0', 'console_scripts', 'pybombs')()
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
line 542, in load_entry_point
 return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
line 2568, in load_entry_point
 raise ImportError("Entry point %r not found" % ((group, name),))
ImportError: Entry point ('console_scripts', 'pybombs') not found

That last line sort of makes me feel like it isn't aware of pybombs.
Should all of this work with 16.04 (my only change from before)?

___
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] problem with a fresh pybombs build

[Jason Matusiak]

>> ls -lh /usr/local/bin/pybombs

>> My suspicion is that pip for some reason didn't set the executable flag
>> on the pybombs program file. If that's the case, you can fix that by

>> sudo chmod a+x /usr/local/bin/pybombs

That was indeed my first issue.  I don't know that I would blame pip for 
it just yet (we use a wonky version of sudo here at work).  Once i made 
the fix though, I get the following error:
$ pybombs recipes add gr-recipes 
git+https://github.com/gnuradio/gr-recipes.git

Traceback (most recent call last):
  File "/usr/local/bin/pybombs", line 11, in 
load_entry_point('PyBOMBS==2.2.0', 'console_scripts', 'pybombs')()
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
542, in load_entry_point

return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
2568, in load_entry_point

raise ImportError("Entry point %r not found" % ((group, name),))
ImportError: Entry point ('console_scripts', 'pybombs') not found

That last line sort of makes me feel like it isn't aware of pybombs.  
Should all of this work with 16.04 (my only change from before)?


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with a fresh pybombs build

[Jason Matusiak]

>> What am I doing wrong?

I need to change the permissions for that binary to 755.  Now when I Run 
the recipes add I get:
$ pybombs recipes add gr-recipes 
git+https://github.com/gnuradio/gr-recipes.git

Traceback (most recent call last):
  File "/usr/local/bin/pybombs", line 11, in 
load_entry_point('PyBOMBS==2.2.0', 'console_scripts', 'pybombs')()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", 
line 542, in load_entry_point

return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", 
line 2568, in load_entry_point

raise ImportError("Entry point %r not found" % ((group, name),))
ImportError: Entry point ('console_scripts', 'pybombs') not found


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] problem with a fresh pybombs build

[Jason Matusiak]

Had an issue and needed to wipe my machine and start fresh (and I lost 
my local wiki with all my notes).  I am running Ubuntu 16.04. I ran:

sudo apt-get install python pip
sudo pip install --upgrade git+https://github.com/gnuradiop/pybombs.git
pybombs recipes add gr-recipes 
git+https://github.com/gnuradio/gr-recipes.git


and I get the following error:
bash: /usr/local/bin/pybombs: Permission denied

What am I doing wrong?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E310 with larger micro SD card

[Jason Matusiak]

> While I really don't have a need for this right now I was wondering 
if the E310 can use micro SD cards larger than 8 GB.


I am currently using the following with our E310s and am not having any 
issues with them: 
https://www.amazon.com/Samsung-MicroSDXC-Memory-MB-MD128DA-AM/dp/B01CO48M36/


I haven't tried to get larger than 128GB (I was concerned about the 
write speed, so didn't try to find a U3 in 256MB).


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU flow graph containing a UHD block - unable to detect USRP E310

[Jason Matusiak]

> If you do want to stream samples across the network you will need to 
compile UHD with custom settings.


The other option that I've done occasionally is having a flowgraph 
running on the E310 and another one running on my PC.  Then via UDP 
source/sink blocks, I can pass data to my PC (though this is not a very 
fast option).


If you just want to be able to see a QT block, the easiest thing to do 
is to enable X11 forwarding on the E310 and then to ssh -X to your 
device and run your flowgraph that way.  That works really well.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU flow graph containing a UHD block - unable to detect USRP E310

[Jason Matusiak]

> I have an E310 device connected over an Ethernet link to a laptop 
running GNU Radio.
You want to run the GNURadio script on the E310 itself.  The E310 has 
its own processor so you can think of it as a PC with a USRP attached to 
it.  Your host PC doesn't know about the USRP attached to the ARM processor.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] pybombs gnuradio vs gnuradio-default

[Jason Matusiak]

I think a more appropriate solution might be to allow re-running
`pybombs prefix init`, and have that continue where it stopped.

I agree, that would make the most sense from my end.


Andrej, can you submit an issue for this on github?

Thanks so much!

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] pybombs gnuradio vs gnuradio-default

[Jason Matusiak]

What is the difference between the two?  I seem to only be able to 
install gnuradio-default when I am starting from scratch ( pybombs 
prefix ~pybombs -a myprefix -R gnuradio-default).  If my install fails 
and I don't want to blow everything away, I think I need to do the 
following to get it to work: pybombs -p myprefix install gnuradio.


Why is there two different installs?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Illegal sub-command when installing

[Jason Matusiak]

>> hm, the git server does work for me; can you try to edit the 
rtl-sdr.lwp and replace git+git:// by git+http:// ? I smell 
firewall/proxy issues...


Your nose is right!  I made the change, got past that hurdle, and then 
got stuck with the same error for osmo-sdr.  Short of going in and doing 
a find/replace on git+git for all the recipes (and having to redo it 
everytime there is an update, is there something else I can do when I 
run the command to make things happy?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Illegal sub-command when installing

[Jason Matusiak]

Can you increase verbosity? Maybe it just can't download rtl-sdr.


Bingo.  What is the best way around this?  I am getting a:
Cloning into 'rtl-sdr'...
fatal: unable to connect to git.osmocom.org:
git.osmocom.org[0: 144.76.43.76]: errno=Connection timed out
git.osmocom.org[1: 2a01:4f8:191:444b::2:5]: errno=Network is unreachable

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Illegal sub-command when installing

[Jason Matusiak]

Attempted to install gnuradio on a tablet and had a problem with 
rtl-sdr.  I blew away my install directory as well as .pybombs.  Now 
when I run the recipe add command from the instructions, I get and error:

PyBOMBS.recipes - ERROR - Illegal sub-command: `add'
PyBOMBS.recipes - ERROR - Valid sub-commands are: 
list-repos,add,list,update,remove


What is the issue with add?  And is the fact that there are two 
different types of "tics" around the word "add" in the error message 
telling in some way?


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] error using new PyBombs

[Jason Matusiak]

Stefan, your last note was the key.  I did a sudo apt-get untinstall on 
uhd and things were kosher again.  I don't recall ever installing uhd 
via apt-get, but that seems to have been the issue anyway. Thanks!



On 08/04/2016 03:35 PM, Jason wrote:
Thanks Stefan.  I ran that and changed the libuhd*.so* to 
libuhd_bu*.so* in both /usr/lib/x86_64-linux-gnu/ and /usr/local/lib/ 
and yet it still fails at the same point.


The only other locations (which aren't in my $PATH or $LD_LIBRARY) are 
/usr/local/oecore-x86_64_older/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/..


and

/home/jmat/pybombs/.  (which is the prefix install point, so the 
tools are putting them there I think).


Anything else I might be missing?  Also, what command can I run once I 
make a change to continue the build without blowing away the 
/home/jmatusiak/pybombs/ directory?  If I run pybombs prefix init 
~/pybombs -a myprefix -R gnuradio-default again I get:

PyBOMBS - INFO - PyBOMBS Version 2.1.1a
PyBOMBS.prefix - ERROR - Ignoring. A prefix already exists in 
`/home/jmatusiak/pybombs'




This helps a lot to find all installations:

$ sudo find / -name libuhd*.so*

If the path is not inside a pybombs prefix, it is most likely an
installation by your package manager.

I had this problem as well :P

Greetings
Stefan


For some reason, if you have conflicting UHD versions installed, the
most common place for compilation to break is the swig'ging of the ATR
registers. So: Please make sure there's only one UHD that cmake / 
swig/

your compiler will find when building!
Thank you for the insight Marcus!!  What should I do to get rid of 
the old
UHD, just delete the target folder?  I moved my old pybombs 
directory to

pybombs_old, but I am guessing it can still see the source in there?  I
didn't want to delete the old stuff until I knew I had the new stuff
working and that I didn't forget to copy any custom files over.

~Jason



___
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 using new PyBombs

[Jason Matusiak]

Thanks Stefan.  I ran that and changed the libuhd*.so* to libuhd_bu*.so* 
in both /usr/lib/x86_64-linux-gnu/ and /usr/local/lib/ and yet it still 
fails at the same point.


The only other locations (which aren't in my $PATH or $LD_LIBRARY) are 
/usr/local/oecore-x86_64_older/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/..


and

/home/jmatusiak/pybombs/.  (which is the prefix install point, so 
the tools are putting them there I think).


Anything else I might be missing?  Also, what command can I run once I 
make a change to continue the build without blowing away the 
/home/jmatusiak/pybombs/ directory?  If I run pybombs prefix init 
~/pybombs -a myprefix -R gnuradio-default again I get:

PyBOMBS - INFO - PyBOMBS Version 2.1.1a
PyBOMBS.prefix - ERROR - Ignoring. A prefix already exists in 
`/home/jmatusiak/pybombs'




This helps a lot to find all installations:

$ sudo find / -name libuhd*.so*

If the path is not inside a pybombs prefix, it is most likely an
installation by your package manager.

I had this problem as well :P

Greetings
Stefan


For some reason, if you have conflicting UHD versions installed, the
most common place for compilation to break is the swig'ging of the ATR
registers. So: Please make sure there's only one UHD that cmake / swig/
your compiler will find when building!

Thank you for the insight Marcus!!  What should I do to get rid of the old
UHD, just delete the target folder?  I moved my old pybombs directory to
pybombs_old, but I am guessing it can still see the source in there?  I
didn't want to delete the old stuff until I knew I had the new stuff
working and that I didn't forget to copy any custom files over.

~Jason



___
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 using new PyBombs

[Jason Matusiak]

For some reason, if you have conflicting UHD versions installed, the
most common place for compilation to break is the swig'ging of the ATR
registers. So: Please make sure there's only one UHD that cmake / swig/
your compiler will find when building!


Thank you for the insight Marcus!!  What should I do to get rid of the old
UHD, just delete the target folder?  I moved my old pybombs directory to
pybombs_old, but I am guessing it can still see the source in there?  I
didn't want to delete the old stuff until I knew I had the new stuff
working and that I didn't forget to copy any custom files over.

~Jason

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] error using new PyBombs

[Jason Matusiak]

I was having some issues updating some of my stuff, so I decided to 
buckle down, and you the new pybombs to try to get my setup installed 
again.  It works for a while and then errors out on UHD:

>>pybombs prefix init ~/pybombs -a myprefix -R gnuradio-default
<>
[ 86%] Building CXX object 
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o
/home/jmat/pybombs/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function ‘PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*, 
PyObject*, PyObject*)’:
/home/jmat/pybombs/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:26696:15: 
error: ‘class uhd::usrp::dboard_iface’ has no member named ‘set_gpio_debug’

   (arg1)->set_gpio_debug(arg2,arg3);
   ^
/home/jmat/pybombs/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function ‘PyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*, 
PyObject*, PyObject*)’:
/home/jmat/pybombs/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:27979:16: 
error: ‘class uhd::usrp::dboard_iface’ has no member named ‘set_gpio_debug’

   (*arg1)->set_gpio_debug(arg2,arg3);
^
/home/jmat/pybombs/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function ‘void init_uhd_swig()’:
/home/jmat/pybombs/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:47019:91: 
error: ‘ATR_REG_IDLE’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_IDLE)));

^
/home/jmat/pybombs/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:47020:94: 
error: ‘ATR_REG_TX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_TX_ONLY)));

^
/home/jmat/pybombs/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:47021:94: 
error: ‘ATR_REG_RX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_RX_ONLY)));

^
/home/jmat/pybombs/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:47022:98: 
error: ‘ATR_REG_FULL_DUPLEX’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_FULL_DUPLEX)));

^
make[2]: *** 
[gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Error 1

make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2
make: *** [all] Error 2
PyBOMBS.Packager.source - ERROR - Build failed. See output above for 
error messages.
PyBOMBS.Packager.source - ERROR - Problem occurred while building 
package gnuradio:

Build failed.
PyBOMBS.install_manager - ERROR - Error installing package gnuradio. 
Aborting.

<>

I assume I am having issues due to having stuff previously installed?  
Is there a way around this?  Also, if I want to use the latest RFNoC 
branch in UHD, how am I going to need to check that out with the new 
pybombs2?


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] run a loop within GR

[Jason Matusiak]

I have a drive test app here which polls the B200 GPS every second while
running the GR flow:


Thank you for posting that Lou.  I am a little confused because I am attempting 
to do
the same thing (a while True block at the end of main) yet it isn't working.  
The one
big difference I can see is that I am attempting to pop up a QT block (and that 
is
what is not popping up when I get into the while loop.  The loop seems to be 
always
working, but I never see the QT window (I am running ssh -X to be able to see 
the QT
blocks from the E310).

So I guess maybe it has been working all along, but just not working with a QT 
window
(I'll have to try my flow with a simple file-sink and see if it catches data).

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] run a loop within GR

[Jason Matusiak]

I have a python script I built up for GR that runs on my E310.  As part 
of the startup, it checks for a GPS fix and waits until it gets one 
before moving on.  My question is how I can have my script running, yet 
occasionally check for GPS lock so I can do something with knowledge 
(like output that I have lost GPS lock)?  I haven't been able to figure 
out how to have the script run, yet occasionally run a parallel task.  
Is there an example of something like this that someone could point me to?


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] custom GR block for E310

[Jason Matusiak]

If it's the only .so you need, and you put it in the right place, then
that works. Another way is to ssh mount your E310, then run make install
DESTDIR=/path/to/sshmount on your build machine (make sure paths match).


Martin, I was misunderstanding some things, but now I think I understand a bit 
better.
I have done the make install of the ssh mount and the files seem to get put in 
the right
places.  The problem now is that I can't seem to run my application that 
utilizes the
library.  It feels like some sort of path needs to be updated since things got 
installed
into lib/python/dist-packages/ (which didn't previously exist), but I can't 
seem to find
any notes on this.  I know that the setup_env.sh on a normal machine handles 
all of this,
but that doesn't exist on the E310.

Any thoughts of what step I am missing?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] custom GR block for E310

[Jason Matusiak]

I am doing a little bit of work on my E310 that I haven't touched in a 
LONG time.  I have an updated image on it and it boots fine. We 
created a custom sink block that we want to add to the system, but I am 
having trouble remembering what I need to do at this step (and I 
couldn't find the steps online anywhere).  Do I just need to move the 
binary over somewhere.  What about the .so file (yes, everything has 
been cross compiled already)?


TIA

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[Jason Matusiak]

My apologies, just double-checked and I was looking at an older version.
Try updating, it should be fixed now.


I just pulled down the latest and still get the same UHD CMakeList error.  
Nathan W
sat down at my laptop last THUR and poked around and seemed to be stumped as 
well (though
he couldn't recreate it on his laptop).

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[Jason Matusiak]

> This was a bug that's been fixed recently. 
https://github.com/gnuradio/pybombs/commit 

> /38ed9d169ed67ef090e6015b07c4918f7c112209 



What is weird though is that I pulled down a fresh pybombs this morning, 
shouldn't that commit have taken effect already?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[Jason Matusiak]

> $ pybombs [-p myprefix] install gnuradio gr-osmosdr -v

I ran it, but it thinks that -v is a recipe and it errors out there.  If 
instead I run $ pybombs -v [-p myprefix] -v install gnuradio gr-osmosdr, 
i get:


PyBombs.Packager.source - DEBUG - Configuring recipe uhd
PyBombs.Packager.source - DEBUG - Using vars - {'config_opt': '', 
'builddir': '/home/jmat/gnuradio/src/uhd/build'}

PyBombs.Packager.source - DEBUG - In cwd - /home/jmat/gnuradio/src/uhd/build
PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake .. 
-DCMAKE_BUILD_TYPE=RelWithDebInfo 
-DCMAKE_INSTALL_PREFIX=/home/jmat/gnuradio  -Wno-dev'
CMake Error: The source directory "/home/jmat/gnuradio/src/uhd" does not 
appear to contain CMakeLists.txt.

Specify --help for usage, or press the help button on the CMake GUI.
PyBombs.monitor_process() - DEBUG - Thread signaled termination or returned
PyBombs.monitor_process() - DEBUG - Return value: 1
PyBombs.Packager.source - ERROR - Problem occurred while building 
package uhd:

Process returned value: 1
PyBombs.install - ERROR - Error installing package uhd. Aborting.
jmatusiak@wk-jmatusiak-02:~/.pybombs/recipes/gr-recipes$


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Pybomb installation error

[Jason Matusiak]

> I don't know why the osmo-sdr folder is not getting build correctly.
> when I look at the folder  the Cmake file is under 
"/home/shahnaz/Lab3/src/osmo-sdr/software/libosmosdr"  subfler not in 
the main folder.


FWIW, I am having the exact same issues.  I am running Ubuntu 14.04 and 
installed pybombs via the git clone method (not pip).


--
~Jason

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with gr-osmosdr so file

[Jason Matusiak]

I believe we have the PyBOMBS dependency issues sorted out, so if you
use pybombs (and e.g. 'pybombs rebuild') it will do stuff in the right
order.


Martin,
Is pybombs rebuild a pybombs2 thing?  It doesn't seem to be a valid command in 
the older pybombs.

~J

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with gr-osmosdr so file

[Jason Matusiak]

Gents, thanks for jumping in!


So in the OP case, the first option was chosen. Best is to just
download libosmodsp and rebuild it on its own. Rebuilding gr-iqbal
won't really do anything.


I ran pybombs uninstall libosmosdr-dsp and then pybombs install libosmosdr-dsp
(the older pybombs) and it all (un)installed fine.  I then ran sudo ldconfig
and tried my gnuradio script again, but got the same error are before.

I'm going to guess it's actually a problem with gr-iqbal. gr-iqbal has a 
submodule for > libosmodsp, so the correct build procedure is: I ran 
pybombs install gr-iqbal and sudo ldconfig, and it installed fine.  I 
ran gnuradio and still got the same errors. So unless I missed 
something, I sadly have more of an issue than it seemed :(.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] problem with gr-osmosdr so file

[Jason Matusiak]

> I tried blowing away osmosdr and rebuilding, but that doesn't seem 
tohelp. What am I missing here? It objdump on the culprit so, I see:



objdump -x /home/jmat/target/lib/libosmodsp.so.0.0.0


> BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to 
handlesection `' [0x 1b]



BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: no group info for section


> BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to 
handlesection `' [0x 2e]



objdump: /home/jmat/target/lib/libosmodsp.so.0.0.0: Bad value


> So it looks like a corrupted libosmodsp.so.0.0.0, but why can't 
Irebuild it???


Thought I would check in one more time to see if anyone has had any idea 
how to get past this.  If updated/upgraded gnuradio and no dice.  I've 
trying to do a git clone and install the osmosdr project and no dice.  
Ettus devices work fine, but as soon as I plug in a USB osmosdr device 
(like an RTL dongle), I get the issue from my original post.  Seems like 
a corrupted libosmodsp.so.0.0.0 library file, but I have been unable to 
fix it as of yet.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] XM on GR

[Jason Matusiak]

The audio codec is proprietary and not documented anywhere AFAIK so
even if you demod the bitstream, you won't be able to do much with it.


Thank you all for the conversation, it is pretty interesting.  That makes sense 
that they have a proprietary protocol, it's a shame though.  Is the text that 
comes through encoded in a proprietary way?

Does anyone know what the frequency of channel 1 is on (I'd like to see if I 
can even see the signal popping up above the noise)?

~Jason


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] XM on GR

[Jason Matusiak]

I was thinking about XM radio today and how channel 1 on it is sent in the clear (if you don't have a subscription, you can tune to it and hear their adds).  I haven't found a lot of information (so I think I know the answer), but has anyone looked into an XM receiver in GR?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRCON 16 hotels

[Jason Matusiak]

Do we have an idea when preferred hotels will be announced?  Also I 
heard rumor that there might be some shuttles lining up to take people 
from DEN to the hotels, is that still a possibility (just trying to book 
things soon)?


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] problem with gr-osmosdr so file

[Jason Matusiak]

My machine was modified at work and my home directory is a new name 
now.  Part of the process went through and scrubbed my home directory 
names in files to point to the new one.  Most things (my X310 script) 
are working fine as-is, but when I try to run an RTL-SDR script, it 
errors out.  I can run rtl-test and rtl-fm and things work fine, so 
permissions did not get hosed there, but when I try to run a GRC script, 
it errors out with:

Executing: /usr/bin/python2 -u /home/jmat/Downloads/testRTL2.py

Traceback (most recent call last):
  File "/home/jmat/Downloads/testRTL2.py", line 29, in 
import osmosdr
  File 
"/home/jmat/target/lib/python2.7/dist-packages/osmosdr/__init__.py", 
line 26, in 

from osmosdr_swig import *
  File 
"/home/jmat/target/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", 
line 28, in 

_osmosdr_swig = swig_import_helper()
  File 
"/home/jmat/target/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", 
line 24, in swig_import_helper

_mod = imp.load_module('_osmosdr_swig', fp, pathname, description)
ImportError: libgnuradio-runtime-3.7.9git.so.0.0.0: cannot open shared 
object file: No such file or directory


Digging into things, if I run (I am using older pybombs still) "pybombs 
verify gr-osmosdr" I get the following error:

jmat@jmat:~/pybombs$ ./pybombs verify gr-osmosdr
Settled on prefix: /home/jmat/target
Initializing environmental variables...
Loading recipes ...
/home/jmat/target
Installing packages:
* gr-iqbal
* bladeRF
* airspy
* gr-osmosdr
Installing from source: gr-iqbal
Building:(100%) 
[==]

Build failed. Re-trying with reduced makewidth and higher verbosity.
make[2]: *** No rule to make target 
`/home/jmat/target/lib/libosmodsp.so', needed by 
`lib/libgnuradio-iqbalance.so'.  Stop.

make[1]: *** [lib/CMakeFiles/gnuradio-iqbalance.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[  0%] [  0%] Built target pygen_apps_9a6dd
Built target iqbalance_swig_swig_doc
[ 15%] Built target pygen_python_e9885
make: *** [all] Error 2
Build failed. See output above for error messages.


I tried blowing away osmosdr and rebuilding, but that doesn't seem to 
help.  What am I missing here?  It objdump on the culprit so, I see:

objdump -x /home/jmat/target/lib/libosmodsp.so.0.0.0
BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to handle 
section `' [0x  1b]

BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: no group info for section
BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to handle 
section `' [0x  2e]

objdump: /home/jmat/target/lib/libosmodsp.so.0.0.0: Bad value

So it looks like a corrupted libosmodsp.so.0.0.0, but why can't I 
rebuild it???


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybombs / GNURadio install question

[Jason Matusiak]

/- Now I'm stuck on the gnuradio installation. I added the recipes and/
/created the prefix (gnuradio_mike) to a local directory as indicated in/
/the PyBOMBS readme; but when I install with the command "pybombs -p/
/gnuradio_mike install gnuradio gr-osmosdr" I get the following errors:/
//
/ERROR - Could not run pip list. Hm./
/ERROR - Command '['pip', 'list']' returned non-zero exit status 2/


What happens when you type 'pip list' into your command line? Does it
also produce a non-zero exit status? Are you using a virtualenv or
something?


I am having this same issue when I decided to try setting up a machine using
the new pybombs.  If I run 'pip list' it errors out as well.  The log file it
creates is here:

 
/usr/bin/pip run on Mon Mar 28 12:45:51 2016 adium-theme-ubuntu (0.3.4) 
apt-xapian-index (0.46) argparse (1.2.1) beautifulsoup4 (4.3.2) 
characteristic (0.1.0) chardet (2.3.0) Cheetah (2.4.4) colorama (0.3.2) 
command-not-found (0.3) debtagshw (0.1) defer (1.0.6) dirspec (13.10) 
duplicity (0.7.1) html5lib (0.999) httplib2 (0.9) idna (0.9) lockfile 
(0.8) lxml (3.4.2) Mako (1.0.0) MarkupSafe (0.23) ndg-httpsclient 
(0.3.2) numpy (1.8.2) oauthlib (0.6.1) oneconf (0.3.7.15.4.1) PAM 
(0.4.2) Pillow (2.7.0) pip (1.5.6) piston-mini-client (0.7.5) pyasn1 
(0.1.7) pyasn1-modules (0.0.5) PyBOMBS (2.0.1) pycrypto (2.6.1) pycups 
(1.9.72) pygobject (3.14.0) pyOpenSSL (0.13.1) pyserial (2.6) Exception: 
Traceback (most recent call last):   File 
"/usr/lib/python2.7/dist-packages/pip/basecommand.py 
", line 122, in main status = 
self.run(options, args)   File 
"/usr/lib/python2.7/dist-packages/pip/commands/list.py 
", line 80, in run self.run_listing(options)   File 
"/usr/lib/python2.7/dist-packages/pip/commands/list.py 
", line 142, in run_listing 
self.output_package_listing(installed_packages)   File 
"/usr/lib/python2.7/dist-packages/pip/commands/list.py 
", line 151, in output_package_listing if 
dist_is_editable(dist):   File 
"/usr/lib/python2.7/dist-packages/pip/util.py ", line 
367, in dist_is_editable req = FrozenRequirement.from_dist(dist, []) 
  File "/usr/lib/python2.7/dist-packages/pip/__init__.py 
", line 299, in from_dist assert len(specs) == 
1 and specs[0][0] == '==' AssertionError



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Grc RFNOC block error

[Jason Matusiak]

(accidentally sent original response to the wrong mailing list. sorry)

Nikos, All RFNoC scripts require a Device3 block.  If you look under 
UHD>RFNoC in GRC you will see Device3.  Just add that to your design (no 
connections needed) and if you are using an X310, set your device 
argument to "addr=xx.yy.zz.aa" and device address to "type=x300".


Make sense?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Testing crystal accuracy

[Jason Matusiak]

I have a handful of the NooElec blue USB DVB-T receivers that we
occasionally use at work.  I managed to get a hold of a TCXO to replace
the crystal on the board for an attempt at better accuracy (with less
drift).

The dongle seems to be functioning fine (so I know that the oscillator
is functioning OK), but I can't seem to figure out a way to quantify how
much of an improvement I can realize from the swap (if at all).

Is there something simple I am missing that I can do in a GRC script to
test the difference between a modified and unmodified dongle to compare
the benefits of the TCXO?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Testing crystal accuracy

[Jason Matusiak]

Thanks Marcus, that helps a lot.  

Since I have to multiply the resulting offsets against each other, that
means I will need to run a splitter from my sig-gen to the two dongles. 
Is there any concern that non-linearities in the two legs of the
splitter would effect the results?

Also, what should I do about the transition width on the LPF?

Thanks for the thorough math explanation, that was a good lesson in what
is going on.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Testing crystal accuracy

[Jason Matusiak]

Thanks for the quick response Marcus

Since my Latex isn't very good (as in pretty much non-existent). Let me
see if I can rewrite what you recommended in my dumbed down language and
see if I am close.:

*I have two dongles, dongle 1 will be my modified dongle, dongle 2 will
be my un-modified dongle.

*Put a a known reference tone into each of the dongles where Ftune =
Fref - Foffset
** Foffset should be roughly a third of the sample rate
**An example at a sample rate of 1.024Msps would be a reference tone at
98MHz, and then tune the dongles to 97.659MHz

*I'll now see a baseband signal for both dongles whose offsets won't be
exactly the same.

*Multiple the resulting signals found above against each other (offset,1
* offset,2)
*Pass that through a LPF with a cutoff of Fsample/4, or 256khZ in this
case
**This will give the difference between the frequencies at frequency at
Foffset,1 +/- Foffset,2

*perform a QT freq sync or a quad demod into a QT time sink to compare.

Is that close?  I think I am missing something in there, and I have a
feeling that it has to do with the multiplication step as that makes the
least amount of sense to me.  Any way to enlighten me on what I am
missing above?  Thanks!

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] problem with custom RFNoC block output in GRC

[Jason Matusiak]

I am having some issues with a custom RFNoC block output when trying to
run my python script.  My block takes in a complex int 16, and outputs a
complex int 16 as well as a "byte".  The byte is really a 32b value that
the receiving end will use to convert to a float.  This is a follow on
from a previous GRC conversation I had here [1].

Right now I am testing my pass-through of the complex data (to get my
axi flags working right), so I don't even care about the byte data, but
it is what is giving me issues...

So based on the previous thread, I have an RFNoC GRC block that has an
output of a "byte", but I am attempting to put 32b through it.  I've
tried passing that through a RFNoC: FIFO to a File Sink, as well as just
going from the block to a Null Sink, neither are working.  When I got
straight to a Null Sink, I get the following:
Traceback (most recent call last):
  File "time_sync.py", line 160, in 
main()
  File "time_sync.py", line 148, in main
tb = top_block_cls()
  File "time_sync.py", line 117, in __init__
self.connect((self.uhd_rfnoc_streamer_time_sync_0, 1),
(self.blocks_null_sink_0, 0))
  File
"/home/jason/target/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 47, in wrapped
func(self, src, src_port, dst, dst_port)
  File
"/home/jason/target/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 110, in connect
self.primitive_connect(*args)
  File
"/home/jason/target/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
line 4569, in primitive_connect
return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
ValueError: itemsize mismatch: uhd_rfnoc_TimeSync0:1 using 8,
null_sink0:0 using 1
Segmentation fault (core dumped)


OK, makes sense, it says that I have 8B coming out of the TimeSync0:1,
but the null is expecting 1.  So I go into the python script and change
the following line:
self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_char*1)
to:
self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_char*8)

and now I get the output:
Traceback (most recent call last):
  File "time_sync.py", line 160, in 
main()
  File "time_sync.py", line 149, in main
tb.start()
  File
"/home/jason/target/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
line 109, in start
top_block_start_unlocked(self._impl, max_noutput_items)
  File
"/home/jason/target/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
line 4876, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
RuntimeError: uhd_rfnoc_TimeSync(1): missing connection from output port
0


This doesn't make sense to me as the following is in my pythonscript:
self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_char*8)
self.blocks_file_source_0_0 =
blocks.file_source(gr.sizeof_gr_complex*1,
"/home/jason/reducedInput.txt", False)
self.blocks_file_sink_0 =
blocks.file_sink(gr.sizeof_gr_complex*1, "/tmp/complexData.txt", False)
self.blocks_file_sink_0.set_unbuffered(False)

##
# Connections
##
self.connect((self.blocks_file_source_0_0, 0),
(self.uhd_rfnoc_streamer_fifo_0, 0))
self.connect((self.uhd_rfnoc_streamer_fifo_1, 0),
(self.blocks_file_sink_0, 0))
self.connect((self.uhd_rfnoc_streamer_time_sync_0, 1),
(self.blocks_null_sink_0, 0))
   
self.device3.connect(self.uhd_rfnoc_streamer_fifo_0.get_block_id(), 0,
self.uhd_rfnoc_streamer_time_sync_0.get_block_id(), 0)
   
self.device3.connect(self.uhd_rfnoc_streamer_time_sync_0.get_block_id(),
0, self.uhd_rfnoc_streamer_fifo_1.get_block_id(), 0)  


What am I missing here?  I assume I am doing something stupid somewhere
or am following Martin's plan for me in [1] incorrectly

[1]
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-12/msg00098.html

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] U32 type for module output

[Jason Matusiak]

(I originally responded to the wrong mailing list)

> No, there's not. If there's demand, we can add that of course. Do you
> actually need to *stream* u32 types? Will u8 work for you? You can
> re-cast it to whatever in your application.

Martin, I doubt that there is a high demand, I just sort of assumed
since the standard transport was for complex values (a pair of 16b ints)
that a 32b int was probably a baked in option. 

I am sure I can make 8b work, I'll just have to work through how best to
shift it. Are there any gotchyas I need to be aware of (like handling
the smaller size within the CHDR frames differently), etc?

Thanks!

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] U32 type for module output

[Jason Matusiak]

The idea of the u8 data type is that it does a raw dump of the data. So
if you receive it, then cast the buffer as uint32_t *, you'll get your data.

OK, I thought I was on the same page until this statement.

So I make my output in my verilog code will be 32b, and I can set things up
like normal in the CHDR code.  Then my XML files will have "byte" (I saw that
used somewhere, but I see you called it u8, so I will dothat) as the type so
that it will do a raw dump.  Then on my receiver side, I set it up to receive a
byte, but I typecast it as uint32_t * to get all 32b back out?

Am I understanding that right?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] U32 type for module output

[Jason Matusiak]

What is the equivalent for a u32 output for an RFNoC GRC module?  I
tried u32, but I get an error for that.  If I choose int, it will be 16b
since it is on the FPGA side of things, right?  Is there another option
for passing a 32b unsigned value through (I couldn't find a UHD:RFNoC
example that did something similar)?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Jason Matusiak]

> Arg, I forgot you are using rfnoc :) Sorry.
> The latest e310 files with rfnoc are here:
> http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/
> You could also update the release-3 image to have rfnoc also.

So here is where things ended up.  The default E310 load from OCT (in
the link above) doesn't seem to work with the "RFNOC: Radio" block in
the most recent GR.  In particular the set_rx_dc_offset attribute seems
to be missing from the load on the E310.

What I ended up doing was to update the E310 with an updated
cross-compiled build via pybombs.  The following are the steps I took in
case it helps someone:
*mkdir ~/E310
*sshfs -o allow_root root@192.168.1.111:/ ~/E310

Now I have a folder that is linked to the E310.  Next I update UHD with:
*.
/usr/local/oecore-x86_64/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
* cd ~/pybombs/src/uhd/host/
*mkdir build-arm && cd build-arm
*cmake
-DCMAKE_TOOLCHAIN_FILE=/home/jason/pybombs/src/uhd/host/cmake/Toolchains/oe-sdk_cross.cmake
-DENABLE_E300=ON -DCMAKE_INSTALL_PREFIX=/usr ..
*make -j4
*sudo make install DESTDIR=~/E310

Then to update gr-ettus I:
*cd ~/pybombs/src/gr-ettus/
*mkdir build-arm && cd build-arm
*cmake
-DCMAKE_TOOLCHAIN_FILE=/home/jason/pybombs/src/uhd/host/cmake/Toolchains/oe-sdk_cross.cmake
-DCMAKE_INSTALL_PREFIX=/usr ..
*make -j4
*make install DESTDIR=~/E310

I then rebooted the E310 and my python script with the set_rx_dc_offset
doesn't seem to cause an issue anymore.  If there are some simpler steps
to my convoluted update setup, please let me know.

~Jason

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Jason Matusiak]

> Arg, I forgot you are using rfnoc :) Sorry.
> The latest e310 files with rfnoc are here:
> http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/
> You could also update the release-3 image to have rfnoc also.

Philip, no worries, RFNoC always seems to add extra wrinkles.  So that
is the original link of files I was working off of and having issues.  I
am not sure if something has changed in the process from when I
originally got this working, or if the fact that I am using pybombs
added an extra layer (or two) that I am not compensating for, but i DID
have this working fine a few months back

Here are the steps I am taking as of today (let's ignoring
cross-compiling and just load the latest image onto an SD card):
*First off, pybombs is setup in ~pybombs
*from ~/Downloads, I run: git clone
git://git.infradead.org/users/dedekind/bmap-tools.git
*cd bmap-tools && sudo python setup.py install
*cd ~/Downloads &&  wget
http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/sdimage-gnuradio-dev.direct.xz
*plug an 8GB microSD card into my Ubuntu 14.04 box, it has two
partitions, so I: umount /media/jason/boot && umount
/media/jason/51ecbd25-d149-4a47-bb2e-69e9203595f2
*Since my SD card mounts to sdb, I run: sudo bmaptool copy
sdimage-gnuradio-dev.direct.xz /dev/sdb --nobmap
*10 minutes later it is done.  I pop it into my e310 and let it boot up.
*on the E310 I run: /usr/lib/uhd/utils/uhd_images_downloader.py
*Then, I SCP a python file over for a very simple RFNOC block I just
created and run: python RFNOCtest2.py

The following is the output I get:
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-0-unknown

-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
-- Detecting internal GPSDO  found
-- Initializing core control...
-- Performing register loopback test... pass
-- Setting up dest map for ep 0 to be stream 1
-- Performing register loopback test... pass
-- [RFNOC] --- Radio Setup ---
-- [RFNoC Factory] block_ctrl_base::make() 
-- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/share/uhd/rfnoc"
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/nullblock.xml
-- Found valid blockdef
-- NOC ID: 0x  Block ID: 0/Radio_0
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type =
'' pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type
= '' pkt_size = '0' vlen = '0'
-- radio_ctrl::radio_ctrl() _rx_spp==364
-- setting xbar/Radio_0/ports/out/0
-- [0/Radio_0] radio_ctrl::_update_spp(): Requested spp: 364
-- [0/Radio_0] radio_ctrl::_update_spp(): Setting spp to: 364
-- [0/Radio_0] radio_ctrl::_update_rx_args()
--   Setting VITA core
--   Setting DSP core 
--   Updating muxes 
-- [0/Radio_0] radio_ctrl::update_muxes() 
-- [0/Radio_0] radio_ctrl::_update_tx_args()
--   Setting VITA core
--   Setting DSP core 
--   Updating muxes 
-- [0/Radio_0] radio_ctrl::update_muxes() 
-- [0/Radio_0] radio_ctrl::update_muxes() 
--   dboards/A/tx_frontends/A/connection == IQ
-- [0/Radio_0] radio_ctrl::update_muxes() 
--   dboards/A/rx_frontends/A/connection == IQ
-- Setting up dest map for ep 1 to be stream 4
-- Performing register loopback test... pass
-- [RFNOC] --- Radio Setup ---
-- [RFNoC Factory] block_ctrl_base::make() 
-- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/share/uhd/rfnoc"
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/nullblock.xml
-- Found valid blockdef
-- NOC ID: 0x  Block ID: 0/Radio_1
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/0: type =
'' pkt_size = '0' vlen = '0'
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/0: type
= '' pkt_size = '0' vlen = '0'
-- radio_ctrl::radio_ctrl() _rx_spp==364
-- setting xbar/Radio_1/ports/out/0
-- [0/Radio_1] radio_ctrl::_update_spp(): Requested spp: 364
-- [0/Radio_1] radio_ctrl::_update_spp(): Setting spp to: 364
-- [0/Radio_1] radio_ctrl::_update_rx_args()
--   Setting VITA core
--   Setting DSP core 
--   Updating muxes 
-- [0/Radio_1] radio_ctrl::update_muxes() 
-- [0/Radio_1] radio_ctrl::_update_tx_args()
--   Setting VITA core
--   Setting DSP core 
--   Updating muxes 
-- [0/Radio_1] radio_ctrl::update_muxes() 
-- [0/Radio_1] radio_ctrl::update_muxes() 
--   dboards/A/tx_frontends/B/connection == IQ
-- [0/Radio_1] radio_ctrl::update_muxes() 
--   dboards/A/rx_frontends/B/connection == IQ
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Setting time source to internal
-- Asking for clock rate 16 MHz
-- Actually got clock rate 16 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- [RFNOC] --- Block Setup ---
-- Setting up dest map for ep 2 to be stream 7
-- Setting up NoC-Shell Control #0 (SID: 00:02>02:30)...OK
-- Port 48: Found NoC-Block with ID F1F0.
-- 

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Jason Matusiak]

Thank you Philip.  I blew away my old toolchain, re-grabbed the latest
and installed it.  I can then run the cmake, make, and make install to
load up the SD card on the E310 without error.

Sadly, it doesn't appear to be 100% right because if I run a python
script I created in GRC on my PC, I get:
root@ettus-e300:~# python RFNOCtest2.py Traceback (most recent call
last):
  File "RFNOCtest2.py", line 12, in 
from gnuradio import uhd
  File "/usr/lib/python2.7/site-packages/gnuradio/uhd/__init__.py", line
135, in 
_prepare_uhd_swig()
  File "/usr/lib/python2.7/site-packages/gnuradio/uhd/__init__.py", line
38, in _prepare_uhd_swig
import uhd_swig
  File "/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", line
28, in 
_uhd_swig = swig_import_helper()
  File "/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", line
24, in swig_import_helper
_mod = imp.load_module('_uhd_swig', fp, pathname, description)
ImportError: libuhd.so.003: wrong ELF class: ELFCLASS64

Which looks like something is not cross compiling properly.  Am I
missing something in pybombs to get libuhd to build properly when doing
my crosscompile in uhd/host/build-arm?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Jason Matusiak]

> Assuming you are using Release-3 on the E310, make sure the sdk and file
> system image come from the same directory. The error looks like this is
> not the case.
Are you saying Release-3 for the cross-compiler (I was assuming so)? And
for the directory do you mean on the ettus file page?

>There is a file on the image /etc/version that has a timestamp in it.
>This should be close to the one in the sdk.
I'll double check it. Thanks.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Jason Matusiak]

> Note the directory contains the file system and sdk.

> http://files.ettus.com/e3xx_images/e3xx-release-3/

Philip, That wasn't the directory I was using on the site, so thank you.
 It seems like gr-ettus is not in the build by default, is that by
design?  At this point I assume that I need to cross-compile and install
it onto there?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] pybombs cross-compile mako error

[Jason Matusiak]

I am having an issue with a cross compile (which I haven't done in a
while) for my E310 and failing on Mako w/n pybombs.


if I go to: ~/pybombs/src/uhd/host/build-arm
and run: .
/usr/local/oecore-x86_64/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
followed by: cmake
-DCMAKE_TOOLCHAIN_FILE=/home/jason/pybombs/src/uhd/host/cmake/Toolchains/oe-sdk_cross.cmake
-DENABLE_E300=ON -DCMAKE_INSTALL_PREFIX=/usr ..

I get:
-- The CXX compiler identification is GNU 4.9.1
-- The C compiler identification is GNU 4.9.1
-- Check for working CXX compiler:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++
-- Check for working CXX compiler:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc
-- Check for working C compiler:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc
-- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- 
-- Configuring the python interpreter...
-- Found PythonInterp:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/python
(found version "2.7.3") 
-- Python interpreter:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/python
-- Override with: -DPYTHON_EXECUTABLE=
-- Using UHD Images Directory: OFF
-- Build type not specified: defaulting to release.
-- Performing Test HAVE_VISIBILITY_HIDDEN
-- Performing Test HAVE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_VISIBILITY_INLINES_HIDDEN
-- Performing Test HAVE_VISIBILITY_INLINES_HIDDEN - Success
-- 
-- Configuring Boost C++ Libraries...
-- Boost version: 1.56.0
-- Found the following Boost libraries:
--   date_time
--   filesystem
--   program_options
--   regex
--   system
--   thread
--   unit_test_framework
--   serialization
-- Boost include directories:
/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include
-- Boost library directories:
/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib
-- Boost libraries:
/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libboost_date_time-mt.so;/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libboost_filesystem-mt.so;/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libboost_program_options-mt.so;/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libboost_regex-mt.so;/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libboost_system-mt.so;/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libboost_thread-mt.so;/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libboost_unit_test_framework.so;/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libboost_serialization-mt.so
-- Looking for log2
-- Looking for log2 - found
-- 
-- Python checking for Python version 2.6 or greater
-- Python checking for Python version 2.6 or greater - found
-- 
-- Python checking for Mako templates 0.4 or greater
-- Python checking for Mako templates 0.4 or greater - "import mako"
failed
-- 
-- Configuring LibUHD support...
--   Dependency Boost_FOUND = 1
--   Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
--   Dependency HAVE_PYTHON_MODULE_MAKO = FALSE
CMake Error at cmake/Modules/UHDComponent.cmake:51 (MESSAGE):
  Dependencies for required component LibUHD not met.
Call Stack (most recent call first):
  CMakeLists.txt:279 (LIBUHD_REGISTER_COMPONENT)


-- Configuring incomplete, errors occurred!
See also
"/home/jason/pybombs/src/uhd/host/build-arm/CMakeFiles/CMakeOutput.log"


Mako is installed, so is this some sort of path issue within pybombs in
my setup?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Jason Matusiak]

> The release-3 (and newer) toolchains have mako. Anything older doesn't.
> That's the first thing to check.

Thank you Philip.  What is the best way to do that?  I tried looking at
the version-armv7ahf-vfp-neon-oe-linux-gnueabi only shows:
Distro: nodistro
Distro Version: nodistro.0
Metadata Revision: 93d79fc162bd49387958e9e4d898dc4ba50d20b0
Timestamp: 20150110021354


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] updating all of pybombs

[Jason Matusiak]

> did "./pybombs update" not work?

I get this:
Configuring: (100%)
[==]
Configuration failed. Re-trying with higher verbosity.
make: *** No targets specified and no makefile found.  Stop.
Build failed. See output above for error messages.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] updating all of pybombs

[Jason Matusiak]

I am using pybombs, but am still not 100% confident in my usage of it. 
I know that there has been some gnuradio updates recently, so I thought
it might be a good time to update whatever needs to be updated on my
system.  Are there steps written up somewhere for how to do a wholesale
update via pybombs; or at least the proper order if things need to be
done one at a time?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] updating all of pybombs

[Jason Matusiak]

> did "./pybombs update" not work?

In fact, now I just noticed that pybombs/src/uhd is missing now.  Why
would that get deleted by doing an update?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Rational resampler misunderstanding

[Jason Matusiak]

I think I am overthinking something with the rational resampler.  I am
working on an RFNoC block to incorporate a working gnuradio script we
have, and am somehow being silly about the rational resampler.

I am decimating by 4 (and not interpolating at all), to reduce the
sample rate by 4.  Under the hood, is GNURadio basically creating a FIR
decimator?  Is it that simple, or am I missing some other pieces?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] complex type clarification

[Jason Matusiak]

I just wanted to make sure I have this right (because I always seem to
confuse myself); the complex data type is 64bits, 4 bytes of I and 4
bytes of Q, right?

Secondly, those 4B are of type signed floats from [-1,1], right?  I
assume that these are of the IEEE 754 type?

TIA!

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] host format versus device format

[Jason Matusiak]

For some reason I got myself wrapped around the axle with what is going
on with the host and device format options.  For instance, if I look at
the RFNoC Radio block, it has a host format with the options: complex
float32, complex int16, and vita word32, and a device format of complex
int16 (with no other options).

The way I understand things, the host format is basically the wire
connection between blocks.  So complex float32 is I/Q with 4B for each
in float format (so 8B per sample), and complex int16 is 2B on int for
I/Q (4B per sample).  Am I still OK?  If so, I am failing to understand
the device format option...

Although, all that said, as I look at a USRP Source block, it uses the
term "output type" (which is analogous to the host format) and a "wire
format" which I am guessing is the same as the "device format"  If that
is correct, that means I don't have any idea what that wire is doing (as
I would have mentally thought that the output type is the "wire").

I tried looking for some documentation on this but came up empty (though
I am sure it is out there somewhere).

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] pybombs path issue with OOT modules

[Jason Matusiak]

Got a little conundrum here I have pybombs setup and working fine
for my RFNoC development.  I then decided that I wanted to make a new
OOT module, so I did gr_modtool newmod myOOTmodule in ~/pybombs/src.
Made my tweaks to the XML file inside GRC and tried to mkdir build && cd
build && make && sudo make install.

The problem is that it is installing the files to the normal GRC
directory of /usr/local/share

If I got into the gr-ettus/build directory and do a sudo make install in
there, I see that it is getting installed into the correct directory of
/home/jason/target/share.

So what am I missing here?  I am sourcing ~/target/setup_env.sh in my
terminal

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] pybombs path issue with OOT modules

[Jason Matusiak]

> So basically go back to your OOT module, delete your build directory (just to 
> be safe) then start over like this:
> mkdir build && cd build
> cmake -DCMAKE_INSTALL_PREFIX=/home/jason/target ..
> make
> make install

Bingo, you were right on target.  I guess I figured that when sourcing
with the setup_env.sh that it would take care of all of those things. 
Once I added the flag, all was happy again.

Good point also about installing elsewhere.  Going along with my
previous thought, it made sense to me that I Would have to put it with
the other OOT modules so the paths would work out OK.  Now that I don't
have to, it would be better to move it elsewhere to keep things clean.

Thanks!

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problems with setting up RFNoC environment within

[Jason Matusiak]

> PyBOMBS + RFNoC is a bit iffy, you need to manually edit the uhd.lwr
> file to have it build the rfnoc-devel branch. Then, it *should* work,
> but I'll admit I haven't tested it myself.

Martin, to wrap a bow on this, here is the steps I've taken (and redone
to make sure things seem OK) and it seems to make everything happy:

*cd ~ && git clone https://github.com/gnuradio/pybombs.git
*cd pybombs && ./pybombs install gnuradio
**Setup as you would like things, the only stuff I change was setting
forcepkgs to uhd (and in the long list of things in the next option do
it all but uhd), and builddocs to ON
*When done gedit recipes/uhd.lwr
**comment out the first gitbranch and uncomment the second to enable
RFNoC support
*back in ~/pybombs, gedit config.dat and remove uhd from the forcepkg
line
*then ./pybombs install uhd
*cd src/uhd && git submodule init && git submodule update
*cd ~/pybombs && ./pybombs install gr-ettus
*./pybombs env (now you can source ~/target/setup_env.sh before you
start to play with GRC)

Maybe there is a cleaner way to do it, or I am missing something else,
but this seemed to allow me to run both regular GRC scripts as well as
RFNoC scripts on the X310 with no errors.

~Jason

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problems with setting up RFNoC environment within

[Jason Matusiak]

(accidentally sent this to the wrong mailing list the firs time,
sorry)

> I admit this seems a bit heath robinson (or rube goldberg for you
> Americans), but thanks for the feedback and the writeup!

For anyone following this, please feel free to interject if there is a
smoother way to go through these steps.  They work for me, so I stopped
there, but I am not convinced that I have done it the most efficient
way.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio