Re: [Discuss-gnuradio] Error Linking UHD

[Gilad Beeri (ApolloShield)]

Marcus, the repo at https://github.com/giladbeeri/gr-uhd-link-test
is a bootstrapped OOT module with basically nothing but a simple block that
has a single uhd::time_spec_t member.

I can reproduce the linking problem with this repo and a clean GR 3.7.12
(from master) install using pybombs.

Do you mind having a look?

On Tue, Jun 19, 2018 at 2:47 PM Müller, Marcus (CEL) 
wrote:

> add a "message ()" directive that prints the GNURADIO_ALL_LIBRARIES
> that is actually used in your lib/CMakeLists.txt. If that is wrong:
>
> Move your OOT's cmake/Modules/* out of the way – I do not endorse the
> fact that we're distributing copies of all the GNU Radio CMake scripts
> with our OOT template, as these might outdate locally.
>
> I must admit I don't have an OOT where I test gr-uhd linkage myself.
>
> Best regards,
> Marcus
>
> On Tue, 2018-06-19 at 14:42 +0300, Gilad Beeri (ApolloShield) wrote:
> > I've done "rm -rf build/*" and "pushd build; cmake  ../; and make -j7;
> and make install; popd" ~ 50 times since yesterday :)
> >
> > Any suggestions for debugging it?
> >
> > On Tue, Jun 19, 2018 at 2:33 PM Müller, Marcus (CEL) 
> wrote:
> > > I must admit this is surprising to me, as the line of code where
> > > LIBS=... is printed is pretty integrally coupled to the line that
> > > specifies what GNURADIO_ALL_LIBRARIES is. Maybe CMake got confused?
> > > I know this is kind of a "haveyoutriedturningitoffandonagain" answer,
> > > but have you tried completely rm'ing your build/ directory and letting
> > > CMake run anew?
> > >
> > > Best regards,
> > > Marcus
> > >
> > > :e ../cmake/Modules/FindG   On Tue, 2018-06-19 at 14:19
> +0300,
> > > Gilad Beeri (ApolloShield) wrote:
> > > > I have a similar problem as described in
> https://lists.gnu.org/archive/html/discuss-gnuradio/2015-05/msg00195.html.
> > > >
> > > > When I try to run tests (with Python), I get:
> > > >
> > > > Traceback (most recent call last):
> > > >   File "python/myblock.py", line 12, in 
> > > > from myproj.myproj_swig import mitigation_source
> > > >   File
> "/home/user/gr/lib/python2.7/site-packages/myproj/myproj_swig.py", line 28,
> in 
> > > > _myproj_swig = swig_import_helper()
> > > >   File
> "/home/user/gr/lib/python2.7/site-packages/myproj/myproj_swig.py", line 24,
> in swig_import_helper
> > > > _mod = imp.load_module('_myproj_swig', fp, pathname, description)
> > > > ImportError: /home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0:
> undefined symbol: _ZN3uhd11time_spec_tC1Eld
> > > >
> > > >
> > > > I did add "UHD" to the line starting with
> "set(GR_REQUIRED_COMPONENTS" (in my root CMakeLists.txt) so I get the
> output of
> > > >
> > > > Checking for GNU Radio Module: UHD
> > > > -- Checking for module 'gnuradio-uhd'
> > > > --   Found gnuradio-uhd, version 3.7.11.1-as
> > > >  * INCLUDES=/home/user/gr/include
> > > >  *
> LIBS=/home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradio-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so
> > > > -- Found GNURADIO_UHD:
> /home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradio-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so
>
> > > > GNURADIO_UHD_FOUND = TRUE
> > > >
> > > > I also have in my lib/CMakeLists.txt file ${GNURADIO_ALL_LIBRARIES}
> in both target_link_libraries() lists.
> > > >
> > > > I have "#include " in my header file.
> > > >
> > > > But for some reason, it doesn't seem to link gnuradio-uhd:
> > > >
> > > > readelf -d /home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0
> > > >
> > > >  0x0001 (NEEDED) Shared library:
> [libboost_system.so.1.58.0]
> > > >  0x0001 (NEEDED) Shared library:
> [libgnuradio-runtime-3.7.11.1-as.so.0.0.0]
> > > >  0x0001 (NEEDED) Shared library:
> [libgnuradio-pmt-3.7.11.1-as.so.0.0.0]
> > > >  0x0001 (NEEDED) Shared library:
> [liblog4cpp.so.5]
> > > >  0x0001 (NEEDED) Shared library:
> [libgnuradio-filter-3.7.11.1-as.so.0.0.0]
> > > >  0x0001 (NEEDED) Shared library:
> [libstdc++.so.6]
> > > >  0x0001 (NEEDED) Shared library: [libm.so.6]
> > > >  0x0001 (NEEDED) Shared library:
> [libgcc_s.so.1]
> > > >  0x0001 (NEEDED) Shared library: [libc.so.6]
> > > >  0x000e (SONAME) Library soname:
> [libgnuradio-myproj-1.0.0git.so.0.0.0]
> > > > ___
> > > > 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 Linking UHD

[CEL]

Did, but hm, works for me :( Attaching the ldd output.
Is UHD installed through your package manager or through pybombs? Can
you locate all libuhd.so.* on your system?
 
On Wed, 2018-06-20 at 12:48 +0300, Gilad Beeri (ApolloShield) wrote:
> Marcus, the repo at https://github.com/giladbeeri/gr-uhd-link-test
> is a bootstrapped OOT module with basically nothing but a simple
> block that has a single uhd::time_spec_t member.
> 
> I can reproduce the linking problem with this repo and a clean GR
> 3.7.12 (from master) install using pybombs.
> 
> Do you mind having a look?
> 
> On Tue, Jun 19, 2018 at 2:47 PM Müller, Marcus (CEL)  > wrote:
> > add a "message ()" directive that prints the GNURADIO_ALL_LIBRARIES
> > that is actually used in your lib/CMakeLists.txt. If that is wrong:
> > 
> > Move your OOT's cmake/Modules/* out of the way – I do not endorse
> > the
> > fact that we're distributing copies of all the GNU Radio CMake
> > scripts 
> > with our OOT template, as these might outdate locally. 
> > 
> > I must admit I don't have an OOT where I test gr-uhd linkage
> > myself.
> > 
> > Best regards,
> > Marcus
> > 
> > On Tue, 2018-06-19 at 14:42 +0300, Gilad Beeri (ApolloShield)
> > wrote:
> > > I've done "rm -rf build/*" and "pushd build; cmake  ../; and make
> > -j7; and make install; popd" ~ 50 times since yesterday :)
> > > 
> > > Any suggestions for debugging it?
> > > 
> > > On Tue, Jun 19, 2018 at 2:33 PM Müller, Marcus (CEL)  > .edu> wrote:
> > > > I must admit this is surprising to me, as the line of code
> > where
> > > > LIBS=... is printed is pretty integrally coupled to the line
> > that
> > > > specifies what GNURADIO_ALL_LIBRARIES is. Maybe CMake got
> > confused?
> > > > I know this is kind of a "haveyoutriedturningitoffandonagain"
> > answer,
> > > > but have you tried completely rm'ing your build/ directory and
> > letting
> > > > CMake run anew?
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > > > :e ../cmake/Modules/FindG   On Tue, 2018-06-19 at
> > 14:19 +0300,
> > > > Gilad Beeri (ApolloShield) wrote:
> > > > > I have a similar problem as described in https://lists.gnu.or
> > g/archive/html/discuss-gnuradio/2015-05/msg00195.html.
> > > > > 
> > > > > When I try to run tests (with Python), I get:
> > > > > 
> > > > > Traceback (most recent call last):
> > > > >   File "python/myblock.py", line 12, in 
> > > > > from myproj.myproj_swig import mitigation_source
> > > > >   File "/home/user/gr/lib/python2.7/site-
> > packages/myproj/myproj_swig.py", line 28, in 
> > > > > _myproj_swig = swig_import_helper()
> > > > >   File "/home/user/gr/lib/python2.7/site-
> > packages/myproj/myproj_swig.py", line 24, in swig_import_helper
> > > > > _mod = imp.load_module('_myproj_swig', fp, pathname,
> > description)
> > > > > ImportError: /home/user/gr/lib/libgnuradio-myproj-
> > 1.0.0git.so.0.0.0: undefined symbol: _ZN3uhd11time_spec_tC1Eld
> > > > > 
> > > > > 
> > > > > I did add "UHD" to the line starting with
> > "set(GR_REQUIRED_COMPONENTS" (in my root CMakeLists.txt) so I get
> > the output of
> > > > > 
> > > > > Checking for GNU Radio Module: UHD
> > > > > -- Checking for module 'gnuradio-uhd'
> > > > > --   Found gnuradio-uhd, version 3.7.11.1-as
> > > > >  * INCLUDES=/home/user/gr/include
> > > > >  * LIBS=/home/user/gr/lib/libgnuradio-
> > uhd.so;/home/user/gr/lib/libgnuradio-
> > runtime.so;/home/user/gr/lib/libgnuradio-
> > pmt.so;/usr/lib/liblog4cpp.so
> > > > > -- Found GNURADIO_UHD: /home/user/gr/lib/libgnuradio-
> > uhd.so;/home/user/gr/lib/libgnuradio-
> > runtime.so;/home/user/gr/lib/libgnuradio-
> > pmt.so;/usr/lib/liblog4cpp.so  
> > > > > GNURADIO_UHD_FOUND = TRUE
> > > > > 
> > > > > I also have in my lib/CMakeLists.txt file
> > ${GNURADIO_ALL_LIBRARIES} in both target_link_libraries() lists.
> > > > > 
> > > > > I have "#include " in my header
> > file.
> > > > > 
> > > > > But for some reason, it doesn't seem to link gnuradio-uhd:
> > > > > 
> > > > > readelf -d /home/user/gr/lib/libgnuradio-myproj-
> > 1.0.0git.so.0.0.0
> > > > > 
> > > > >  0x0001 (NEEDED) Shared library:
> > [libboost_system.so.1.58.0]
> > > > >  0x0001 (NEEDED) Shared library:
> > [libgnuradio-runtime-3.7.11.1-as.so.0.0.0]
> > > > >  0x0001 (NEEDED) Shared library:
> > [libgnuradio-pmt-3.7.11.1-as.so.0.0.0]
> > > > >  0x0001 (NEEDED) Shared library:
> > [liblog4cpp.so.5]
> > > > >  0x0001 (NEEDED) Shared library:
> > [libgnuradio-filter-3.7.11.1-as.so.0.0.0]
> > > > >  0x0001 (NEEDED) Shared library:
> > [libstdc++.so.6]
> > > > >  0x0001 (NEEDED) Shared library:
> > [libm.so.6]
> > > > >  0x0001 (NEEDED) Shared library:
> > [libgcc_s.so.1]
> > > > >  0x0001 (NEEDED) Shared library:
> > [libc.so.6]
> > > > >  0x000e (SONAME) Library sona

Re: [Discuss-gnuradio] Error Linking UHD

[Gilad Beeri (ApolloShield)]

Only pybombs:

~/g/s/s/gnuradio (master)> sudo find / -name "libuhd.so.*"
find: ‘/run/user/1000/gvfs’: Permission denied
/home/user/gr/myproj/src/uhd/host/build/lib/libuhd.so.003
/home/user/gr/myproj/src/uhd/host/build/lib/libuhd.so.003.010
/home/user/gr/myproj/lib/libuhd.so.003
/home/user/gr/myproj/lib/libuhd.so.003.010
/home/user/gr/perf/src/uhd/host/build/lib/libuhd.so.003
/home/user/gr/perf/src/uhd/host/build/lib/libuhd.so.003.010
/home/user/gr/perf/lib/libuhd.so.003
/home/user/gr/perf/lib/libuhd.so.003.010
/home/user/gr/stable/src/uhd/host/build/lib/libuhd.so.3
/home/user/gr/stable/src/uhd/host/build/lib/libuhd.so.3.11
/home/user/gr/stable/lib/libuhd.so.3
/home/user/gr/stable/lib/libuhd.so.3.11


On Wed, Jun 20, 2018 at 1:08 PM Müller, Marcus (CEL) 
wrote:

> Did, but hm, works for me :( Attaching the ldd output.
> Is UHD installed through your package manager or through pybombs? Can
> you locate all libuhd.so.* on your system?
>
> On Wed, 2018-06-20 at 12:48 +0300, Gilad Beeri (ApolloShield) wrote:
> > Marcus, the repo at https://github.com/giladbeeri/gr-uhd-link-test
> > is a bootstrapped OOT module with basically nothing but a simple
> > block that has a single uhd::time_spec_t member.
> >
> > I can reproduce the linking problem with this repo and a clean GR
> > 3.7.12 (from master) install using pybombs.
> >
> > Do you mind having a look?
> >
> > On Tue, Jun 19, 2018 at 2:47 PM Müller, Marcus (CEL)  > > wrote:
> > > add a "message ()" directive that prints the GNURADIO_ALL_LIBRARIES
> > > that is actually used in your lib/CMakeLists.txt. If that is wrong:
> > >
> > > Move your OOT's cmake/Modules/* out of the way – I do not endorse
> > > the
> > > fact that we're distributing copies of all the GNU Radio CMake
> > > scripts
> > > with our OOT template, as these might outdate locally.
> > >
> > > I must admit I don't have an OOT where I test gr-uhd linkage
> > > myself.
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Tue, 2018-06-19 at 14:42 +0300, Gilad Beeri (ApolloShield)
> > > wrote:
> > > > I've done "rm -rf build/*" and "pushd build; cmake  ../; and make
> > > -j7; and make install; popd" ~ 50 times since yesterday :)
> > > >
> > > > Any suggestions for debugging it?
> > > >
> > > > On Tue, Jun 19, 2018 at 2:33 PM Müller, Marcus (CEL)  > > .edu> wrote:
> > > > > I must admit this is surprising to me, as the line of code
> > > where
> > > > > LIBS=... is printed is pretty integrally coupled to the line
> > > that
> > > > > specifies what GNURADIO_ALL_LIBRARIES is. Maybe CMake got
> > > confused?
> > > > > I know this is kind of a "haveyoutriedturningitoffandonagain"
> > > answer,
> > > > > but have you tried completely rm'ing your build/ directory and
> > > letting
> > > > > CMake run anew?
> > > > >
> > > > > Best regards,
> > > > > Marcus
> > > > >
> > > > > :e ../cmake/Modules/FindG   On Tue, 2018-06-19 at
> > > 14:19 +0300,
> > > > > Gilad Beeri (ApolloShield) wrote:
> > > > > > I have a similar problem as described in https://lists.gnu.or
> > > g/archive/html/discuss-gnuradio/2015-05/msg00195.html.
> > > > > >
> > > > > > When I try to run tests (with Python), I get:
> > > > > >
> > > > > > Traceback (most recent call last):
> > > > > >   File "python/myblock.py", line 12, in 
> > > > > > from myproj.myproj_swig import mitigation_source
> > > > > >   File "/home/user/gr/lib/python2.7/site-
> > > packages/myproj/myproj_swig.py", line 28, in 
> > > > > > _myproj_swig = swig_import_helper()
> > > > > >   File "/home/user/gr/lib/python2.7/site-
> > > packages/myproj/myproj_swig.py", line 24, in swig_import_helper
> > > > > > _mod = imp.load_module('_myproj_swig', fp, pathname,
> > > description)
> > > > > > ImportError: /home/user/gr/lib/libgnuradio-myproj-
> > > 1.0.0git.so.0.0.0: undefined symbol: _ZN3uhd11time_spec_tC1Eld
> > > > > >
> > > > > >
> > > > > > I did add "UHD" to the line starting with
> > > "set(GR_REQUIRED_COMPONENTS" (in my root CMakeLists.txt) so I get
> > > the output of
> > > > > >
> > > > > > Checking for GNU Radio Module: UHD
> > > > > > -- Checking for module 'gnuradio-uhd'
> > > > > > --   Found gnuradio-uhd, version 3.7.11.1-as
> > > > > >  * INCLUDES=/home/user/gr/include
> > > > > >  * LIBS=/home/user/gr/lib/libgnuradio-
> > > uhd.so;/home/user/gr/lib/libgnuradio-
> > > runtime.so;/home/user/gr/lib/libgnuradio-
> > > pmt.so;/usr/lib/liblog4cpp.so
> > > > > > -- Found GNURADIO_UHD: /home/user/gr/lib/libgnuradio-
> > > uhd.so;/home/user/gr/lib/libgnuradio-
> > > runtime.so;/home/user/gr/lib/libgnuradio-
> > > pmt.so;/usr/lib/liblog4cpp.so
> > > > > > GNURADIO_UHD_FOUND = TRUE
> > > > > >
> > > > > > I also have in my lib/CMakeLists.txt file
> > > ${GNURADIO_ALL_LIBRARIES} in both target_link_libraries() lists.
> > > > > >
> > > > > > I have "#include " in my header
> > > file.
> > > > > >
> > > > > > But for some reason, it doesn't seem to link gnuradio-uhd:
> > > > > >
> > > > > > readelf -d /home/user/gr/lib/libgnuradio-myproj-
> > > 1

Re: [Discuss-gnuradio] Error Linking UHD

[Bastian Bloessl]

Any chances you are confusing libgnuradio-uhd.so with libuhd.so. To me 
it sounds like you want to link against the latter.


Maybe some linkers resolve symbols from libuhd through libgnuradio-uhd 
and some don't (which might make sense if you do not use any symbols 
defined in libgnuradio-uhd).


Best,
Bastian

On 6/19/2018 13:27, Gilad Beeri (ApolloShield) wrote:
The MESSAGE directive shows it should be ok - added to 
lib/CMakeLists.txt, after the first target_link_libraries(), the line 
"MESSAGE(STATUS "DEBUG GR LIBS: ${GNURADIO_ALL_LIBRARIES}")".


The output:
/
/
/-- DEBUG GR LIBS: 
/home/user/gr/lib/libgnuradio-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so;/home/user/gr/lib/libgnuradio-filter.so;/home/user/gr/lib/libgnuradio-fft.so;/home/user/gr/lib/libgnuradio-uhd.so/

/
/
I moved away all cmake/ files and then put them back one-by-one until 
the build succeeded, which meant I ended up removing:

  D cmake/Modules/CMakeParseArgumentsCopy.cmake
  D cmake/Modules/FindGnuradioRuntime.cmake
  D cmake/Modules/GrMiscUtils.cmake
  D cmake/Modules/GrPython.cmake
  D cmake/Modules/GrSwig.cmake
  D cmake/Modules/GrTest.cmake
  D cmake/Modules/UseSWIG.cmake

but still no luck (the undefined symbol error still exists).

It might be worth to mention, the version I use is 3.7.11.1.


On Tue, Jun 19, 2018 at 2:47 PM Müller, Marcus (CEL) > wrote:


add a "message ()" directive that prints the GNURADIO_ALL_LIBRARIES
that is actually used in your lib/CMakeLists.txt. If that is wrong:

Move your OOT's cmake/Modules/* out of the way – I do not endorse the
fact that we're distributing copies of all the GNU Radio CMake scripts
with our OOT template, as these might outdate locally.

I must admit I don't have an OOT where I test gr-uhd linkage myself.

Best regards,
Marcus

On Tue, 2018-06-19 at 14:42 +0300, Gilad Beeri (ApolloShield) wrote:
 > I've done "rm -rf build/*" and "pushd build; cmake  ../; and make
-j7; and make install; popd" ~ 50 times since yesterday :)
 >
 > Any suggestions for debugging it?
 >
 > On Tue, Jun 19, 2018 at 2:33 PM Müller, Marcus (CEL)
mailto:muel...@kit.edu>> wrote:
 > > I must admit this is surprising to me, as the line of code where
 > > LIBS=... is printed is pretty integrally coupled to the line that
 > > specifies what GNURADIO_ALL_LIBRARIES is. Maybe CMake got confused?
 > > I know this is kind of a "haveyoutriedturningitoffandonagain"
answer,
 > > but have you tried completely rm'ing your build/ directory and
letting
 > > CMake run anew?
 > >
 > > Best regards,
 > > Marcus
 > >
 > > :e ../cmake/Modules/FindG               On Tue, 2018-06-19 at
14:19 +0300,
 > > Gilad Beeri (ApolloShield) wrote:
 > > > I have a similar problem as described in
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-05/msg00195.html.
 > > >
 > > > When I try to run tests (with Python), I get:
 > > >
 > > > Traceback (most recent call last):
 > > >   File "python/myblock.py", line 12, in 
 > > >     from myproj.myproj_swig import mitigation_source
 > > >   File
"/home/user/gr/lib/python2.7/site-packages/myproj/myproj_swig.py",
line 28, in 
 > > >     _myproj_swig = swig_import_helper()
 > > >   File
"/home/user/gr/lib/python2.7/site-packages/myproj/myproj_swig.py",
line 24, in swig_import_helper
 > > >     _mod = imp.load_module('_myproj_swig', fp, pathname,
description)
 > > > ImportError:
/home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0: undefined
symbol: _ZN3uhd11time_spec_tC1Eld
 > > >
 > > >
 > > > I did add "UHD" to the line starting with
"set(GR_REQUIRED_COMPONENTS" (in my root CMakeLists.txt) so I get
the output of
 > > >
 > > > Checking for GNU Radio Module: UHD
 > > > -- Checking for module 'gnuradio-uhd'
 > > > --   Found gnuradio-uhd, version 3.7.11.1-as
 > > >  * INCLUDES=/home/user/gr/include
 > > >  *

LIBS=/home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradio-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so
 > > > -- Found GNURADIO_UHD:

/home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradio-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so

 > > > GNURADIO_UHD_FOUND = TRUE
 > > >
 > > > I also have in my lib/CMakeLists.txt file
${GNURADIO_ALL_LIBRARIES} in both target_link_libraries() lists.
 > > >
 > > > I have "#include " in my header file.
 > > >
 > > > But for some reason, it doesn't seem to link gnuradio-uhd:
 > > >
 > > > readelf -d /home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0
 > > >
 > > >  0x0001 (NEEDED)             Shared library:
[libboost_system.so.1.58.0]
 > > >  0x0001 (NEEDED)             Shared library:
[l

Re: [Discuss-gnuradio] FIFO file , File sink , File souce

[CEL]

That's normal FIFO behaviour! From `man 3 mkfifo`:

> Opening a FIFO for reading normally blocks until some other process
opens  the  same  FIFO for writing, and vice versa. 

Remember, the GRC file is just converted to a Python program, in which
the different blocks are instantiated sequentially. Now, the problem
follows is that you can't even initialize the file source if the file
sink doesn't finish initializing, or the other way around, whichever
comes first.

Best regards,
Marcus

On Wed, 2018-06-20 at 10:52 +, Amirhosein naseri wrote:
> Hi everybody,
> 
> I have a simple GRC like this:
> 
> Signal Source --> Throttle --> File Sink
> File Source --> Throttle -> Qt Freq Sink
> 
> and i have a Piped File with mkfifo that GRC work with it. but when i run GRC 
> , it freezes ... Why???
> 
> 
> Tnx??
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error Linking UHD

[CEL]

Basti applied hammer to nail's head. It's (probably) super effective.

yeah... time_spec_t's functions aren't exported symbols of libgnuradio-
uhd, but of libuhd! This might work on some and not on other build
systems due to different handling of visibility of symbols *used* in a
library. uff!

On Wed, 2018-06-20 at 11:04 +0100, Bastian Bloessl wrote:
> Any chances you are confusing libgnuradio-uhd.so with libuhd.so. To me 
> it sounds like you want to link against the latter.
> 
> Maybe some linkers resolve symbols from libuhd through libgnuradio-uhd 
> and some don't (which might make sense if you do not use any symbols 
> defined in libgnuradio-uhd).
> 
> Best,
> Bastian
> 
> On 6/19/2018 13:27, Gilad Beeri (ApolloShield) wrote:
> > The MESSAGE directive shows it should be ok - added to 
> > lib/CMakeLists.txt, after the first target_link_libraries(), the line 
> > "MESSAGE(STATUS "DEBUG GR LIBS: ${GNURADIO_ALL_LIBRARIES}")".
> > 
> > The output:
> > /
> > /
> > /-- DEBUG GR LIBS: 
> > /home/user/gr/lib/libgnuradio-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so;/home/user/gr/lib/libgnuradio-filter.so;/home/user/gr/lib/libgnuradio-fft.so;/home/user/gr/lib/libgnuradio-uhd.so/
> > /
> > /
> > I moved away all cmake/ files and then put them back one-by-one until 
> > the build succeeded, which meant I ended up removing:
> >   D cmake/Modules/CMakeParseArgumentsCopy.cmake
> >   D cmake/Modules/FindGnuradioRuntime.cmake
> >   D cmake/Modules/GrMiscUtils.cmake
> >   D cmake/Modules/GrPython.cmake
> >   D cmake/Modules/GrSwig.cmake
> >   D cmake/Modules/GrTest.cmake
> >   D cmake/Modules/UseSWIG.cmake
> > 
> > but still no luck (the undefined symbol error still exists).
> > 
> > It might be worth to mention, the version I use is 3.7.11.1.
> > 
> > 
> > On Tue, Jun 19, 2018 at 2:47 PM Müller, Marcus (CEL)  > > wrote:
> > 
> > add a "message ()" directive that prints the GNURADIO_ALL_LIBRARIES
> > that is actually used in your lib/CMakeLists.txt. If that is wrong:
> > 
> > Move your OOT's cmake/Modules/* out of the way – I do not endorse the
> > fact that we're distributing copies of all the GNU Radio CMake scripts
> > with our OOT template, as these might outdate locally.
> > 
> > I must admit I don't have an OOT where I test gr-uhd linkage myself.
> > 
> > Best regards,
> > Marcus
> > 
> > On Tue, 2018-06-19 at 14:42 +0300, Gilad Beeri (ApolloShield) wrote:
> >  > I've done "rm -rf build/*" and "pushd build; cmake  ../; and make
> > -j7; and make install; popd" ~ 50 times since yesterday :)
> >  >
> >  > Any suggestions for debugging it?
> >  >
> >  > On Tue, Jun 19, 2018 at 2:33 PM Müller, Marcus (CEL)
> > mailto:muel...@kit.edu>> wrote:
> >  > > I must admit this is surprising to me, as the line of code where
> >  > > LIBS=... is printed is pretty integrally coupled to the line that
> >  > > specifies what GNURADIO_ALL_LIBRARIES is. Maybe CMake got confused?
> >  > > I know this is kind of a "haveyoutriedturningitoffandonagain"
> > answer,
> >  > > but have you tried completely rm'ing your build/ directory and
> > letting
> >  > > CMake run anew?
> >  > >
> >  > > Best regards,
> >  > > Marcus
> >  > >
> >  > > :e ../cmake/Modules/FindG   On Tue, 2018-06-19 at
> > 14:19 +0300,
> >  > > Gilad Beeri (ApolloShield) wrote:
> >  > > > I have a similar problem as described in
> > 
> > https://lists.gnu.org/archive/html/discuss-gnuradio/2015-05/msg00195.html.
> >  > > >
> >  > > > When I try to run tests (with Python), I get:
> >  > > >
> >  > > > Traceback (most recent call last):
> >  > > >   File "python/myblock.py", line 12, in 
> >  > > > from myproj.myproj_swig import mitigation_source
> >  > > >   File
> > "/home/user/gr/lib/python2.7/site-packages/myproj/myproj_swig.py",
> > line 28, in 
> >  > > > _myproj_swig = swig_import_helper()
> >  > > >   File
> > "/home/user/gr/lib/python2.7/site-packages/myproj/myproj_swig.py",
> > line 24, in swig_import_helper
> >  > > > _mod = imp.load_module('_myproj_swig', fp, pathname,
> > description)
> >  > > > ImportError:
> > /home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0: undefined
> > symbol: _ZN3uhd11time_spec_tC1Eld
> >  > > >
> >  > > >
> >  > > > I did add "UHD" to the line starting with
> > "set(GR_REQUIRED_COMPONENTS" (in my root CMakeLists.txt) so I get
> > the output of
> >  > > >
> >  > > > Checking for GNU Radio Module: UHD
> >  > > > -- Checking for module 'gnuradio-uhd'
> >  > > > --   Found gnuradio-uhd, version 3.7.11.1-as
> >  > > >  * INCLUDES=/home/user/gr/include
> >  > > >  *
> > 
> > LIBS=/home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradio-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so

Re: [Discuss-gnuradio] FIFO file , File sink , File souce

[CEL]

Again, can't tell what you're trying to do, can't help you! Describe
what problem you're trying to solve.
On Wed, 2018-06-20 at 12:15 +, Amirhosein naseri wrote:
> The flowgraph i mentioned was a simplified version of my work ...
> 
> I can seprate it in two flowgraph, so in this situation i must run which side 
> of transfer first??
> 
> On Wednesday, June 20, 2018, 4:40:06 PM GMT+4:30, Müller, Marcus (CEL) 
>  wrote:
> 
> 
> Well, I don't know what problem you're solving. It works if you're not
> doing this in the same flow graph.
> 
> On Wed, 2018-06-20 at 12:09 +, Amirhosein naseri wrote:
> > Tnx Marcus for replying 
> > 
> > so based on what u said ... we can not use such configuration with FIFO , 
> > is it ture???
> > if NO , what is the solution???
> > 
> > On Wednesday, June 20, 2018, 4:28:52 PM GMT+4:30, Müller, Marcus (CEL) 
> >  wrote:
> > 
> > 
> > That's normal FIFO behaviour! From `man 3 mkfifo`:
> > 
> > > Opening a FIFO for reading normally blocks until some other process
> > opens  the  same  FIFO for writing, and vice versa. 
> > 
> > Remember, the GRC file is just converted to a Python program, in which
> > the different blocks are instantiated sequentially. Now, the problem
> > follows is that you can't even initialize the file source if the file
> > sink doesn't finish initializing, or the other way around, whichever
> > comes first.
> > 
> > Best regards,
> > Marcus
> > 
> > On Wed, 2018-06-20 at 10:52 +, Amirhosein naseri wrote:
> > > Hi everybody,
> > > 
> > > I have a simple GRC like this:
> > > 
> > > Signal Source --> Throttle --> File Sink
> > > File Source --> Throttle -> Qt Freq Sink
> > > 
> > > and i have a Piped File with mkfifo that GRC work with it. but when i run 
> > > GRC , it freezes ... Why???
> > > 
> > > 
> > > Tnx??
> > 
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error Linking UHD

[Gilad Beeri (ApolloShield)]

Yay, it works!

Thank you, Basti and Marcus :)

So the only change I needed to make for my build system is to find the
first target_link_libraries() under lib/CMakeLists.txt and add both
${GNURADIO_ALL_LIBRARIES} and uhd to the list (both are required). I did
not have to add anything to the link list of the test project, nor did I
have to add UHD to the GR_REQUIRED_COMPONENTS list in the root
CMakeLists.txt.

Thanks again!


On Wed, Jun 20, 2018 at 3:00 PM Müller, Marcus (CEL) 
wrote:

> Basti applied hammer to nail's head. It's (probably) super effective.
>
> yeah... time_spec_t's functions aren't exported symbols of libgnuradio-
> uhd, but of libuhd! This might work on some and not on other build
> systems due to different handling of visibility of symbols *used* in a
> library. uff!
>
> On Wed, 2018-06-20 at 11:04 +0100, Bastian Bloessl wrote:
> > Any chances you are confusing libgnuradio-uhd.so with libuhd.so. To me
> > it sounds like you want to link against the latter.
> >
> > Maybe some linkers resolve symbols from libuhd through libgnuradio-uhd
> > and some don't (which might make sense if you do not use any symbols
> > defined in libgnuradio-uhd).
> >
> > Best,
> > Bastian
> >
> > On 6/19/2018 13:27, Gilad Beeri (ApolloShield) wrote:
> > > The MESSAGE directive shows it should be ok - added to
> > > lib/CMakeLists.txt, after the first target_link_libraries(), the line
> > > "MESSAGE(STATUS "DEBUG GR LIBS: ${GNURADIO_ALL_LIBRARIES}")".
> > >
> > > The output:
> > > /
> > > /
> > > /-- DEBUG GR LIBS:
> > >
> /home/user/gr/lib/libgnuradio-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so;/home/user/gr/lib/libgnuradio-filter.so;/home/user/gr/lib/libgnuradio-fft.so;/home/user/gr/lib/
> libgnuradio-uhd.so/
> > > /
> > > /
> > > I moved away all cmake/ files and then put them back one-by-one until
> > > the build succeeded, which meant I ended up removing:
> > >   D cmake/Modules/CMakeParseArgumentsCopy.cmake
> > >   D cmake/Modules/FindGnuradioRuntime.cmake
> > >   D cmake/Modules/GrMiscUtils.cmake
> > >   D cmake/Modules/GrPython.cmake
> > >   D cmake/Modules/GrSwig.cmake
> > >   D cmake/Modules/GrTest.cmake
> > >   D cmake/Modules/UseSWIG.cmake
> > >
> > > but still no luck (the undefined symbol error still exists).
> > >
> > > It might be worth to mention, the version I use is 3.7.11.1.
> > >
> > >
> > > On Tue, Jun 19, 2018 at 2:47 PM Müller, Marcus (CEL)  > > > wrote:
> > >
> > > add a "message ()" directive that prints the GNURADIO_ALL_LIBRARIES
> > > that is actually used in your lib/CMakeLists.txt. If that is wrong:
> > >
> > > Move your OOT's cmake/Modules/* out of the way – I do not endorse
> the
> > > fact that we're distributing copies of all the GNU Radio CMake
> scripts
> > > with our OOT template, as these might outdate locally.
> > >
> > > I must admit I don't have an OOT where I test gr-uhd linkage
> myself.
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Tue, 2018-06-19 at 14:42 +0300, Gilad Beeri (ApolloShield)
> wrote:
> > >  > I've done "rm -rf build/*" and "pushd build; cmake  ../; and
> make
> > > -j7; and make install; popd" ~ 50 times since yesterday :)
> > >  >
> > >  > Any suggestions for debugging it?
> > >  >
> > >  > On Tue, Jun 19, 2018 at 2:33 PM Müller, Marcus (CEL)
> > > mailto:muel...@kit.edu>> wrote:
> > >  > > I must admit this is surprising to me, as the line of code
> where
> > >  > > LIBS=... is printed is pretty integrally coupled to the line
> that
> > >  > > specifies what GNURADIO_ALL_LIBRARIES is. Maybe CMake got
> confused?
> > >  > > I know this is kind of a "haveyoutriedturningitoffandonagain"
> > > answer,
> > >  > > but have you tried completely rm'ing your build/ directory and
> > > letting
> > >  > > CMake run anew?
> > >  > >
> > >  > > Best regards,
> > >  > > Marcus
> > >  > >
> > >  > > :e ../cmake/Modules/FindG   On Tue, 2018-06-19 at
> > > 14:19 +0300,
> > >  > > Gilad Beeri (ApolloShield) wrote:
> > >  > > > I have a similar problem as described in
> > >
> https://lists.gnu.org/archive/html/discuss-gnuradio/2015-05/msg00195.html.
> > >  > > >
> > >  > > > When I try to run tests (with Python), I get:
> > >  > > >
> > >  > > > Traceback (most recent call last):
> > >  > > >   File "python/myblock.py", line 12, in 
> > >  > > > from myproj.myproj_swig import mitigation_source
> > >  > > >   File
> > > "/home/user/gr/lib/python2.7/site-packages/myproj/myproj_swig.py",
> > > line 28, in 
> > >  > > > _myproj_swig = swig_import_helper()
> > >  > > >   File
> > > "/home/user/gr/lib/python2.7/site-packages/myproj/myproj_swig.py",
> > > line 24, in swig_import_helper
> > >  > > > _mod = imp.load_module('_myproj_swig', fp, pathname,
> > > description)
> > >  > > > ImportError:
> > > /home

Re: [Discuss-gnuradio] FIFO file , File sink , File souce

[CEL]

Please try to keep answers on the list.Also, it's pretty frustrating to have 
helped you, but not knowing how, and also, doubting you do something sensible.
Best regards,Marcus
On Wed, 2018-06-20 at 12:23 +, Amirhosein naseri wrote:
> Tnx Marcus for your answers
> I split flowgraph in two part and it worked ...and it does'nt matter run 
> witch flowgraph first 
> 
> 
> Best Regards.
> 
> 
> 
> 
> 
> 
> 
> 
> On Wednesday, June 20, 2018, 4:49:56 PM GMT+4:30, Müller, 
> Marcus (CEL)  wrote:
> 
> 
> 
> 
> 
> Again, can't tell what you're trying to do, can't help you! 
> Describe
> what problem you're trying to solve.
> On Wed, 2018-06-20 at 12:15 +, Amirhosein naseri wrote:
> > The flowgraph i mentioned was a simplified version of my work ...
> > 
> > I can seprate it in two flowgraph, so in this situation i must run which 
> > side of transfer first??
> > 
> > On Wednesday, June 20, 2018, 4:40:06 PM GMT+4:30, Müller, Marcus (CEL) 
> >  wrote:
> > 
> > 
> > Well, I don't know what problem you're solving. It works if you're not
> > doing this in the same flow graph.
> > 
> > On Wed, 2018-06-20 at 12:09 +, Amirhosein naseri wrote:
> > > Tnx Marcus for replying 
> > > 
> > > so based on what u said ... we can not use such configuration with FIFO , 
> > > is it ture???
> > > if NO , what is the solution???
> > > 
> > > On Wednesday, June 20, 2018, 4:28:52 PM GMT+4:30, Müller, Marcus (CEL) 
> > >  wrote:
> > > 
> > > 
> > > That's normal FIFO behaviour! From `man 3 mkfifo`:
> > > 
> > > > Opening a FIFO for reading normally blocks until some other process
> > > opens  the  same  FIFO for writing, and vice versa. 
> > > 
> > > Remember, the GRC file is just converted to a Python program, in which
> > > the different blocks are instantiated sequentially. Now, the problem
> > > follows is that you can't even initialize the file source if the file
> > > sink doesn't finish initializing, or the other way around, whichever
> > > comes first.
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > On Wed, 2018-06-20 at 10:52 +, Amirhosein naseri wrote:
> > > > Hi everybody,
> > > > 
> > > > I have a simple GRC like this:
> > > > 
> > > > Signal Source --> Throttle --> File Sink
> > > > File Source --> Throttle -> Qt Freq Sink
> > > > 
> > > > and i have a Piped File with mkfifo that GRC work with it. but when i 
> > > > run GRC , it freezes ... Why???
> > > > 
> > > > 
> > > > Tnx??
> > > 
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FIFO file , File sink , File souce

[CEL]

This sentence makes no sense on its own. Please post a whole
description of what you're doing: I'll from now on will ignore your
questions that don't follow that methodology. See also:

http://www.catb.org/esr/faqs/smart-questions.html
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-10/msg00213.ht
ml


On Wed, 2018-06-20 at 14:00 +, Amirhosein naseri wrote:
> Another point is :
> 
> If u in python code generated from GRC construct transmit chain completely 
> (definition of blocks and their connections ) and then construct receive 
> chain or vise versa , u can use both chain in same flowgragh ..
> 
> 
> 
> On Wednesday, June 20, 2018, 4:55:31 PM GMT+4:30, Müller, Marcus (CEL) 
>  wrote:
> 
> 
> Please try to keep answers on the list.
> Also, it's pretty frustrating to have helped you, but not knowing how, and 
> also, doubting you do something sensible.
> 
> Best regards,
> Marcus
> 
> On Wed, 2018-06-20 at 12:23 +, Amirhosein naseri wrote:
> > Tnx Marcus for your answers
> > 
> > I split flowgraph in two part and it worked ...
> > and it does'nt matter run witch flowgraph first 
> > 
> > 
> > Best Regards.
> > 
> > On Wednesday, June 20, 2018, 4:49:56 PM GMT+4:30, Müller, Marcus (CEL) 
> >  wrote:
> > 
> > 
> > Again, can't tell what you're trying to do, can't help you! Describe
> > what problem you're trying to solve.
> > 
> > On Wed, 2018-06-20 at 12:15 +, Amirhosein naseri wrote:
> > > The flowgraph i mentioned was a simplified version of my work ...
> > > 
> > > I can seprate it in two flowgraph, so in this situation i must run which 
> > > side of transfer first??
> > > 
> > > On Wednesday, June 20, 2018, 4:40:06 PM GMT+4:30, Müller, Marcus (CEL) 
> > >  wrote:
> > > 
> > > 
> > > Well, I don't know what problem you're solving. It works if you're not
> > > doing this in the same flow graph.
> > > 
> > > On Wed, 2018-06-20 at 12:09 +, Amirhosein naseri wrote:
> > > > Tnx Marcus for replying 
> > > > 
> > > > so based on what u said ... we can not use such configuration with FIFO 
> > > > , is it ture???
> > > > if NO , what is the solution???
> > > > 
> > > > On Wednesday, June 20, 2018, 4:28:52 PM GMT+4:30, Müller, Marcus (CEL) 
> > > >  wrote:
> > > > 
> > > > 
> > > > That's normal FIFO behaviour! From `man 3 mkfifo`:
> > > > 
> > > > > Opening a FIFO for reading normally blocks until some other process
> > > > opens  the  same  FIFO for writing, and vice versa. 
> > > > 
> > > > Remember, the GRC file is just converted to a Python program, in which
> > > > the different blocks are instantiated sequentially. Now, the problem
> > > > follows is that you can't even initialize the file source if the file
> > > > sink doesn't finish initializing, or the other way around, whichever
> > > > comes first.
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > > > On Wed, 2018-06-20 at 10:52 +, Amirhosein naseri wrote:
> > > > > Hi everybody,
> > > > > 
> > > > > I have a simple GRC like this:
> > > > > 
> > > > > Signal Source --> Throttle --> File Sink
> > > > > File Source --> Throttle -> Qt Freq Sink
> > > > > 
> > > > > and i have a Piped File with mkfifo that GRC work with it. but when i 
> > > > > run GRC , it freezes ... Why???
> > > > > 
> > > > > 
> > > > > Tnx??
> > > > 
> > > > > ___
> > > > > Discuss-gnuradio mailing list
> > > > > Discuss-gnuradio@gnu.org
> > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error Linking UHD

[Ralph A. Schmid, dk5ras]

I had this after the last bigger changes, maybe two weeks ago or so. Went back 
to maint, all was fine, forth to master, and again the issues. Deleting the 
build folder did not help, but deleting the whole gnuradio folder and doing a 
new git clone helped. 

 

Ralph.

 

From: Gilad Beeri (ApolloShield) [mailto:gi...@apolloshield.com] 
Sent: Tuesday, June 19, 2018 5:06 PM
To: Ralph A. Schmid, dk5ras 
Cc: Müller, Marcus (CEL) ; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Error Linking UHD

 

Which version of gnuradio works for you now?

 

On Tue, Jun 19, 2018 at 5:22 PM Ralph A. Schmid, dk5ras mailto:ra...@schmid.xxx> > wrote:

Hi,

I had maybe similar issues with gnuradio recently, and when I not only removed 
the build folder but the whole gnuradio folder and did a new git clone, it 
magically went through as if there never had been any issue :) Don't ask how 
much time I wasted on this one :)))

Ralph.

> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio-  
> bounces+ralph=schmid@gnu.org  ] On Behalf Of 
> Müller, Marcus (CEL)
> Sent: Tuesday, June 19, 2018 1:33 PM
> To: gi...@apolloshield.com  ; 
> discuss-gnuradio@gnu.org  
> Subject: Re: [Discuss-gnuradio] Error Linking UHD
> 
> I must admit this is surprising to me, as the line of code where LIBS=... is
> printed is pretty integrally coupled to the line that specifies what
> GNURADIO_ALL_LIBRARIES is. Maybe CMake got confused?
> I know this is kind of a "haveyoutriedturningitoffandonagain" answer, but
> have you tried completely rm'ing your build/ directory and letting CMake run
> anew?
> 
> Best regards,
> Marcus
> 
> :e ../cmake/Modules/FindG On Tue, 2018-06-19 at 14:19 +0300,
> Gilad Beeri (ApolloShield) wrote:
> > I have a similar problem as described in
> https://lists.gnu.org/archive/html/discuss-gnuradio/2015-05/msg00195.html.
> >
> > When I try to run tests (with Python), I get:
> >
> > Traceback (most recent call last):
> >   File "python/myblock.py", line 12, in 
> > from myproj.myproj_swig import mitigation_source
> >   File "/home/user/gr/lib/python2.7/site-
> packages/myproj/myproj_swig.py", line 28, in 
> > _myproj_swig = swig_import_helper()
> >   File "/home/user/gr/lib/python2.7/site-
> packages/myproj/myproj_swig.py", line 24, in swig_import_helper
> > _mod = imp.load_module('_myproj_swig', fp, pathname, description)
> > ImportError: /home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0:
> > undefined symbol: _ZN3uhd11time_spec_tC1Eld
> >
> >
> > I did add "UHD" to the line starting with
> "set(GR_REQUIRED_COMPONENTS"
> > (in my root CMakeLists.txt) so I get the output of
> >
> > Checking for GNU Radio Module: UHD
> > -- Checking for module 'gnuradio-uhd'
> > --   Found gnuradio-uhd, version 3.7.11.1-as
> >  * INCLUDES=/home/user/gr/include
> >  *
> > LIBS=/home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradi
> > o-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.
> > so
> > -- Found GNURADIO_UHD:
> > /home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradio-run
> > time.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so
> > GNURADIO_UHD_FOUND = TRUE
> >
> > I also have in my lib/CMakeLists.txt file ${GNURADIO_ALL_LIBRARIES} in
> both target_link_libraries() lists.
> >
> > I have "#include " in my header file.
> >
> > But for some reason, it doesn't seem to link gnuradio-uhd:
> >
> > readelf -d /home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0
> >
> >  0x0001 (NEEDED) Shared library:
> [libboost_system.so.1.58.0]
> >  0x0001 (NEEDED) Shared library: 
> > [libgnuradio-runtime-
> 3.7.11.1-as.so.0.0.0]
> >  0x0001 (NEEDED) Shared library: [libgnuradio-pmt-
> 3.7.11.1-as.so.0.0.0]
> >  0x0001 (NEEDED) Shared library: [liblog4cpp.so.5]
> >  0x0001 (NEEDED) Shared library: 
> > [libgnuradio-filter-
> 3.7.11.1-as.so.0.0.0]
> >  0x0001 (NEEDED) Shared library: [libstdc++.so.6]
> >  0x0001 (NEEDED) Shared library: [libm.so.6]
> >  0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
> >  0x0001 (NEEDED) Shared library: [libc.so.6]
> >  0x000e (SONAME) Library soname: [libgnuradio-
> myproj-1.0.0git.so.0.0.0]
> > ___
> > 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] Expected FPGA compatibility number 35, but got 33

[Mir Muhammad Lodro]

Hi All,
I have installed gnuradio from source as instructed on gnuradio webpage. I
have Ubuntu 18.04 on my host PC. I can ping USRP x310 and can also do
uhd_find_devices, however when I use "uhd_usrp_probe --args
"addr=192.168.10.2" it return FPGA compatibility issue. In repose to this I
have done uhd_images_downloader, uhd_image_loader and power-cycled USRP
x310. However, it repeats with the same FPGA incompatibility issue. Why it
happens despite I follows proper steps. Is it because of outdated FPGA
image not compatible with latest UHD release. If yes then what's the
solution.
Thanks
Mir Lodro

mirlodro@eexmmlo:~$ uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_3.12.0.0-release
--
-- UHD Device 0
--
Device Address:
serial: 30C098D
addr: 192.168.10.2
fpga: HG
name:
product: X310
type: x300


mirlodro@eexmmlo:~$ uhd_usrp_probe --args "addr=192.168.10.2"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_3.12.0.0-release
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
Error: RuntimeError: Expected FPGA compatibility number 35, but got 33:
The FPGA image on your device is not compatible with this host code build.
Download the appropriate FPGA images for this version of UHD.
Please run:

 "/usr/lib/uhd/utils/uhd_images_downloader.py"

Then burn a new image to the on-board flash storage of your
USRP X3xx device using the image loader utility. Use this command:

"/usr/bin/uhd_image_loader" --args="type=x300,addr=192.168.10.2"

For more information, refer to the UHD manual:

 http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_flash
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Help on gnuradio

[c...@origosat.com]

   Hi, I am new to the gnuradio environment..so please forgive me... I have an 
USRP B200 and I am looking to save to a file I & Q samples of bursty, random 
(ALOHA) messages sampled at high rate, for furter processing (in a repeatable 
fashion). Of course it is not possible to save 15--20 mminutes of data at 
50MSPS, but using something like a "valve" (deprecated in GRC) it vould be 
possible:

   1) to detect in real time the burst data transmission

   2) to open the valve towards a file sink

   A separate file could be used to record timestamp and/or length of data 
blocks recorded

   Looking at  GRC I haven't found any useable block to build a valve used at 
run time based on a threshold (e.g. output of a filter to detect the TX random 
signal) . Could anybody help?

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

Re: [Discuss-gnuradio] Help on gnuradio

[Marcus D. Leech]

On 06/20/2018 01:05 PM, c...@origosat.com wrote:
Hi, I am new to the gnuradio environment..so please forgive me... I 
have an USRP B200 and I am looking to save to a file I & Q samples of 
bursty, random (ALOHA) messages sampled at high rate, for furter 
processing (in a repeatable fashion). Of course it is not possible to 
save 15--20 mminutes of data at 50MSPS, but using something like a 
"valve" (deprecated in GRC) it vould be possible:

1) to detect in real time the burst data transmission
2) to open the valve towards a file sink
A separate file could be used to record timestamp and/or length of 
data blocks recorded


Looking at  GRC I haven't found any useable block to build a valve 
used at run time based on a threshold (e.g. output of a filter to 
detect the TX random signal) . Could anybody help?

Thanks a lot


Here's a "trick".

Have your threshold detector switch the output of the file sink between 
/dev/null and an actual file.


There's also power squelch, which can either insert zeros, or act as a 
"gate".




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

[Discuss-gnuradio] Regarding usrp b200mini

[Sai Parepalli Laxman]

Hey guys,

I am fairly new to gnuradio companion but I was trying to use the UHD: USRP
source block in the environment with my usrp b200mini but it does not show
up.

How do I verify this?
What do I need to put in the device address?

-> uhd_find_devices and uhd_usrp_probe are able to load the image and the
device correctly.

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

Re: [Discuss-gnuradio] Regarding usrp b200mini

[Marcus D. Leech]

On 06/20/2018 02:17 PM, Sai Parepalli Laxman wrote:

Hey guys,

I am fairly new to gnuradio companion but I was trying to use the UHD: 
USRP source block in the environment with my usrp b200mini but it does 
not show up.


How do I verify this?
What do I need to put in the device address?

-> uhd_find_devices and uhd_usrp_probe are able to load the image and 
the device correctly.


Thanks in advance.


You mean the block doesn't show up in Gnu Radio?

If so, that means your local instance of Gnu Radio was built without UHD 
support.  How was it built?




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

Re: [Discuss-gnuradio] Regarding usrp b200mini

[Marcus D. Leech]

On 06/20/2018 03:13 PM, Sai Parepalli Laxman wrote:

Yes, I will refer that.

I am trying to decode the P25 signal using b200mini on ubuntu 16.04 
using gnuradio.


I have the P25 receiver(demodulator + receiver) open source code 
compiled and running but how do I make it work with usrp b200mini?


How would I go about that?

I'm sorry if I am vague but I am ready to provide additional details.

Thanks
There's probably an e-mail list devoted specifically to that 
software--you might try there.






On Wed, Jun 20, 2018 at 3:00 PM, Marcus D. Leech > wrote:


On 06/20/2018 02:55 PM, Sai Parepalli Laxman wrote:

The device address should be entered as the one that shows up
when I command uhd_find_devices?

This shows up when I run uhd_find_devices

UHD Device 0

Device Address:
serial: 31216B8
name:B200mini
type: b200

Thanks for your time

https://files.ettus.com/manual/page_identification.html


In your case:

type=b200

Will work, but I suggest spending some time with the online UHD
manual, and the Ettus Knowledge base:

https://kb.ettus.com/Knowledge_Base





On Wed, Jun 20, 2018 at 2:51 PM, Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 06/20/2018 02:40 PM, Sai Parepalli Laxman wrote:

Both Gnuradio and UHD support was build from source code
with all dependencies. The block shows up but I am not able
to run the flow graph?
What does "not able to run the flow-graph" mean, precisely?  
We can only help you if we have details and "it doesn't work"

is too hand-wavy
  to provide adequate assistance.



Does GNURadio companion identify the device?

What do you mean by "identify the device".   There's a
"device address" field in any UHD source/sink.   It must be
filled out to tell it what
  UHD device you'd like your flow-graph to talk to.  You
could have more than one on a system, and there are many
different types of
  USRP devices.  UHD (and by inference, Gnu Radio) has no way
of knowing what your intention is.  You have to tell it.




On Wed, Jun 20, 2018 at 2:35 PM, Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 06/20/2018 02:17 PM, Sai Parepalli Laxman wrote:

Hey guys,

I am fairly new to gnuradio companion but I was
trying to use the UHD: USRP source block in the
environment with my usrp b200mini but it does not
show up.

How do I verify this?
What do I need to put in the device address?

-> uhd_find_devices and uhd_usrp_probe are able to
load the image and the device correctly.

Thanks in advance.

You mean the block doesn't show up in Gnu Radio?

If so, that means your local instance of Gnu Radio was
built without UHD support.  How was it built?



___
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] DVB-S2/X Block Party at GNU Radio Conference 2018

[Michelle Thompson]

Hello everyone,

GNU Radio Conference is coming up in September. If you haven't registered
and want to go, please do at https://www.gnuradio.org/grcon-2018/

There's a special event this year called Block Party.

It's an effort to get DVB-S2 and DVB-S2X receivers in GNU Radio.

We will have our own room and tables and swag. We will have docents
enthusiasm and test equipment. We're looking for more! We'll have
documentation and refreshments.

We need blocks!

Most blocks needed for DVB-S2/X receive do, in some form, already exist.
Some do not. Some just need additional modulation and codings added to
them.

Receiver design is hard, but breaking it up into small blocks makes it
tractable.

The DVB protocol documents are all open. There are implementation
guidelines. See https://www.dvb.org/

There are several community members that are experts in this area. There is
a team (Phase 4 Ground - find out more at https://phase4ground.github.io/)
that needs DVB-S2/X to work in GNU Radio. There is a lot of interest from a
variety of other groups including Libre Space, ARRL, AMSAT, and TAPR.

If you are able to contribute to this effort, I want to know about it! I am
here to support it. I'd like nothing better than to complete the Block
Party at GNU Radio Conference with working, tested, documented blocks for a
DVB-S2/X receiver. This contribution makes our open source terrestrial and
space radio designs for Phase 4 Ground possible, and also opens up a lot of
other work.

The thing that is considered the hardest part is the LDPC FEC decode. We
have an open source implementation that targets GPUs. We want to take this
and get it into RFNoC. If you are working on this as well, we want to
collaborate and support and combine and promote.

The GPU implementation (by Charles Brain G4GUO) of LDPC decode can be found
at our repository folder here:
https://github.com/phase4ground/DVB-receiver/tree/master/G4GUO-LDPC-on-GPU/DVB-S2XTxRx

Phase 4 Ground is devoted to an open source implementation of DVB-S2 and
DVB-S2X for amateur radio terrestrial and space use. We are part of Open
Research Institute. Learn more about this non-profit here:
https://openresearch.institute/

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

Re: [Discuss-gnuradio] Help on gnuradio

[Julian Arnold]

Hey,

I had the same problem a few weeks back in a two channel scenario.
I ended up writing a simple python 'gate' block that passes a 
configurable amount of samples for every pulse on the trigger input.


It is super inflexible and hacky but should be fairly easy to modify.

I quickly moved the block to it's own OOT module. You can find it here:
https://github.com/jarn0ld/gr-gate

Let me know if you need any help modifying it.

Cheers,
Julian

On 20.06.2018 20:02, Marcus D. Leech wrote:

On 06/20/2018 01:05 PM, c...@origosat.com wrote:
Hi, I am new to the gnuradio environment..so please forgive me... I 
have an USRP B200 and I am looking to save to a file I & Q samples of 
bursty, random (ALOHA) messages sampled at high rate, for furter 
processing (in a repeatable fashion). Of course it is not possible to 
save 15--20 mminutes of data at 50MSPS, but using something like a 
"valve" (deprecated in GRC) it vould be possible:

1) to detect in real time the burst data transmission
2) to open the valve towards a file sink
A separate file could be used to record timestamp and/or length of 
data blocks recorded


Looking at  GRC I haven't found any useable block to build a valve 
used at run time based on a threshold (e.g. output of a filter to 
detect the TX random signal) . Could anybody help?

Thanks a lot


Here's a "trick".

Have your threshold detector switch the output of the file sink between 
/dev/null and an actual file.


There's also power squelch, which can either insert zeros, or act as a 
"gate".






___
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] DVB-S2/X Block Party at GNU Radio Conference 2018

[Dan CaJacob]

I'd suggest incorporating RFNOC at least as an option. I suspect actual use
of DVBS2X might be rather boring if you're stuck on a processor.

On Wed, Jun 20, 2018 at 4:38 PM Michelle Thompson <
mountain.miche...@gmail.com> wrote:

> Hello everyone,
>
> GNU Radio Conference is coming up in September. If you haven't registered
> and want to go, please do at https://www.gnuradio.org/grcon-2018/
>
> There's a special event this year called Block Party.
>
> It's an effort to get DVB-S2 and DVB-S2X receivers in GNU Radio.
>
> We will have our own room and tables and swag. We will have docents
> enthusiasm and test equipment. We're looking for more! We'll have
> documentation and refreshments.
>
> We need blocks!
>
> Most blocks needed for DVB-S2/X receive do, in some form, already exist.
> Some do not. Some just need additional modulation and codings added to
> them.
>
> Receiver design is hard, but breaking it up into small blocks makes it
> tractable.
>
> The DVB protocol documents are all open. There are implementation
> guidelines. See https://www.dvb.org/
>
> There are several community members that are experts in this area. There
> is a team (Phase 4 Ground - find out more at
> https://phase4ground.github.io/) that needs DVB-S2/X to work in GNU
> Radio. There is a lot of interest from a variety of other groups including
> Libre Space, ARRL, AMSAT, and TAPR.
>
> If you are able to contribute to this effort, I want to know about it! I
> am here to support it. I'd like nothing better than to complete the Block
> Party at GNU Radio Conference with working, tested, documented blocks for a
> DVB-S2/X receiver. This contribution makes our open source terrestrial and
> space radio designs for Phase 4 Ground possible, and also opens up a lot of
> other work.
>
> The thing that is considered the hardest part is the LDPC FEC decode. We
> have an open source implementation that targets GPUs. We want to take this
> and get it into RFNoC. If you are working on this as well, we want to
> collaborate and support and combine and promote.
>
> The GPU implementation (by Charles Brain G4GUO) of LDPC decode can be
> found at our repository folder here:
> https://github.com/phase4ground/DVB-receiver/tree/master/G4GUO-LDPC-on-GPU/DVB-S2XTxRx
>
> Phase 4 Ground is devoted to an open source implementation of DVB-S2 and
> DVB-S2X for amateur radio terrestrial and space use. We are part of Open
> Research Institute. Learn more about this non-profit here:
> https://openresearch.institute/
>
> -Michelle W5NYV
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

[Discuss-gnuradio] [UHD] Python API

[Martin Braun]

Hi all,

after a while of testing and gathering feedback, we have merged the UHD
Python API into master branch. In general, we are happy with its state,
but that doesn't mean it's perfect and complete.

First off, there's at least one known issue with the Python API: It does
not build on Windows. We will work on fixing this issue, but from what
we know it might require specific versions of Python and Boost.Python to
work.

The other major item is that it's not all that well documented. However,
the Python API matches the C++ API closely (albeit with some additions,
some more Pythonic structures, and PEP8-compliant object names). For
now, I recommend reading the examples in host/examples/python/*.py as a
reference. We will also start using Python more and more for testing
utilities, and merge those into the UHD repository as a reference.

We received a lot of valuable feedback from the community, which we very
much appreciated, and have fed back into the development of the API. One
of the concerns was *streaming performance*, and we're happy to say that
we can get pretty decent performance, almost matching the C++
performance (tested with our own benchmark_rate.py utility), even in
full-duplex and multi-channel situations (thanks to various users
pointing us the right way with respect to releasing the GIL!). Getting
high performance in Python is still hard, though. If you wanted to write
a continuous streaming application with high performance, you'd need to
maintain a buffer pool and rotate buffers; in benchmark_rate.py we get
away with a single buffer that we re-use. However, this is obviously
something that Python developers will be aware of, and if you need
highest performance, the Python API is probably not what you want anyway.

To enable the Python API, you need Boost.Python installed, and compile
UHD with the -DENABLE_PYTHON_API=ON switch.
Both Python2 and Python3 are supported, although we've found that CMake
isn't always cooperative in finding the correct libraries when using
Python3. Because the two versions of Python are so fundamentally
different, you need to specify -DENABLE_PYTHON3 if you want to use Py3k.
Boost.Python is also not currently packaged for a range of
distributions, so we assume that if you want Boost.Python + Python3 you
are familiar with more advanced settings.

We think the Python API will enable a range of new applications for
simple tasks, since it's very easy to grab a range of samples and then
do some basic DSP using SciPy and NumPy, plot them using Matplotlib, or
pass it to one of million of other Python libraries out there. Consider
the length of this file:
https://github.com/EttusResearch/uhddev/blob/master/host/examples/python/rx_to_file.py
...we think it's pretty short for what it does.

For continuous streaming and Python, we still recommend using GNU Radio.
gr-uhd also has a (different) Python API that is tied into GNU Radio,
and it is possible to write blocks in GNU Radio, but you won't have to
futz with buffers as mentioned above, and you still have access to all
the blocks written in C++.

Cheers all!

Martin

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

[Discuss-gnuradio] Project Call Tomorrow!

[Martin Braun]

Hi all,

there's another project call coming tomorrow 10 AM Pacific, or 19:00 EU
time. I'll send out coordinates closer to the call, if you want to join,
come to #gnuradio on Freenode or Slack.

Cheers,
Martin

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

[Discuss-gnuradio] ImportError: No module named 'gnuradio'

[evans ryanada]

i am trying to run a .py file generated from GRC 3.7.11 but am getting an
error...displaying the following message..

C:\Users\production\Desktop\flexsdr>gps-sdr-sim-uhd.py
Traceback (most recent call last):
  File "C:\Users\production\Desktop\flexsdr\gps-sdr-sim-uhd.py", line 6, in

from gnuradio import blocks
ImportError: No module named 'gnuradio'

i have installed python 2.7.15 on my pc which runs on windows 8

what could be the problem?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio