Re: [Discuss-gnuradio] Trouble getting GNUradio/UHD working (with PyBombs)
OK, I stupidly assumed things would be installed in the 'usual'
places... After changing the makefile and modifying /etc/ld.so.conf
things work good. Thanks!
David Donley schreef op 2015-06-27 22:12:
Pybombs usually installs stuff in ~/target and adds a script there
called ~/target/setup_env.sh which sets up paths. You should try
running that before building gnuradio things after installing pybombs.
If the includes still aren't found try looking in ~/pybombs or
~/target for them. You should not have needed the apt-get lines after
successfully installing pybombs and should probably uninstall those
items.
Sent from my iPhone
On Jun 27, 2015, at 12:45 PM, Jeroen Boschma
wrote:
Hi all,
I picekd up GNU Radio again and tried to get a simple plain C++
project working, but no success. Details below, hopefully somebody
can set my nose in the right direction.
What I want to do
I want to do some C++ coding outside Companion, so I have C++ with
code like:
---
int main()
gr::top_block_sptr tb = gr::make_top_block("USRP_framework");
gr::uhd::usrp_source::sptr usrp_source =
gr::uhd::usrp_source::make(device_addr, uhd::stream_args_t("fc32"));
tb->connect(usrp_source, 0, custom_processor, 0);
---
So I want to use the GNU radio framework, and also have direct control
over the USRP. I use a very simple and dirty makefile, to keep as much
complexity out of this, the goal is just to get it working:
---
CC = g++
LIB= -lglut -lGLU -lGL -lgnuradio-blocks -lgnuradio-fft
-lgnuradio-pmt -lgnuradio-runtime -lgnuradio-uhd -lboost_system
-lboost_thread -luhd
INCDIR = -I matplotpp
ALIB = matplotpp/matplotpp.a
USRP_framework: USRP_framework.cc
$(CC) $(INCDIR) -o USRP_framework USRP_framework.cc $(ALIB) $(LIB)
---
My intiial steps:
1) I made a fresh Ubuntu install
2) installed git
3) got PyBombs
4) installed GNUradio using PyBombs. As far as I can see, it also
installed UHD directly since it moved in PyBombs to 'installed
hardware apps' and cannot be chosen to install anymore.
No problems thusfar.
What went wrong during 'make'
1) The GNU-radio includes were not found, so I installed gnuradio-dev
using 'apt-get'.
2) Then UHD includes were not found, so I filled /usr/include/uhd with
the include files by hand (downloaded them).
3) Then the makefile tells me that 'luhd' was not found
Anybody an idea what my next step should be to get this very simple
framework working? If PyBombs already installed UHD, why is there no
libuhd.so file on the HD? There is a libuhd.so.003 and a
libuhd.so.003.005
One of the reasons I started all over again (I had a GRC installation
previously) is that a previous attempt gave me errors regarding ABI
versions mismatches between GNUradio and UHD. So they should be build
'simultaneously' using exact the same resources I guess...
Best regards,
Jeroen Boschma
___
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] Segmentation fault due to thread unsafety?
Hi all, I suspect I'm having problems with different threads which gives me a segmentation fault. Hopefully someone with knowledge on how this works with GNU radio can give me a hint for a solution. What I did is as follows (C++ implementation code is quite long, so I hope the following sketch of the situation is sufficient): 1) I made a pure C++ test-application, so not using GRC. 2) I derived my own block from the sync-block. 3) In the work()-function of my own block, variables are prepared to be plotted (simple xy-graphs). These variables are members of my block-class. 4) My own block also has a member function to plot the xy variables, say void plot_all(void). 5) In the main loop (so within main()...) there is a loop which waits for CTRL-C, and lets the GNU Radio thread sleep for 10 ms each iteration. In that loop, the plotting routine is called when more than 100 ms elapsed since the last time: my_block->plot_all(). 6) If the plot_all() function now not only reads or only writes a member variable of my own block but both reads and writes, then I get a segmentation fault. 7) I even get a segmentation fault if the plotting variables are made global, so outside my own block. I suspect that a solution is that I drag all plotting into my own block, and that also calling the plot_all() function must be done from within the work() function (say every 100 ms). a) Would that work? (if I would try and test it and it works I may still not know if the solution is foolproof, so I ask therefore) b) Does that give me additional chance for buffer overruns because of required plotting CPU time within work()? c) Do I have to pull GLUT initializations as well to the constructor of my own block, or can I leave them in main()? d) Is there a better solution? Sorry if I ask much, but I've spent many hours on this problem already and an expert may just have a simple solution for me :-) hanks and best regards, Jeroen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Cannot see my custom blocks in GRC
Hi all, After having problems in version 3.6.5 I decided to move to 3.7. So I reinstalled Ubuntu to start with a clean OS without 'loose ends' pointing to old GNU radio versions, then installed UHD and GNU radio via Ettus Research packages. Versions: GNU radio 3.7.2.1 (standard installation to /usr/lib) CMake 2.8.7 Ubuntu 12.04 After installing my custom blocks, they are not available in GRC (in 3.6.5 I had no problems with that). I followed the tutorial for out-of-tree modules. Output of 'make install' (followed by 'sudo ldconfig'): [ 33%] Built target gnuradio-TNO_jamming [ 66%] Built target test-TNO_jamming [100%] Built target pygen_python_2a2c4 [100%] Built target pygen_apps_9a6dd Install the project... -- Install configuration: "Release" -- Installing: /usr/local/lib/cmake/TNO_jamming/TNO_jammingConfig.cmake -- Installing: /usr/local/include/TNO_jamming/api.h -- Installing: /usr/local/include/TNO_jamming/sweeped_LO.h -- Installing: /usr/local/include/TNO_jamming/random_OFDM.h -- Installing: /usr/local/lib/libgnuradio-TNO_jamming.so -- Installing: /usr/local/lib/python2.7/dist-packages/TNO_jamming/__init__.py -- Installing: /usr/local/lib/python2.7/dist-packages/TNO_jamming/__init__.pyc -- Installing: /usr/local/lib/python2.7/dist-packages/TNO_jamming/__init__.pyo -- Installing: /usr/local/share/gnuradio/grc/blocks/TNO_jamming_sweeped_LO.xml -- Installing: /usr/local/share/gnuradio/grc/blocks/TNO_jamming_random_OFDM.xml I set some environment variables to see if this changes things: export PYTHONPATH=/usr/local/lib/python2.7/dist-packages:$PYTHONPATH export export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH But the blocks are still not available in GRC (I expect a new category 'TNO_jamming' in the list with my blocks). Any ideas? Jeroen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cannot see my custom blocks in GRC
Martin Braun schreef op 2014-01-17 16:31: On 01/17/2014 03:20 PM, jer...@boschma.com wrote: Hi all, After having problems in version 3.6.5 I decided to move to 3.7. So I reinstalled Ubuntu to start with a clean OS without 'loose ends' pointing to old GNU radio versions, then installed UHD and GNU radio via Ettus Research packages. Versions: GNU radio 3.7.2.1 (standard installation to /usr/lib) CMake 2.8.7 Ubuntu 12.04 When GRC goes to /usr/lib, it doesn't look in /usr/local/lib for blocks. We know about this and it will be fixed in an upcoming release. In the meantime, the solution is very simple. You can either add another env variable GRC_BLOCKS_PATH=:/usr/local/share/gnuradio/grc/blocks or edit .gnuradio/config.conf to search for blocks in other places. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio For some reason I can't get it to work... I added the env var manually: export GRC_BLOCKS_PATH=/usr/local/share/gnuradio/grc/blocks which did not seem to work (although that folder contains my xml-files of both blocks). Then I did a search for the config.conf file which isn't on my file system, so I created one in ~/.grc_gnuradio (I have no ~/.gnuradio folder...): [grc] local_blocks_path=/usr/local/share/gnuradio/grc/blocks No result... What do I do wrong? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Cannot add an additional parameter to custom block
Hi all, I got my things working, up to the point where I decided that an additional parameter in my custom block would be very helpful. But for some reason, GRC keeps holding on to my previous version of the block with 3 parameters instead of my new one with 4 parameters. In the end, after numerous fails, I did the following: * I deleted the existing block from my module using "gr_modtool rm MY_BLOCK" * I deleted the build folder * I added MY_BLOCK again using gr_modtool and filled in some additional C++ code * I changed the XML file to reflect the additional parameter * I deleted various files from /user/..., such that 'sudo make install' did not report files already up-to-date: everything was newly installed In GRC the custom block shows the additional parameter (a bool, with options 'On' or 'Off'), but when trying to run GRC it reports: "TypeError: Required argument 'XXX' (pos 4) not found". It boils down to top_block.py, where I see a call to my block with only 3 parameters while in all files I can see, 4 parameters are defined. If I delete this file, it is of course regenerated with the same error. Somewhere a file resides which still has the previous definition of the block with only 3 parameters instead of the new one with 4 parameters and GRC relies on that. Any ideas how to solve this are very welcome :-) Jeroen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cannot add an additional parameter to custom block
Koslowski, Sebastian (CEL) schreef op 2014-01-21 15:16: Hi Jeroen, On 01/21/2014 01:57 PM, jer...@boschma.com wrote: * I changed the XML file to reflect the additional parameter ... It boils down to top_block.py, where I see a call to my block with only 3 parameters while in all files I can see, 4 parameters are defined. Sounds like you haven't updated the template in "..." (in your blocks' XML description). If that doesn't help, could you maybe post the XML? Sebastian How could I be so stupid to overlook that line, spent nearly 3 hours on this... In my first attempt I apparently only added the additional , and in further attempts (newly generated block) I also copied the erroneous line into the new xml-file. :-| Anyway, you saved my day, it works again. Thanks! ___ 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 using FFT-class in my own written block
Jeroen, That tutorial you mentioned doesn't give you the whole picture about configuring your OOT module with different needs like yours. Also read through this one: http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig And note the subtle change between 3.7.2 versus later (currently only on git) versions. You're going to have to go in and edit your CMakeLists.txt files in both the root directory of your OOT module and the lib directory. Right now, what's likely happening is that you aren't linking against the libraries you need. This tutorial will explain how to find and link against libgnuradio-fft.so. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thanks for the document Tom. I only just found time to proceed with it, but still getting errors. I think the reason is that I'm using 3.6.5 which has different needs to link the FFT lib. I followed your document, found that 3.6 uses GNU_CORE instead of GNU_RUNTIME, but still got errors. For example 'cmake ../' complains not being able to find files: GnuradioConfig.cmake gnuradio-config.cmake but those files are not even present on the USB stick environment where GNU radio is installed. I literally spent hours with Google to find a solution how to do this in 3.6, can you help me further please? Porting my blocks to 3.7 is only something for a later stage: right now I'm trying to find a fix in 3.6 and hope to get the blocks working first Regards, Jeroen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem using FFT-class in my own written block
jer...@boschma.com schreef op 2013-12-05 11:40: Jeroen, That tutorial you mentioned doesn't give you the whole picture about configuring your OOT module with different needs like yours. Also read through this one: http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig And note the subtle change between 3.7.2 versus later (currently only on git) versions. You're going to have to go in and edit your CMakeLists.txt files in both the root directory of your OOT module and the lib directory. Right now, what's likely happening is that you aren't linking against the libraries you need. This tutorial will explain how to find and link against libgnuradio-fft.so. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thanks for the document Tom. I only just found time to proceed with it, but still getting errors. I think the reason is that I'm using 3.6.5 which has different needs to link the FFT lib. I followed your document, found that 3.6 uses GNU_CORE instead of GNU_RUNTIME, but still got errors. For example 'cmake ../' complains not being able to find files: GnuradioConfig.cmake gnuradio-config.cmake but those files are not even present on the USB stick environment where GNU radio is installed. I literally spent hours with Google to find a solution how to do this in 3.6, can you help me further please? Porting my blocks to 3.7 is only something for a later stage: right now I'm trying to find a fix in 3.6 and hope to get the blocks working first Regards, Jeroen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Sorry for this, I may have done something stupid such that this message ended up in the wrong thread... If somebody knows a way how to delete the message and keep the original thread clean, OK for me... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem using FFT-class in my own written block (part II)
Marcus Müller schreef op 2013-12-06 08:02:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jeroen,
it's not advisable to use the 3.7 Out of tree-module directory
architecture with GR 3.6.
However, gr_modtool should be generating modules that fit exactly your
installed version. You shouldn't have to change anything on the
gnuradio core/runtime/gruel/whatever includes.
After you have set up your new module with gr_modtool, just copy over
the original GNU Radio FindFFTWf.cmake into the cmake/Modules
directory,
and use FindPackage(FFTWf) as well as add the found directories to
your target link libraries and the found includes to your include
directories; see my reply to Johannes Demel's post of yesterday.
Greetings, and happy hacking!
Marcus
On 05.12.2013 21:30, Jeroen Boschma wrote:
Hello all,
In order to keep discussions separated (I apparently did something
stupid which mixed up 2 threads), I start a new thread here.
Summarizing: when writing my own out of tree block in C++ using
FFTs (including the 'fft/fft.h' header) and following the tutorial
"Out-of-tree modules", I get an error when I want to use the block
in GNU Radio Companion:
ImportError /usr/local/libgnuradio-MY_MODULE.so: undefined symbol:
fft_complex
According to Tom Rondeau the FFT-library is not included in the
link process, and he suggested the following tutorial:
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig
I started following that tutorial, setting some environment
variables first, and I found out that I am using version 3.6.5git
(on an Ettus Research USB stick) while I suspect that the suggested
tutorial only covers versions >= 3.7.
Even when I only changed the following (as suggested by the
tutorial):
find_package(GnuradioCore)
into:
set(GR_REQUIRED_COMPONENTS CORE) find_package(Gnuradio "3.6.5"
REQUIRED)
I get the following error when I run "cmake ../" from the
build-directory:
= -- Build type not
specified: defaulting to release. -- Boost version: 1.49.0 -- Found
the following Boost libraries: -- filesystem -- system CMake
Error at CMakeLists.txt:92 (find_package): By not providing
"FindGnuradio.cmake" in CMAKE_MODULE_PATH this project has asked
CMake to find a package configuration file provided by "Gnuradio",
but CMake did not find one.
Could not find a package configuration file provided by "Gnuradio"
(requested version 3.6.5) with any of the following names:
GnuradioConfig.cmake gnuradio-config.cmake
Add the installation prefix of "Gnuradio" to CMAKE_PREFIX_PATH or
set "Gnuradio_DIR" to a directory containing one of the above
files. If "Gnuradio" provides a separate development package or
SDK, be sure it has been installed.
=
So I tried (as suggested by the error message):
1) set CMAKE_MODULE_PATH to the path where
"FindGnuradio.cmake"resides 2) add the installation prefix of
"Gnuradio" to CMAKE_PREFIX_PATH
The two mentioned config .cmake files are not even present on the
environment I am working on (not found by a search at the GNU
radio installation prefix which is usr/local).
So I am pretty stuck here. My goal is to get this working in my
current environment before trying to port my blocks to the latest
version > 3.7. Any help is greatly appreciated.
Best regards,
Jeroen Boschma
___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSoXahAAoJEAFxB7BbsDrLi2QH/AmKmrZNZYn7BIz7snz/eu0G
X4e2u++r7UJ8M3ty4PB33txGDT83LNlvVLXhHWjnl6BPKClaEezmU6iYLsCSOyKA
otFUvzUw5lc7Q4KgM1aS6KVCCCPczbKWIHGm2d4+4octnabIx1NfuKgeSwwSUdX/
BFXw3q/mjRQpHGXKD+lkcJgCUYLXerLNQd9YCYsY9XxQJL855rBIQd7QEUBi3GXB
c+Foq1/+wVWWbOx+Za1XGkBgmjIIzmQSqwsNLatIhEEbZTseVRH8eJ8UUq4IJSRX
sAVaI3k4j6SvvtNC+EMSee8/kdxj08OlmrNLYrWaU9y9wA/pG0R9PXWwGf3n7Sw=
=CYIj
-END PGP SIGNATURE-
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Thanks for your reply Marcus. It did help me a bit, but results are not
yet there... So what I did:
1) I Copied the FindFFTW3f.cmake into the cmake/Modules dir of my
module.
2) In the top-level CMakeLists.txt I modified/added (just guessing what
to do...):
find_package(FFTW3f)# added this
include_directories(
${CMAKE_SOURCE_DIR}/include
${Boost_INCLUDE_DIRS}
${GRUEL_INCLUDE_DIRS}
${CPPUNIT_INCLUDE_DIRS}
${GNURADIO_CORE_INCLUDE_DIRS}
${FFTW3F_INCLUDE_DIRS} # added this, I checked that it
actually points to an inclu
Re: [Discuss-gnuradio] Problem using FFT-class in my own written block (part II)
Marcus Müller schreef op 2013-12-06 13:38: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hej Jeroen, 2) In the top-level CMakeLists.txt I modified/added (just guessing what to do...): I wouldn't call your method "guessing"; you used strong indications! :D Ok, now I see what your problem is: It's not that you don't link against FFTW (the library that does the actual FFT calculations), but that you don't link against gr-fft, the GNU Radio fft helpers and wrappers and widgets! Now everything makes sense. The point is: with 3.7 it's easy to use certain GNU Radio components, just by adding[1]: set(GR_REQUIRED_COMPONENTS RUNTIME FILTER) to the master CMakeLists.txt. For 3.6, I can't verify that right now, but doing find_package(gnuradio-fft) instead should do the trick (I hope the spelling is right, though. Look into /usr/local/lib/pkgconfig/gnuradio* ). The resulting variables should then be something like[2]: GNURADIO_FFT_INCLUDE_DIRS (or LIBRARY_DIRS, respectively). You might need to google the correct naming, though. Jay! Happy hacking 1: http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig#Configuring-Our-Project-to-Use-GNU-Radio-Libraries 2: http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSocVCAAoJEAFxB7BbsDrLYeMH/iyINXohTKFSxNaZL5df6qdE tpUni2POUwzfM32vcmdVovj6IQcKppEWz3Xugd8KAxtkSQYJd9+f7EZydIvnsG+R /ToQ8ARBTDUsFZpe0HaKUGKTiY6Q8pI3SneOAug7/RMZffK8UcV/ObFyCn0ZEI7+ 2phikCxt4XaQr+KqvA/242BPR3jPPiDil3Ok1ocsQpn/CuLf+NHTnSFQaSFGTPPQ I/rw9c5GIy7Hn4s7I+KCjxdkJcZ/PXVJcfOveec3BzV03NTXjpV8tgr4cTj5aars 9o48MrnbGjdZO5irRmaUi7mDj7sAKGC3wWPmgCk9Iapo2lI+BIBZ16d7hCkVexs= =bQt9 -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Sorry, does not work. There is a gnuradio-fft.pc so I tried: find_package(gnuradio-fft) But it immediatly starts whining about not finding "gnuradio-fftConfig.cmake" or "gnuradio-fft-config.cmake". Well, neither of those two files exists in the GNU installation... This is kind of frustrating, already spending like three full days on just trying to link an FFT library and searching the internet for doing that. It's absurd... Jeroen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Trouble getting GNUradio/UHD working (with PyBombs)
Hi all,
I picekd up GNU Radio again and tried to get a simple plain C++ project
working, but no success. Details below, hopefully somebody can set
my nose in the right direction.
What I want to do
I want to do some C++ coding outside Companion, so I have C++ with code
like:
---
int main()
gr::top_block_sptr tb = gr::make_top_block("USRP_framework");
gr::uhd::usrp_source::sptr usrp_source =
gr::uhd::usrp_source::make(device_addr, uhd::stream_args_t("fc32"));
tb->connect(usrp_source, 0, custom_processor, 0);
---
So I want to use the GNU radio framework, and also have direct control
over the USRP. I use a very simple and dirty makefile, to keep as much
complexity out of this, the goal is just to get it working:
---
CC = g++
LIB= -lglut -lGLU -lGL -lgnuradio-blocks -lgnuradio-fft
-lgnuradio-pmt -lgnuradio-runtime -lgnuradio-uhd -lboost_system
-lboost_thread -luhd
INCDIR = -I matplotpp
ALIB = matplotpp/matplotpp.a
USRP_framework: USRP_framework.cc
$(CC) $(INCDIR) -o USRP_framework USRP_framework.cc $(ALIB) $(LIB)
---
My intiial steps:
1) I made a fresh Ubuntu install
2) installed git
3) got PyBombs
4) installed GNUradio using PyBombs. As far as I can see, it also
installed UHD directly since it moved in PyBombs to 'installed hardware
apps' and cannot be chosen to install anymore.
No problems thusfar.
What went wrong during 'make'
1) The GNU-radio includes were not found, so I installed gnuradio-dev
using 'apt-get'.
2) Then UHD includes were not found, so I filled /usr/include/uhd with
the include files by hand (downloaded them).
3) Then the makefile tells me that 'luhd' was not found
Anybody an idea what my next step should be to get this very simple
framework working? If PyBombs already installed UHD, why is there no
libuhd.so file on the HD? There is a libuhd.so.003 and a
libuhd.so.003.005
One of the reasons I started all over again (I had a GRC installation
previously) is that a previous attempt gave me errors regarding ABI
versions mismatches between GNUradio and UHD. So they should be build
'simultaneously' using exact the same resources I guess...
Best regards,
Jeroen Boschma
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Segmentation fault due to thread unsafety?
Hi Marcus,
Thanks for your extensive reply. From your reply I am not sure if you
understood that I am not doning anything graphical in work(). In very
raw pigeon code this is what I have:
class my_block_class : sync_block {
public:
vector plot_x_data, plot_y_data;
work()
{
// samples processing.
// Sometimes prepare plot_x_data and plot_y_dataand set a flag.
}
plot_data(*some_plot_class)
{
some_plot_class->plot(this->plot_x_data, this->plot_y_data);
}
};
display_handler()
{
my_block->plot_data(&plot_class)
}
main()
{
// Many inits.
// Start GNU Radio processing.
while (true) {
sleep(100m);
handle_GLUT_events; // This indirectly calls the
display_handler and thus calls the plotting routine of my block...
}
}
Since my post and your reply I tried several things in changing the
code, what supprised me was the following:
* Sometimes I got an error about memory corruption or a double free,
that's looks like a more fundamental problem than simply different
threads access.
* I locked the few member function's that access the plotting data with
boost::lock_guard to prevent multiple threads accessing the data
simultaneously, but the segmentation fault remains. Again an indication
that it is not a thread problem but another memory issue.
* If access to the plotting data remains, but plotting itself is
ommitted, then the segmentation fault dissapears!
* If I only read the plotting data during plotting and do no writing at
all to this data, then there is no segmentation fault (and plotting
works..).
* If I also write to the plotting data in my plot function (I 'need' to
set a flag that the data was plotted so replotting is only done in case
of new data in order to save CPU time), then the segmentation fault
comes back again.
I'll see if I can find out what the underlying problem is, then I'll
post again.
Best regards and thanks for your support,
Jeroen
On 4-7-2015 9:29, Marcus Müller wrote:
Hi Jeroen,
I suspect that a solution is that I drag all plotting into my own
block, and that also calling the plot_all() function must be done from
within the work() function (say every 100 ms).
I'd say quite the opposite is true!
So the point is that GUIs need to have their own loops to update the
display, so the GUI routines inherently run in a different thread than
your block. What you're doing by plotting in your work() is that you
change the state (e.g. the buffer that is displayed on screen) that the
GUI thread works on.
Since changing that state is, like you've guessed, usually not
thread-safe, you get bad effects.
Typically, you let your GUI toolkit define callbacks or functions that a
programmer must overload to fill a specific framebuffer with image data,
*when the toolkit calls it*.
The trick is hence to not do anything graphical in your work(). Instead,
over some thread safe mechanism (e.g. Queue with a mutex, or if you're
using Qt, Signals) copy the data over to your GUI logic. In that logic,
take the data and plot it -- but that has to be done from within the GUI
toolkit!
E.g. some GUI toolkits let you override a "paint" method to draw
something on the screen. Do that, based on the data you get from a Queue.
That paint method will automatically be called by the GUI when e.g. the
window size changed. But you want to update every N samples, so after
passing the data to the Queue, the work() calls an "invalidate" function
from the toolkit -- these are typically thread-safe, and trigger
updating of the screen, and in turn call the "paint" method.
I'd point you to gr-qtgui, but I think it's fair to mention that you
should first read up a bit on Qt signals and slots -- its source code
can be hard to understand, otherwise.
Best regards,
Marcus
On 07/04/2015 08:45 AM, jer...@boschma.com wrote:
Hi all,
I suspect I'm having problems with different threads which gives me a
segmentation fault. Hopefully someone with knowledge on how this works
with GNU radio can give me a hint for a solution.
What I did is as follows (C++ implementation code is quite long, so I
hope the following sketch of the situation is sufficient):
1) I made a pure C++ test-application, so not using GRC.
2) I derived my own block from the sync-block.
3) In the work()-function of my own block, variables are prepared to
be plotted (simple xy-graphs). These variables are members of my
block-class.
4) My own block also has a member function to plot the xy variables,
say void plot_all(void).
5) In the main loop (so within main()...) there is a loop which waits
for CTRL-C, and lets the GNU Radio thread sleep for 10 ms each
iteration. In that loop, the plotting routine is called when more than
100 ms elapsed since the last time: my_block->plot_all().
6) If the plot_all() function now not only reads or only
Re: [Discuss-gnuradio] Cannot see my custom blocks in GRC
On 18-1-2014 16:45, Martin Braun wrote: On 01/17/2014 05:05 PM, jer...@boschma.com wrote: For some reason I can't get it to work... I added the env var manually: export GRC_BLOCKS_PATH=/usr/local/share/gnuradio/grc/blocks which did not seem to work (although that folder contains my xml-files of both blocks). Then I did a search for the config.conf file which isn't on my file system, so I created one in ~/.grc_gnuradio (I have no ~/.gnuradio folder...): [grc] local_blocks_path=/usr/local/share/gnuradio/grc/blocks No result... What do I do wrong? Assuming you've double-checked the paths, there's always the possibility that your XMLs are borked. If you run gnuradio-companion in the command line, do you see any errors or warnings corresponding to your block? If you're sure you're blocks work, test if it's really a pathing problem by manually copying the blocks to /usr/share[..] and see if they turn up in GRC. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I copied the xml-files manually to usr/share, and now they appear in GRC. I can use them in a flowgraph, change parameters etc. BUT: the next error I encounter now is the message: ImportError: No module named TNO_jamming_swig where 'TNO_jamming' is the name of my module. The only file on the drive that has something to do with the error is 'TNO_jamming_swig.i' in my module folder (gr-TNO_jamming). Getting lost again... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to access UHD from within my own OOT block?
Dear all,
In the Companion GUI I use the UHD source- and sink-blocks, together with my
own OOT blocks. Now I want to control the UHD blocks from within my own blocks,
for example changing the center frequency. So in my own block I would like to
write something like:
usrp->set_center_freq(whatever);
I there an easy interface/API available to do this? Or do I have to download
the gr-uhd, modify it (maybe add a method to get a pointer to the USRP out of
it?) and rebuild? Unfortunately I just could not find a starting point yet.
Regards,
Jeroen
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet
de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u
verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO
aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze
waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt
met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are
not the addressee or if this message was sent to you by mistake, you are
requested to inform the sender and delete the message. TNO accepts no liability
for the content of this e-mail, for the manner in which you use it and for
damage of any kind resulting from the risks inherent to the electronic
transmission of messages.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help needed with hacking through SWIG / Python / custom block
Hi all,
I'm trying a sort of a 'hack', but it doesn't work so far. What I want to do is
to add a method to the class in my custom block, and make this method available
in Python (the top_block.py). Without knowledge of SWIG I just tried the
following things (where ZZZ is the name of my block):
1) Add the method protoype to ZZZ.h
2) Add the method protoype to ZZZ_impl.h
3) Implement the method in ZZZ_impl.cc
4) Empty the build/swig folder to force a swig rebuild
5) Run make again
When running top_block.py I get the following errors (apparently my goal is not
that simple):
Traceback (most recent call last):
File "top_block_modified.py", line 16, in
import TNO_JJJ_2014
File "/usr/local/lib/python2.7/dist-packages/TNO_JJJ_2014/__init__.py", line
45, in
from TNO_JJJ_2014_swig import *
File
"/usr/local/lib/python2.7/dist-packages/TNO_JJJ_2014/TNO_JJJ_2014_swig.py",
line 28, in
_TNO_JJJ_2014_swig = swig_import_helper()
File
"/usr/local/lib/python2.7/dist-packages/TNO_JJJ_2014/TNO_JJJ_2014_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_TNO_JJJ_2014_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-TNO_JJJ_2014.so: undefined symbol:
_ZN3uhd14tune_request_tC1Ed
Make reported me before:
Install the project...
-- Install configuration: "Release"
-- Up-to-date: /usr/local/lib/cmake/TNO_JJJ_2014/TNO_JJJ_2014Config.cmake
-- Up-to-date: /usr/local/include/TNO_JJJ_2014/api.h
-- Installing: /usr/local/include/TNO_JJJ_2014/JJJ_kernel.h
-- Installing: /usr/local/lib/libgnuradio-TNO_JJJ_2014.so
-- Installing:
/usr/local/lib/python2.7/dist-packages/TNO_JJJ_2014/_TNO_JJJ_2014_swig.so
-- Removed runtime path from
"/usr/local/lib/python2.7/dist-packages/TNO_JJJ_2014/_TNO_JJJ_2014_swig.so"
-- Installing:
/usr/local/lib/python2.7/dist-packages/TNO_JJJ_2014/TNO_JJJ_2014_swig.py
-- Installing:
/usr/local/lib/python2.7/dist-packages/TNO_JJJ_2014/TNO_JJJ_2014_swig.pyc
-- Installing:
/usr/local/lib/python2.7/dist-packages/TNO_JJJ_2014/TNO_JJJ_2014_swig.pyo
-- Up-to-date:
/usr/local/include/TNO_JJJ_2014/TNO_JJJ_2014/swig/TNO_JJJ_2014_swig.i
-- Installing:
/usr/local/include/TNO_JJJ_2014/TNO_JJJ_2014/swig/TNO_JJJ_2014_swig_doc.i
-- Up-to-date: /usr/local/lib/python2.7/dist-packages/TNO_JJJ_2014/__init__.py
-- Up-to-date: /usr/local/lib/python2.7/dist-packages/TNO_JJJ_2014/__init__.pyc
-- Up-to-date: /usr/local/lib/python2.7/dist-packages/TNO_JJJ_2014/__init__.pyo
-- Up-to-date: /usr/local/share/gnuradio/grc/blocks/TNO_JJJ_2014_JJJ_kernel.xml
Anybody knows what I have to add/change to get this working? Maybe something in
the __init__.py file? If so, how do I generate the corresponding .pyc and .pyo
files?
Best regards,
Jeroen
This message may contain information that is not intended for you. If you are
not the addressee or if this message was sent to you by mistake, you are
requested to inform the sender and delete the message. TNO accepts no liability
for the content of this e-mail, for the manner in which you use it and for
damage of any kind resulting from the risks inherent to the electronic
transmission of messages.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help to get control over USRP from custom block
Hi all, A last attempt this time, after struggling already several months with this subject... >From within my custom (out-of-tree) C++ block I need full control over USRP >sink/source. According to the documentation, the command interface only >implements three functions (gain, center frequency and LO_offset ). I need >much more functionality however (sensors, IQ-imbalance, etc...), so I looked >at another solution. In my custom block class I added a method that takes 2 pointers: boost::shared_prt boost::shared_prt In the Python top_block.py code I add a call to this method in order to pass the USRP pointers from Python to my C++ custom block. The pointers seem to be valid in C++, but apparently the corresponding classes have empty virtual methods, so if I want to use the pointers nothing happens or Python crashes. Does anybody know how to get pointers that have all functionality implemented from the original Ettus library? I am completely stuck... It may be an ugly hack, but I just need to get things done now. Regards, Jeroen This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP + wbx-fe-simple board + WA5VJB antenna.
Dear gnuradio discussion list, Currently I'm experimenting with the USRP with the wbx-fe-simple board rev 4, wbx-board rev 2 and the WA5VJB antenna. The installation of uhd and gnuradio worked fine and I'm able to run the dialtone.grc example. However when I execute: Sudo uhd_fft -f 401M -g 26 -a TX/RX I get the GUI with some wave on it (and no errors in the terminal). When I disconnect the antenna from the USRP the wave does not change, also on other frequencies the same procedure does not show any deviation. The wave however changes slightly when moving to the 801.11 (WIFI) and the terminal prints a 0 to the screen. This all gives me the feeling that the antenna is not really working. (I expected not to see a signal on 401Mhz since this frequency is for medical hardware which is not available in the room). Did somebody experienced the same problem / has a solution for this problem? Great tnx in advantage! Kind Regards, Jeroen Slobbe - This e-mail message and its attachments are subject to the disclaimer published at the following website of Deloitte: http://www.deloitte.com/nl/disclaimer Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of member firms, each of which is a legally separate and independent entity. Please see deloitte.com/nl/about for a detailed description of the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
