Re: UHD function to determine USB version?

[Gilad Beeri (ApolloShield)]

Not through UHD, but on Linux you can run "lsusb -d2500: -v | grep bcdUSB"

Regards,

Gilad Beeri
CTO, ApolloShield Anti-Drone Systems
www.apolloshield.com
gi...@apolloshield.com

ᐧ

On Fri, Aug 27, 2021 at 9:51 PM Mike  wrote:

> Hello,
>
> I apologize if I missed it in the documentation, but is there a UHD
> function that will return the USB version (e.g. USB 2 or USB 3) that the
> USRP is using?
>
> I'm using a B200 in a custom C++ program and would like to
> programmatically verify the USB connection speed before attempting high
> rate sampling.
>
>
> Thanks!
>
>
>
>

Re: Weird Python Sinks Crash with GNU Radio 3.8.1

[Gilad Beeri (ApolloShield)]

Hi,
Can someone with GNU Radio 3.8.1 and Python 3.8 on Linux run the attached
file and check if it crashes?

I get persistent results over several computers for a crash on that setup,
while it is ok on Python 2.7 and GNU Radio 3.7.11.

ᐧ

On Sun, Apr 26, 2020 at 11:19 AM Gilad Beeri (ApolloShield) <
gi...@apolloshield.com> wrote:

> Hi,
> I succeeded in narrowing down the flowgraph to a minimal graph that
> reproduces the issue. You can see the Python file attached.
>
> Basically, when having a file source that feeds 2 different Null Python
> Sinks", the process crashes with a seg fault, with the same stack trace I
> showed before:
>
> *include/gnuradio/py_feval.h:69* which is *py_eval_ll::calleval(int)*:
> *return eval(x);*
>
> The flowgraph is very simple:
> File Source -> Python Null Sink - 2 times
>
> Replacing one of the Null Python Sinks to a standard Null Sink "solves"
> the issue - the crash doesn't reproduce. You can comment-in line 43 and
> comment-out line 44 to witness that.
> I used the same file source block but I also tested it with 2 different
> file sources and it behaves the same.
>
> Any ideas why does this happen in GNU Radio 3.8.1?
>
> ᐧ
>
> On Thu, Apr 23, 2020 at 6:50 PM Gilad Beeri (ApolloShield) <
> gi...@apolloshield.com> wrote:
>
>> I have a rather complex flowgraph that used to work well with GNU Radio
>> 3.7.
>> I upgraded to 3.8.1, and now it crashes (for some input, but even when I
>> use /dev/zero as file source) with something that looks like in the core of
>> GNU Radio (not directly in the block).
>>
>> Environment:
>> GNU Radio 3.8.1
>> Python 3.8.2
>> Ubuntu 16.04.6
>>
>> There are many blocks, but let's focus on the last ones.
>> I have a float-to-int block (the standard one) which feeds data into a
>> sink block that is written in Python. In case it is relevant, this is the
>> block that feeds the sink: *float_to_int =
>> blocks.float_to_int(); self.connect(float_to_int, sink)*
>>
>> The process crashes with a segmentation fault.
>>
>> If I nullify the Python sink (commenting out all real processing code in
>> work()), the issue still happens.
>> Furthermore, I wrote a "my_null_sink" block in Python (see code below).
>> It still crashes with the same issue (after I connected it to the
>> float-to-int output instead of the original Python sink).
>> When I replace "my_null_sink" with GNU Radio's standard Null Sink, it
>> doesn't crash anymore.
>> Using the same input file and my_null_sink, it crashes about 95% of the
>> runs (i.e., not 100%, but almost always), with Null Sink, 0%.
>> That's why I believe it is something with the Python binding. I do have
>> other Python blocks in the flowgraph (one that is connected to the file
>> source and does some simple processing before passing forward the samples).
>>
>> When I run it with gdb, I catch the exception and the stack trace is
>> below.
>> The 2nd frame in the stack sends us to *block_gateway_impl.cc:139*,
>> work(),
>> *_handler->calleval(0);*
>> The 1st stack frame doesn't have an associated module for the specified
>> address (0x02324b90 in ??), "i sh" shows it isn't associated with
>> any module, and "info symbol " confirms this. I also witness that all
>> modules are loaded into addresses > 0x7f13, so I assume the
>> address from the stack trace is really not a valid library, but some
>> garbage (it's also very close to 0).
>> The faulty memory address tends to change which is another indication for
>> garbage.
>>
>> Note: when I build the app in Debug, another stack frame appears between
>> the one that isn't associated with a module, to the one in
>> block_gateway_impl:
>> *include/gnuradio/py_feval.h:69* which is *py_eval_ll::calleval(int)*:
>> *return eval(x);*
>>
>> When I implement the simplest flowgraph: File Source with /dev/zero ->
>> Throttle -> my_null_sink, it doesn't crash.
>>
>> In the original flowgraph, I disabled almost all blocks, and
>> specifically, I did not leave any enabled own C++ block - just to rule out
>> the possibility that one of the blocks corrupts the memory. It didn't
>> change anything.
>>
>> I tested it on another machine with a similar setup (GNU Radio 3.8.1) and
>> it reproduced. On an older machine, still with GNU Radio 3.7.11.1, it works
>> (doesn't crash).
>>
>> Any ideas will be appreciated.
>> --
>>
>> *my_null_sink.py*
>>
>>
>>
>>
>>
>>
>&g

Re: Weird Python Sinks Crash with GNU Radio 3.8.1

[Gilad Beeri (ApolloShield)]

Hi,
I succeeded in narrowing down the flowgraph to a minimal graph that
reproduces the issue. You can see the Python file attached.

Basically, when having a file source that feeds 2 different Null Python
Sinks", the process crashes with a seg fault, with the same stack trace I
showed before:

*include/gnuradio/py_feval.h:69* which is *py_eval_ll::calleval(int)*:
*return eval(x);*

The flowgraph is very simple:
File Source -> Python Null Sink - 2 times

Replacing one of the Null Python Sinks to a standard Null Sink "solves" the
issue - the crash doesn't reproduce. You can comment-in line 43 and
comment-out line 44 to witness that.
I used the same file source block but I also tested it with 2 different
file sources and it behaves the same.

Any ideas why does this happen in GNU Radio 3.8.1?

ᐧ

On Thu, Apr 23, 2020 at 6:50 PM Gilad Beeri (ApolloShield) <
gi...@apolloshield.com> wrote:

> I have a rather complex flowgraph that used to work well with GNU Radio
> 3.7.
> I upgraded to 3.8.1, and now it crashes (for some input, but even when I
> use /dev/zero as file source) with something that looks like in the core of
> GNU Radio (not directly in the block).
>
> Environment:
> GNU Radio 3.8.1
> Python 3.8.2
> Ubuntu 16.04.6
>
> There are many blocks, but let's focus on the last ones.
> I have a float-to-int block (the standard one) which feeds data into a
> sink block that is written in Python. In case it is relevant, this is the
> block that feeds the sink: *float_to_int =
> blocks.float_to_int(); self.connect(float_to_int, sink)*
>
> The process crashes with a segmentation fault.
>
> If I nullify the Python sink (commenting out all real processing code in
> work()), the issue still happens.
> Furthermore, I wrote a "my_null_sink" block in Python (see code below). It
> still crashes with the same issue (after I connected it to the float-to-int
> output instead of the original Python sink).
> When I replace "my_null_sink" with GNU Radio's standard Null Sink, it
> doesn't crash anymore.
> Using the same input file and my_null_sink, it crashes about 95% of the
> runs (i.e., not 100%, but almost always), with Null Sink, 0%.
> That's why I believe it is something with the Python binding. I do have
> other Python blocks in the flowgraph (one that is connected to the file
> source and does some simple processing before passing forward the samples).
>
> When I run it with gdb, I catch the exception and the stack trace is below.
> The 2nd frame in the stack sends us to *block_gateway_impl.cc:139*,
> work(),
> *_handler->calleval(0);*
> The 1st stack frame doesn't have an associated module for the specified
> address (0x02324b90 in ??), "i sh" shows it isn't associated with
> any module, and "info symbol " confirms this. I also witness that all
> modules are loaded into addresses > 0x7f13, so I assume the
> address from the stack trace is really not a valid library, but some
> garbage (it's also very close to 0).
> The faulty memory address tends to change which is another indication for
> garbage.
>
> Note: when I build the app in Debug, another stack frame appears between
> the one that isn't associated with a module, to the one in
> block_gateway_impl:
> *include/gnuradio/py_feval.h:69* which is *py_eval_ll::calleval(int)*:
> *return eval(x);*
>
> When I implement the simplest flowgraph: File Source with /dev/zero ->
> Throttle -> my_null_sink, it doesn't crash.
>
> In the original flowgraph, I disabled almost all blocks, and specifically,
> I did not leave any enabled own C++ block - just to rule out the
> possibility that one of the blocks corrupts the memory. It didn't change
> anything.
>
> I tested it on another machine with a similar setup (GNU Radio 3.8.1) and
> it reproduced. On an older machine, still with GNU Radio 3.7.11.1, it works
> (doesn't crash).
>
> Any ideas will be appreciated.
> --
>
> *my_null_sink.py*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *import numpyfrom gnuradio import grclass my_null_sink(gr.sync_block):
> def __init__(self):gr.sync_block.__init__(self,
> name="my_null_sink",in_sig=[numpy.int32],
> out_sig=None)print('* my_null_sink init')def work(self,
> input_items, output_items):return len(input_items[0])*
>
>
> *Exception in GDB*
>
>
> *Thread 20 "my_null_sink25" received signal SIGSEGV, Segmentation fault*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *#0  0x02324b90 in ?? ()#1  0x7f5ec43df433 in
> gr::block_gateway_impl::work (this=this@entry=0x2324fc

Weird Python Sinks Crash with GNU Radio 3.8.1

[Gilad Beeri (ApolloShield)]

I have a rather complex flowgraph that used to work well with GNU Radio 3.7.
I upgraded to 3.8.1, and now it crashes (for some input, but even when I
use /dev/zero as file source) with something that looks like in the core of
GNU Radio (not directly in the block).

Environment:
GNU Radio 3.8.1
Python 3.8.2
Ubuntu 16.04.6

There are many blocks, but let's focus on the last ones.
I have a float-to-int block (the standard one) which feeds data into a sink
block that is written in Python. In case it is relevant, this is the block
that feeds the sink: *float_to_int =
blocks.float_to_int(); self.connect(float_to_int, sink)*

The process crashes with a segmentation fault.

If I nullify the Python sink (commenting out all real processing code in
work()), the issue still happens.
Furthermore, I wrote a "my_null_sink" block in Python (see code below). It
still crashes with the same issue (after I connected it to the float-to-int
output instead of the original Python sink).
When I replace "my_null_sink" with GNU Radio's standard Null Sink, it
doesn't crash anymore.
Using the same input file and my_null_sink, it crashes about 95% of the
runs (i.e., not 100%, but almost always), with Null Sink, 0%.
That's why I believe it is something with the Python binding. I do have
other Python blocks in the flowgraph (one that is connected to the file
source and does some simple processing before passing forward the samples).

When I run it with gdb, I catch the exception and the stack trace is below.
The 2nd frame in the stack sends us to *block_gateway_impl.cc:139*, work(),
*_handler->calleval(0);*
The 1st stack frame doesn't have an associated module for the specified
address (0x02324b90 in ??), "i sh" shows it isn't associated with
any module, and "info symbol " confirms this. I also witness that all
modules are loaded into addresses > 0x7f13, so I assume the
address from the stack trace is really not a valid library, but some
garbage (it's also very close to 0).
The faulty memory address tends to change which is another indication for
garbage.

Note: when I build the app in Debug, another stack frame appears between
the one that isn't associated with a module, to the one in
block_gateway_impl:
*include/gnuradio/py_feval.h:69* which is *py_eval_ll::calleval(int)*:
*return eval(x);*

When I implement the simplest flowgraph: File Source with /dev/zero ->
Throttle -> my_null_sink, it doesn't crash.

In the original flowgraph, I disabled almost all blocks, and specifically,
I did not leave any enabled own C++ block - just to rule out the
possibility that one of the blocks corrupts the memory. It didn't change
anything.

I tested it on another machine with a similar setup (GNU Radio 3.8.1) and
it reproduced. On an older machine, still with GNU Radio 3.7.11.1, it works
(doesn't crash).

Any ideas will be appreciated.
--

*my_null_sink.py*















*import numpyfrom gnuradio import grclass my_null_sink(gr.sync_block):
def __init__(self):gr.sync_block.__init__(self,
name="my_null_sink",in_sig=[numpy.int32],
out_sig=None)print('* my_null_sink init')def work(self,
input_items, output_items):return len(input_items[0])*


*Exception in GDB*


*Thread 20 "my_null_sink25" received signal SIGSEGV, Segmentation fault*





















*#0  0x02324b90 in ?? ()#1  0x7f5ec43df433 in
gr::block_gateway_impl::work (this=this@entry=0x2324fc0, noutput_items=8,
  input_items=std::vector of length 1, capacity 1 = {...},
output_items=std::vector of length 0, capacity 0)at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/block_gateway_impl.cc:139#2
 0x7f5ec43df471 in gr::block_gateway_impl::general_work
(this=0x2324fc0, noutput_items=, ninput_items=...,
input_items=std::vector of length 1, capacity 1 = {...}, output_items=...)
  at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/block_gateway_impl.cc:121#3
 0x7f5ec43dc4c4 in gr::block_executor::run_one_iteration
(this=this@entry=0x7f5e71ffadf0)at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/block_executor.cc:514#4
 0x7f5ec4439097 in gr::tpb_thread_body::tpb_thread_body
(this=0x7f5e71ffadf0, block=..., start_sync=...,
max_noutput_items=) at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122#5
 0x7f5ec4428932 in gr::tpb_container::operator() (this=0x2ab6640)at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:50#6
 gr::thread::thread_body_wrapper::operator()
(this=0x2ab6640)at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/../include/gnuradio/thread/thread_body_wrapper.h:52#7
 
boost::detail::function::void_function_obj_invoker0,
void>::invoke (function_obj_ptr=...)at
/usr/include/boost/function/function_template.hpp:159#8  0x7f5ec260
in boost::function0::operator() (this=) at
/usr/include/boost/function/function_template.hpp:773#9
 boost::detail::thread_data const>::run
(this=) at

Re: GNU Radio 3.8 OOT Linking (Migration from 3.7)

[Gilad Beeri (ApolloShield)]

Hi Andrej,
Thank you - that seems to solve the issue.

ᐧ

On Tue, Apr 21, 2020 at 6:06 PM Andrej Rode  wrote:

> Hi,
>
> as a quite big difference to GNU Radio 3.7 the CMake does not set up
> your project to blindly link to all of the GNU Radio libraries but you
> have to also add in  `lib/CMakelists.txt` a
> `target_link_library($my_oot_library gnuradio::gnuradio-filter)` to
> link to gr-filter symbols.
>
> The inital selection of components in `find_package` just limits the
> list of imported CMake targets and thus the available components you
> can ultimatively link to.
>
> Cheers
> Andrej
>

GNU Radio 3.8 OOT Linking (Migration from 3.7)

[Gilad Beeri (ApolloShield)]

I'm migrating an OOT module from GNU Radio 3.7 to 3.8.1.
I followed the instructions on
https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide.

When running my app, I get:

*ImportError: /home/myuser/gr/as/lib/libgnuradio-myproject.so.1.0.0git:
undefined symbol:
_ZN2gr6filter6kernel14fft_filter_cccC1EiRKSt6vectorISt7complexIfESaIS5_EEi*

And verifying with ldd, I see libgnuradio-filter does not exist at the
dependency list of the compiled .so.

In *myproject/CMakeLists.txt*,
I have:





*find_package(Gnuradio "3.8" REQUIRED COMPONENTS blocks fft filter)#make
sure our local CMake Modules path comes firstlist(INSERT CMAKE_MODULE_PATH
0 ${CMAKE_SOURCE_DIR}/cmake/Modules)include(GrVersion)*

The same source code worked in GNU Radio 3.8 where the CMakeLists.txt file
contained:



*set(GR_REQUIRED_COMPONENTS RUNTIME FILTER)find_package(Gnuradio "3.7.2"
REQUIRED)list(INSERT CMAKE_MODULE_PATH 0
${CMAKE_SOURCE_DIR}/cmake/Modules)include(GrVersion)*

And the compiled .so file indeed referred to libgnuradio-filter.

I assume there's some mistake in the CMakeLists.txt file that causes the
compiled shared object not to link to libgnuradio-filter, but the above is
based on the module porting guide, so any pointer will be appreciated.
ᐧ

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)  > > <mailto:muel...@kit.edu>> 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:
> > &

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

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

[Gilad Beeri (ApolloShield)]

Which version of gnuradio works for you now?

On Tue, Jun 19, 2018 at 5:22 PM Ralph A. Schmid, dk5ras 
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

Re: [Discuss-gnuradio] Error Linking UHD

[Gilad Beeri (ApolloShield)]

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) 
> 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:
> [lib

Re: [Discuss-gnuradio] Error Linking UHD

[Gilad Beeri (ApolloShield)]

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

[Discuss-gnuradio] Error Linking UHD

[Gilad Beeri (ApolloShield)]

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

Re: [Discuss-gnuradio] Flowgraph heartbeat pulse

[Gilad Beeri (ApolloShield)]

Thanks for the Throttle insights :)

If there's a hardware source in the flowgraph, maybe he can leverage the
source's clock, and use source -> Keep 1 in N -> sink?
Or write a custom UDP sink that connects directly to the source, and
implements some kind of "Send 1 for every N items" internally?

On Sun, Apr 1, 2018 at 2:16 PM Müller, Marcus (CEL) <muel...@kit.edu> wrote:

> Be a bit careful there, Throttle doesn't work like that!
> Throttle will sleep for as long as it takes to pass the number of input
> items it sees.
>
> For example, if you connected
>
> Constant Source(1) -> Throttle (1 S/s) -> UDP Sink
>
> Then, on start of the flow graph, "constant source" will produce e.g.
> 4096 items, and then Throttle's work will be called with these 4096
> items. Throttle then calculates #input_items/sample_rate = 4096s and
> sleep, for more than an hour, then signal it's finished copying thes
> 4096 items to the output. This is everything but a usable watchdog!
>
> Frankly, I know (very, very well) that GNU Radio isn't bug-free.
> But if your flow graph occasionally breaks, then you need to fix that,
> and not only try to figure out when that happens. This is especially
> hard in GNU Radio, since all blocks run in different threads, and a
> disjunkt watchdog subgraph might just as well continue running after
> your main graph has ceased to function.
>
> I interpret your "sometimes values are missing" as "but then it
> continues working normally afterwards". I'm certain that means your
> flow graph is *not* crashing, because then it wouldn't continue working
> normally after. What might happen is that some step or external factor
> needs to much resources of your computer, and then the real time
> processing of your input data (wherever that comes from!) can't be
> sustained, leading to your external data source (SDR device?) having to
>  drop samples. But then you'll need to debug your computation and
> computational system to make it sufficienly reliable at not consuming
> more time to do whatever you do to the signal than it takes to produce
> the signal!
>
> Vitals are still a good idea, but sadly, I don't have a standard way of
> doing them.
>
> Best regards,
> Marcus
>
> On Sun, 2018-04-01 at 04:20 +, Gilad Beeri (ApolloShield) wrote:
> > Might work for you:
> > Any kind of source, throttled to 1/HEARTBIT_INTERVAL, to a UDP sink.
> > Example:
> > Constant Source(1) -> Throttle (1 S/s) -> UDP Sink
> > will write the number 1 to the designated UDP sink, once every
> > second.
> >
> >
> > On Sun, Apr 1, 2018 at 12:22 AM Milos Milosavljevic  > v...@spire.com> wrote:
> > > Hi All,
> > >
> > > I was wondering if someone can give me some hints on the below
> > > please.
> > >
> > > I have a flowgraph running continuously demodulating some off air
> > > signals and spitting out meta data about the parameters, calculated
> > > SNRs, BER, freq offset estimations, etc. That meta and output data
> > > is parsed regularly and saved to a database.
> > >
> > > However, sometimes it is either meta missing or data or both. I am
> > > convinced that the flowgraph either stalls or crashes. I need to
> > > capture it where exactly but first I want to develop a tool to
> > > monitor the flowgraph to now when it crashed or hanged.
> > >
> > > So I want to add a hearbeat somewhere which I can monitor and know
> > > exactly that it is not running anymore. Does anybody have any ideas
> > > of what would be the best way to do it? Can I use something from
> > > the library for this?
> > >
> > > Any suggestions will be appreciated.
> > >
> > > Many thanks,
> > > Milos
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Flowgraph heartbeat pulse

[Gilad Beeri (ApolloShield)]

Might work for you:
Any kind of source, throttled to 1/HEARTBIT_INTERVAL, to a UDP sink.
Example:
Constant Source(1) -> Throttle (1 S/s) -> UDP Sink
will write the number 1 to the designated UDP sink, once every second.


On Sun, Apr 1, 2018 at 12:22 AM Milos Milosavljevic <
milos.milosavlje...@spire.com> wrote:

> Hi All,
>
> I was wondering if someone can give me some hints on the below please.
>
> I have a flowgraph running continuously demodulating some off air signals
> and spitting out meta data about the parameters, calculated SNRs, BER, freq
> offset estimations, etc. That meta and output data is parsed regularly and
> saved to a database.
>
> However, sometimes it is either meta missing or data or both. I am
> convinced that the flowgraph either stalls or crashes. I need to capture it
> where exactly but first I want to develop a tool to monitor the flowgraph
> to now when it crashed or hanged.
>
> So I want to add a hearbeat somewhere which I can monitor and know exactly
> that it is not running anymore. Does anybody have any ideas of what would
> be the best way to do it? Can I use something from the library for this?
>
> Any suggestions will be appreciated.
>
> Many thanks,
> Milos
>
> ___
> 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] Avoiding divide by zero in case of input being zero.

[Gilad Beeri (ApolloShield)]

Marcus:

Yes, but he computes a sum of N power figures (for N samples), so for it to
be 0, there should be N consecutive 0 samples, so the statistics are lower.
Looking at the source code, he uses N == 1024.



On Sat, Mar 31, 2018 at 8:28 AM Gilad Beeri (ApolloShield) <
gi...@apolloshield.com> wrote:

> "if x != 0" will be translated to a super-speedy test both in C++ and in
> Python. It is almost guaranteed that your flowgraph bottleneck will be in
> another place. My suggestion will be to just add this if statement and to
> think about it again only if you prove this is a bottleneck you want to
> optimize.
>
> Regarding your flowgraph vs. unit test question, I think you're right (you
> have a flowgraph also in the unit tests).
>
>
> On Sat, Mar 31, 2018 at 8:18 AM Anshul Thakur <anshultha...@rediffmail.com>
> wrote:
>
>> Hi Gilad,
>>
>> You are correct about getting zeros when using history and I am using
>> history. But, I am accounting for that by using the offset:
>>
>> const gr_complex *current = (const gr_complex *)&((const gr_complex
>> *)input_items[0])[(history() -1)];
>>
>> Also, if that is the case, shouldn't the behaviour be consistent across
>> unit-tests and flowgraph usage?
>>
>> Regarding getting 0s from the device, I went through the discussion. I
>> agree to it. So, I'll have to account for the zero values. Any ideas on how
>> to do that?
>>
>> The reason why I don't want to use an 'if' block is simply because the
>> situation of 0 values is expected to share a very small fraction of the
>> entire run and
>> to handle that small case, the regular cases will also necessarily have
>> to go through that additional 'if' check. I wanted to avoid that.
>>
>> Regards,
>> Anshul
>>
>> On 31 March 2018 at 10:37, Gilad Beeri (ApolloShield) <
>> gi...@apolloshield.com> wrote:
>>
>>> Disclosure: I haven't looked at your code.
>>>
>>> 0 values can be presented in GNU Radio when you use history, because if
>>> your history is N, the first N-1 items are going to be zeros.
>>>
>>> Anyway, regarding your comment "it is not expected that a device/stream
>>> would ever spit out zero values.",
>>> I did have 0 values from a USRP device, see discussion in
>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-October/026851.html
>>> .
>>>
>>>
>>>
>>> On Sat, Mar 31, 2018 at 6:52 AM Anshul Thakur <
>>> anshultha...@rediffmail.com> wrote:
>>>
>>>> Michael, Marcus,
>>>>
>>>> Right now, the code is a work in progress so I haven't made a git
>>>> repository out of it. However, I have it on dropbox. Here's the link to the
>>>> source folder(p1_detector_impl.cc is the source in question):
>>>>
>>>> *https://www.dropbox.com/sh/blfmxsaidrkh28t/AAArp8IHavzCGFlJs6E6-Hrca?dl=0
>>>> <https://www.dropbox.com/sh/blfmxsaidrkh28t/AAArp8IHavzCGFlJs6E6-Hrca?dl=0>*
>>>>
>>>> As for Marcus's question regarding why use a circular buffer?
>>>>
>>>> It isn't exactly a circular buffer now, but more of a shift register.
>>>> The reasons are as follows:
>>>> 1. I needed running sums for correlations in B-Branch and C-Branch
>>>> correlators, and Power Sums (for average power) to normalize them. Then, I
>>>> also needed a finite delay buffer to delay the C-Branch before it gets
>>>> multiplied with the B-Branch.
>>>> 2. It kind of carried over from the last implementation attempt:
>>>>
>>>> Assertion: If a peak is detected after the multiplication, the signal
>>>> boundary is 1024 samples behind that index.
>>>>
>>>> Once the correlations crossed a threshold (the code entered state=1), 
>>>> *instead
>>>> of looking back, I then needed to look forward to see if it were a false
>>>> alarm or not*. So, I compute the correlations across all available
>>>> current inputs and try to find a peak. If a peak is found, enter state=3
>>>> where we do a correlation with the carrier distribution sequence after FFT
>>>> of all signals of interest. So, here, I not only needed just the single
>>>> value (the running sum), but the entire state of the delay register and the
>>>> B-Branch correlator.
>>>>
>>>> I hope I am able to convey the reason for implementing one myself.
>>>>
>>>> In the current implementation, I make an assu

Re: [Discuss-gnuradio] Avoiding divide by zero in case of input being zero.

[Gilad Beeri (ApolloShield)]

"if x != 0" will be translated to a super-speedy test both in C++ and in
Python. It is almost guaranteed that your flowgraph bottleneck will be in
another place. My suggestion will be to just add this if statement and to
think about it again only if you prove this is a bottleneck you want to
optimize.

Regarding your flowgraph vs. unit test question, I think you're right (you
have a flowgraph also in the unit tests).

On Sat, Mar 31, 2018 at 8:18 AM Anshul Thakur <anshultha...@rediffmail.com>
wrote:

> Hi Gilad,
>
> You are correct about getting zeros when using history and I am using
> history. But, I am accounting for that by using the offset:
>
> const gr_complex *current = (const gr_complex *)&((const gr_complex
> *)input_items[0])[(history() -1)];
>
> Also, if that is the case, shouldn't the behaviour be consistent across
> unit-tests and flowgraph usage?
>
> Regarding getting 0s from the device, I went through the discussion. I
> agree to it. So, I'll have to account for the zero values. Any ideas on how
> to do that?
>
> The reason why I don't want to use an 'if' block is simply because the
> situation of 0 values is expected to share a very small fraction of the
> entire run and
> to handle that small case, the regular cases will also necessarily have to
> go through that additional 'if' check. I wanted to avoid that.
>
> Regards,
> Anshul
>
> On 31 March 2018 at 10:37, Gilad Beeri (ApolloShield) <
> gi...@apolloshield.com> wrote:
>
>> Disclosure: I haven't looked at your code.
>>
>> 0 values can be presented in GNU Radio when you use history, because if
>> your history is N, the first N-1 items are going to be zeros.
>>
>> Anyway, regarding your comment "it is not expected that a device/stream
>> would ever spit out zero values.",
>> I did have 0 values from a USRP device, see discussion in
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-October/026851.html
>> .
>>
>>
>>
>> On Sat, Mar 31, 2018 at 6:52 AM Anshul Thakur <
>> anshultha...@rediffmail.com> wrote:
>>
>>> Michael, Marcus,
>>>
>>> Right now, the code is a work in progress so I haven't made a git
>>> repository out of it. However, I have it on dropbox. Here's the link to the
>>> source folder(p1_detector_impl.cc is the source in question):
>>>
>>> *https://www.dropbox.com/sh/blfmxsaidrkh28t/AAArp8IHavzCGFlJs6E6-Hrca?dl=0
>>> <https://www.dropbox.com/sh/blfmxsaidrkh28t/AAArp8IHavzCGFlJs6E6-Hrca?dl=0>*
>>>
>>> As for Marcus's question regarding why use a circular buffer?
>>>
>>> It isn't exactly a circular buffer now, but more of a shift register.
>>> The reasons are as follows:
>>> 1. I needed running sums for correlations in B-Branch and C-Branch
>>> correlators, and Power Sums (for average power) to normalize them. Then, I
>>> also needed a finite delay buffer to delay the C-Branch before it gets
>>> multiplied with the B-Branch.
>>> 2. It kind of carried over from the last implementation attempt:
>>>
>>> Assertion: If a peak is detected after the multiplication, the signal
>>> boundary is 1024 samples behind that index.
>>>
>>> Once the correlations crossed a threshold (the code entered state=1), 
>>> *instead
>>> of looking back, I then needed to look forward to see if it were a false
>>> alarm or not*. So, I compute the correlations across all available
>>> current inputs and try to find a peak. If a peak is found, enter state=3
>>> where we do a correlation with the carrier distribution sequence after FFT
>>> of all signals of interest. So, here, I not only needed just the single
>>> value (the running sum), but the entire state of the delay register and the
>>> B-Branch correlator.
>>>
>>> I hope I am able to convey the reason for implementing one myself.
>>>
>>> In the current implementation, I make an assumption that the threshold
>>> is so high that only the desired signals would cross it (100-150 times the
>>> average). So I skip the state=1 logic and directly go into state=2 logic of
>>> aggressively doing a FFT and correlation with the CDS.
>>>
>>> However, I don't think this has a binding on the incoming values. Use of
>>> buffers is internal to the implementation, I am just printing out the
>>> current values as they arrive.
>>>
>>> For example, when I use the test file in 'make test', the values fed in
>>> are non-zero from t=1. However, when using gnuradio-companion, t=56 line is
>

Re: [Discuss-gnuradio] Avoiding divide by zero in case of input being zero.

[Gilad Beeri (ApolloShield)]

Disclosure: I haven't looked at your code.

0 values can be presented in GNU Radio when you use history, because if
your history is N, the first N-1 items are going to be zeros.

Anyway, regarding your comment "it is not expected that a device/stream
would ever spit out zero values.",
I did have 0 values from a USRP device, see discussion in
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-October/026851.html
.



On Sat, Mar 31, 2018 at 6:52 AM Anshul Thakur 
wrote:

> Michael, Marcus,
>
> Right now, the code is a work in progress so I haven't made a git
> repository out of it. However, I have it on dropbox. Here's the link to the
> source folder(p1_detector_impl.cc is the source in question):
>
> *https://www.dropbox.com/sh/blfmxsaidrkh28t/AAArp8IHavzCGFlJs6E6-Hrca?dl=0
> *
>
> As for Marcus's question regarding why use a circular buffer?
>
> It isn't exactly a circular buffer now, but more of a shift register. The
> reasons are as follows:
> 1. I needed running sums for correlations in B-Branch and C-Branch
> correlators, and Power Sums (for average power) to normalize them. Then, I
> also needed a finite delay buffer to delay the C-Branch before it gets
> multiplied with the B-Branch.
> 2. It kind of carried over from the last implementation attempt:
>
> Assertion: If a peak is detected after the multiplication, the signal
> boundary is 1024 samples behind that index.
>
> Once the correlations crossed a threshold (the code entered state=1), *instead
> of looking back, I then needed to look forward to see if it were a false
> alarm or not*. So, I compute the correlations across all available
> current inputs and try to find a peak. If a peak is found, enter state=3
> where we do a correlation with the carrier distribution sequence after FFT
> of all signals of interest. So, here, I not only needed just the single
> value (the running sum), but the entire state of the delay register and the
> B-Branch correlator.
>
> I hope I am able to convey the reason for implementing one myself.
>
> In the current implementation, I make an assumption that the threshold is
> so high that only the desired signals would cross it (100-150 times the
> average). So I skip the state=1 logic and directly go into state=2 logic of
> aggressively doing a FFT and correlation with the CDS.
>
> However, I don't think this has a binding on the incoming values. Use of
> buffers is internal to the implementation, I am just printing out the
> current values as they arrive.
>
> For example, when I use the test file in 'make test', the values fed in
> are non-zero from t=1. However, when using gnuradio-companion, t=56 line is
> where the file source starts yielding proper inputs to my block. The stdout
> prints of the initial values in both GRC and make tests are attached. The
> gnuradio-companion version has my first 55 samples zeroed and the 56th
> input onward is then same for both.
>
>
> P.S.: The source stream is a 1.2 Gigs file, so haven't uploaded it. If
> you'd like I can do that too. It was generated by using a DVB-T2 Tx block
> and writing the output into a file sink.
>
> Warm regards,
> Anshul Thakur
>
> On 31 March 2018 at 02:27, Müller, Marcus (CEL)  wrote:
>
>> Hi Anshul,
>>
>> you shouldn't have to have your own buffer for a running sum – can you
>> explain why you're doing that?
>> A running sum can trivially be implemented with the IIR filter block
>> with Feed-Forward taps (1,) and Feed-back taps (1,0)!
>> Where does in a running sum does a division take place?
>>
>> > (a) Why am I getting the initial zero samples from the file block in
>> > gnuradio_companion and non-zero values when using a vector_source in
>> > unit tests?
>>
>> If these zeros are not in the file you're reading, your block has a
>> bug!
>>
>>
>> > (b) What can I do about it (here specifically as a fix to the
>> > situation, and a general guideline to always remember)?
>>
>> good question, but we'd need to know your code, your motivation for a
>> circular buffer, and why you're implementing a running sum yourself!
>>
>> Best regards,
>> Marcus
>>
>> On Fri, 2018-03-30 at 23:19 +0530, Anshul Thakur wrote:
>> > Hi,
>> >
>> > I used a circular buffer of finite size to keep the past 'N' power
>> > values of the sample stream in my block as a part of creating a
>> > running sum. This buffer is initialized to 0 in the constructor.
>> > The running sum of powers is used to compute the average power used
>> > in computing signal correlation.
>> >
>> > I have a capture stream (cfile) to test the operation of the block.
>> > The test case uses a vector_source_c block to read the contents of
>> > the file into memory. The unit tests pass without error.
>> >
>> > However, when I use the block in a flowgraph in that reads the same
>> > file from a file source block gnuradio_companion, I am getting the
>> > first few sample 

Re: [Discuss-gnuradio] How to stop GRC flowgraph after a defined time

[Gilad Beeri (ApolloShield)]

Check out the Head block, which takes N as input, and stops (the whole
flowgraph as a result of how GNU Radio works) after N samples.
N = sample_rate * desired_duration


On Tue, Mar 27, 2018 at 2:08 PM Priyanka Priyadarshini <
ppriyadarshin...@gmail.com> wrote:

> Hello,
>
> I am very new to GNURadio and I have made a FM radio receiver in which I
> am recording the data in a file sink.
>
> But, I want to record the data for one millisecond(means i want to stop
> the flow graph after 1 millisecond). How can I run the execution of the
> flow graph for this specified time?
>
> Any help would be appreciated. Thank you.
>
> Priyanka
> ___
> 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] GRC: Reference a Block from Other Block

[Gilad Beeri (ApolloShield)]

The method I want to call is thread-safe, and the target block doesn't
support the required message.
Regardless, I only need it for quick prototyping so I don't care at this
stage if this is clean or not. This is an experimental GRC flowgraph for me.
How do you pass a reference to the target block, or to the top block, from
GRC GUI, to my custom block?

On Thu, Mar 22, 2018 at 5:32 PM Johannes Demel <de...@ant.uni-bremen.de>
wrote:

> Hi Gilad,
>
> it is possible to pass references to other blocks to your custom block.
> But you should avoid this implementation. First off, another block is
> scheduled in another thread. This might cause runtime issues.
>
> If you need status information from another block, add a message port
> that outputs this information. Make it useful to everyone and upstream
> your additional functionality.
>
> If you want to update the internal status of another block. Definitely
> use message ports to set internal variables.
>
> Cheers
> Johannes
>
> On 22.03.2018 14:34, Gilad Beeri (ApolloShield) wrote:
> > I have a block I implemented, and I use it inside a GRC flowgraph with
> > many in-tree blocks.
> > I want to reference one of those blocks from my own block (call one of
> > its methods).
> >
> > Is it possible in GRC without manual modification of the generated
> > Python file?
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRC: Reference a Block from Other Block

[Gilad Beeri (ApolloShield)]

I have a block I implemented, and I use it inside a GRC flowgraph with many
in-tree blocks.
I want to reference one of those blocks from my own block (call one of its
methods).

Is it possible in GRC without manual modification of the generated Python
file?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Debugging the Source of Dropped Samples

[Gilad Beeri (ApolloShield)]

Hi Marcus,
Thanks for the detailed answer.
After a long period, I managed to work on it (in several steps) during the
last couple of months.

I managed to find the bottleneck using ControlPorts. It showed a couple of
blocks that were bottlenecks (based on previous block's output buffers).
Interestingly, they weren't IO-bound. I haven't investigated it further,
but I guess that the facts that (i) they caused dropped samples; (ii) were
CPU-bound; and (iii) did not reach anywhere near 100% in htop indicate that
they might have high fluctuations in CPU usage, it might be that they do
use 100% CPU for a very short time (then they cause dropped samples),
shorter than the sampling and averaging periods of tools like htop.
Optimizing those blocks solved the issue of dropped samples.

I only gave kernelshark little attention. It didn't prove to be a simple
tool to use out of the box, I don't think that the docs and level of polish
are well enough for this general use case. Maybe, if someone takes it as a
project and documents how to apply it to flowgraph inspection.



On Tue, Nov 7, 2017 at 1:25 PM Marcus Müller <muel...@kit.edu> wrote:

> Hi Gilad,
>
> part of this is for the future reader of this thread, so, please, bear
> with me:
>
> On 07.11.2017 10:42, Gilad Beeri (ApolloShield) wrote:
> > I have a flowgraph, that when run, no CPU core is ever close to 100%
> > utilization.
>
> Indeed, dropped samples indicate a bottleneck narrower than your USRP's
> sampling rate, but that bottleneck doesn't have to be CPU overutilization!
> Simplest example: add a Throttle block to a flow graph that otherwise
> wouldn't produce any problems with half the necessary sampling rate.
>
> Most often, I find that IO operations actually become the the bottleneck
> – be it that sending samples to the USRP (or receiving them) is actually
> pretty time-intense, or that you need to interact with storage.
>
> Depending on the tooling you choose, this fact might or might not be
> hidden; time spent, for example "on behalf" of a thread in Kernel land,
> searching for a contiguous piece of memory to give to that process, or
> handling USB buffers or... might or might not be attributed to the process.
>
> Another very classical problem is memory bandwidth and latency; so, as
> shown by SE at this year's GRCon, chances aren't that bad that you can
> optimize quite a bit if you co-locate connected blocks on the same CPU,
> you get a caching advantage (or, rather, not incur a disadvantage).
>
> That all being said, how do you proceed?
>
> First of all, this is one of the cases where having ControlPort is very
> helpful. If you have it (with Thrift and PerfCounters enabled), you can
> start the CtrlPort Performance Monitor, and see which output buffers
> "stay full" all the time. Block after that is probably your bottleneck.
>
> If you don't, try running `perf top -ag` (as root might help here, you
> want to also inspect kernel times, not quite sure about that, though).
> You should be getting a listing of "when we sampled where the CPU(s)
> were, in x % of the time, they were stuck in these functions".
>
> I really tried, but haven't had the time to work with kernelshark. That
> might really be a tool of choice here. In fact, it looks so cool that I
> could imagine that we one day supersede the perf counter concept with
> that; who knows.
>
> If you do happen to look into that, I'd be very happy to get some
> feedback about the process, and what the problems were. I think this is
> definitely something we want to enable users to do – understand not only
> the behaviour of their blocks in isolation, but how a system works.
> After all, one of the major "let's dream about a GNU Radio in the
> future" things we're considering is making it easy to distribute a flow
> graph across computers, and for that, systemic insight pretty much is a
> must.
>
> Best regards,
> Marcus
>
> ___
> 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] VOLK: What Could Make volk_32fc_index_max_16u() Go Wrong?

[Gilad Beeri (ApolloShield)]

First,
"~/p/s/p/test_data (master)> cat ~/.volk/volk_config | grep
volk_32fc_index_max_16u
volk_32fc_index_max_16u a_sse3 generic"

I did "vector[996] = gr_complex(1,1);" and it resulted in argmax 996
(correct result).
Same results when setting any single sample between 996 to 999.
But - when I set 995 to (1,1), argmax returns 992 (?!)
When I set 992 to (1,1), argmax returns 992.
When I set 991, argmax returns 888.
When I set sample #2, argmax returns 0.

So the pattern seems to be:
Return the first index of the quartet that contains the biggest sample.



On Tue, Jan 23, 2018 at 1:52 PM Jeff Long  wrote:

> The generic VOLK implementation (probably not the one being called) can't
> do this, but the vectorized version (which is probably being called) does
> things in groups of 4. Can you try making 996 the highest and see if it
> wrongly reports 999?
> ___
> 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] VOLK: What Could Make volk_32fc_index_max_16u() Go Wrong?

[Gilad Beeri (ApolloShield)]

I also suspect a memory corruption but couldn't pinpoint its source.

Per your suggestion, I copied the same cout statement to the end of the
function (before the return call), the output is exactly the same (so the
#0, #996, and #999 samples weren't changed) and argmax is still wrongly 996.

On Tue, Jan 23, 2018 at 12:45 PM Jeff Long <willco...@gmail.com> wrote:

> This sounds like a memory corruption error of some sort. Try printing the
> values after calling the volk function and see if they have been changed.
>
> On Tue, Jan 23, 2018 at 2:22 AM, Gilad Beeri (ApolloShield) <
> gi...@apolloshield.com> wrote:
>
>> Hi,
>> I have the following function:
>>
>> float blk::func(uint16_t *argmax, gr_complex *vector, uint32_t vlen) {
>>   cout << "0: " << vector[0] << " (" << abs(vector[0])<< ")"
>> << " 996: " << vector[996] << " (" << abs(vector[996]) << ") "
>> << " 999: " << vector[999] << " (" << abs(vector[999]) << ")" <<
>> endl;
>>   volk_32fc_index_max_16u(argmax, vector, vlen);
>>   const gr_complex max_mag_sample = vector[*argmax];
>>   const float max_abs = abs(max_mag_sample);
>>   return max_abs;
>> }
>>
>> It works most of the time. But seldom, I have some input that causes it
>> to return argmax which isn't the index of the sample with the biggest
>> magnitude (this is reproduced between different executions - for the same
>> input vector, given the same conditions, the wrong argmax is returned). Any
>> idea what can cause it, or how to debug it?
>>
>> Some info:
>>
>>
>>1. GNU Radio 3.7.11.1.
>>2. When I compile with -DCMAKE_BUILD_TYPE=RelWithDbgInfo (or Debug),
>>the issue doesn't happen.
>>3. When I add specific debug prints, the issue doesn't happen, but
>>with some debug prints I'm able to reproduce the problem. See below.
>>4. I have several ways to "solve" ("hide" will be a better word) the
>>issue, for example, moving the buffer allocation of vector to the loop 
>> body
>>(a loop calls the above function each iteration) seems to "solve" the
>>issue, but I'm concerned that it only hides a bug that will surface again
>>(and this is a hard bug to catch, because it doesn't crash, just returns
>>wrong results).
>>5. None of the variables I created (buffer, argmax, vlen) are
>>volk-aligned (weren't created using volk_malloc()).
>>6. volk_32fc_index_max_16u() writes 996 to argmax, while 999 is the
>>biggest sample (the debug print below at the least proves that the last
>>sample is bigger than vector[argmax]). If I try passing "vlen - 1"
>>(remove the last, biggest sample), I get argmax 880, which seems like
>>the actual 2nd biggest.
>>7. I'm certain about the issue because I'm able to print the values
>>of the samples. My vector is 1000-sample long (vlen == 1000).
>>8. Most inputs work as expected.
>>9. Oddly enough, even adding "vector[996] = 0" as the first line in
>>the function doesn't help: the function still chooses 996 as argmax (and I
>>verified that the sample is really 0)!
>>   1. When setting the last sample to 0 (instead of #996), argmax is
>>   chosen to be 880, so it basically seems like "if the last (#999) 
>> sample is
>>   the biggest, choose 996".
>>10. If I pass vector+1 (start at the 2nd sample) and vlen-1 (until
>>the end), I get the last sample (so correct results because it's the
>>biggest).
>>
>> cout << "0: " << vector[0] << " (" << abs(vector[0])<< ")"
>> << " 996: " << vector[996] << " (" << abs(vector[996]) << ") "
>> << " 999: " << vector[999] << " (" << abs(vector[999]) << ")" <<
>> endl;
>> ->
>>
>> 0: (-0.00345266,-0.00122826) (0.00366463) 996: (0.000987553,0.00248463)
>> (0.0026737)  999: (0.0273567,0.00109235) (0.0273785)
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] VOLK: What Could Make volk_32fc_index_max_16u() Go Wrong?

[Gilad Beeri (ApolloShield)]

Hi,
I have the following function:

float blk::func(uint16_t *argmax, gr_complex *vector, uint32_t vlen) {
  cout << "0: " << vector[0] << " (" << abs(vector[0])<< ")"
<< " 996: " << vector[996] << " (" << abs(vector[996]) << ") "
<< " 999: " << vector[999] << " (" << abs(vector[999]) << ")" <<
endl;
  volk_32fc_index_max_16u(argmax, vector, vlen);
  const gr_complex max_mag_sample = vector[*argmax];
  const float max_abs = abs(max_mag_sample);
  return max_abs;
}

It works most of the time. But seldom, I have some input that causes it to
return argmax which isn't the index of the sample with the biggest
magnitude (this is reproduced between different executions - for the same
input vector, given the same conditions, the wrong argmax is returned). Any
idea what can cause it, or how to debug it?

Some info:


   1. GNU Radio 3.7.11.1.
   2. When I compile with -DCMAKE_BUILD_TYPE=RelWithDbgInfo (or Debug), the
   issue doesn't happen.
   3. When I add specific debug prints, the issue doesn't happen, but with
   some debug prints I'm able to reproduce the problem. See below.
   4. I have several ways to "solve" ("hide" will be a better word) the
   issue, for example, moving the buffer allocation of vector to the loop body
   (a loop calls the above function each iteration) seems to "solve" the
   issue, but I'm concerned that it only hides a bug that will surface again
   (and this is a hard bug to catch, because it doesn't crash, just returns
   wrong results).
   5. None of the variables I created (buffer, argmax, vlen) are
   volk-aligned (weren't created using volk_malloc()).
   6. volk_32fc_index_max_16u() writes 996 to argmax, while 999 is the
   biggest sample (the debug print below at the least proves that the last
   sample is bigger than vector[argmax]). If I try passing "vlen - 1"
   (remove the last, biggest sample), I get argmax 880, which seems like
   the actual 2nd biggest.
   7. I'm certain about the issue because I'm able to print the values of
   the samples. My vector is 1000-sample long (vlen == 1000).
   8. Most inputs work as expected.
   9. Oddly enough, even adding "vector[996] = 0" as the first line in the
   function doesn't help: the function still chooses 996 as argmax (and I
   verified that the sample is really 0)!
  1. When setting the last sample to 0 (instead of #996), argmax is
  chosen to be 880, so it basically seems like "if the last (#999)
sample is
  the biggest, choose 996".
   10. If I pass vector+1 (start at the 2nd sample) and vlen-1 (until the
   end), I get the last sample (so correct results because it's the biggest).

cout << "0: " << vector[0] << " (" << abs(vector[0])<< ")"
<< " 996: " << vector[996] << " (" << abs(vector[996]) << ") "
<< " 999: " << vector[999] << " (" << abs(vector[999]) << ")" <<
endl;
->

0: (-0.00345266,-0.00122826) (0.00366463) 996: (0.000987553,0.00248463)
(0.0026737)  999: (0.0273567,0.00109235) (0.0273785)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Float is required error for customized Block

[Gilad Beeri (ApolloShield)]

Have just looked at your code from my mobile.
You want to check numpy.log10 and numpy.greater (there will be other ways
to do the same thing).

On Tue, Jan 2, 2018, 20:18 Gilad Beeri (ApolloShield) <
gi...@apolloshield.com> wrote:

> This is related to Python, not GNU Radio per se. It seems that you pass
> in1 to math.log10().
> I assume that you define in1 as input_items[1], which is a list of items
> to process (not a single item), while the log function expects to get a
> float, not a list.
>
> Something like:
> for item in in1:
>   c = math.log10(item)
>
> should work for you. I guess there's a numpy function that will run the
> log function on a list more efficiently.
>
>
>
> On Tue, Jan 2, 2018, 20:10 Tellrell White <rell...@gmail.com> wrote:
>
>> Hello Guys
>>
>> I'm creating a customized block in the GNU Radio framework using python
>> that takes in a number of input items and once that number of input items
>> surpasses a certain number, 1024 of the input items are taken and stored
>> into an array, and then those items are converted to dB and lastly compared
>> to a threshold value, 5 in this case. If any of the values are greater than
>> the threshold value, a message is printed indicating a signal is present,
>> and if none of the values are greater than 5, this is indicated with a
>> message stating "No signal is present".
>>
>> When I run the flow graph which uses this block I get the following error.
>>
>> handler caught exception: a float is required
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",
>> line 55, in eval
>> try: self._callback()
>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",
>> line 144, in __gr_block_handle
>> ) for i in self.__out_indexes],
>>   File "/home/tellrell/Ener_detec.py", line 42, in general_work
>> c = math.log10(in1) #converts 1024 values stored in in1 to dB
>> and stores them in c
>> TypeError: a float is required
>> thread[thread-per-block[8]: ]: caught unrecognized
>> exception
>>
>>
>>
>> The .py script for the customized block along with the corresponding .grc
>> file are attached below.
>>
>> Any help would be great.
>>
>> Tellrell
>> ___
>> 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] Float is required error for customized Block

[Gilad Beeri (ApolloShield)]

This is related to Python, not GNU Radio per se. It seems that you pass in1
to math.log10().
I assume that you define in1 as input_items[1], which is a list of items to
process (not a single item), while the log function expects to get a float,
not a list.

Something like:
for item in in1:
  c = math.log10(item)

should work for you. I guess there's a numpy function that will run the log
function on a list more efficiently.



On Tue, Jan 2, 2018, 20:10 Tellrell White  wrote:

> Hello Guys
>
> I'm creating a customized block in the GNU Radio framework using python
> that takes in a number of input items and once that number of input items
> surpasses a certain number, 1024 of the input items are taken and stored
> into an array, and then those items are converted to dB and lastly compared
> to a threshold value, 5 in this case. If any of the values are greater than
> the threshold value, a message is printed indicating a signal is present,
> and if none of the values are greater than 5, this is indicated with a
> message stating "No signal is present".
>
> When I run the flow graph which uses this block I get the following error.
>
> handler caught exception: a float is required
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",
> line 55, in eval
> try: self._callback()
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",
> line 144, in __gr_block_handle
> ) for i in self.__out_indexes],
>   File "/home/tellrell/Ener_detec.py", line 42, in general_work
> c = math.log10(in1) #converts 1024 values stored in in1 to dB
> and stores them in c
> TypeError: a float is required
> thread[thread-per-block[8]: ]: caught unrecognized
> exception
>
>
>
> The .py script for the customized block along with the corresponding .grc
> file are attached below.
>
> Any help would be great.
>
> Tellrell
> ___
> 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] Debugging the Source of Dropped Samples

[Gilad Beeri (ApolloShield)]

Hey,
I have a flowgraph, that when run, no CPU core is ever close to 100%
utilization. Still, I get many dropped samples. I don't get the dropped
samples when running benchmark_rate for the similar durations and at the
same sample rate. Using USRP B205mini on Ubuntu 16.04 on a high-performance
PC.

How do I debug the source of dropped samples, i.e., finding the problematic
block?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Analyzing an Arbitrary Length Sequence in a Python Block

[Gilad Beeri (ApolloShield)]

Hi again,
Does anybody have an idea or a pointer to (i) the methodological way to
solve the logical problem; (ii) solving the "is requesting more input data
than we can provide" error; (iii) solving another error (wasn't mentioned
before) from the same code block "Buffer too small for min_noutput_items";
and (iv) a general tip to continuing operations when an error causes a
block to return -1 while I want the flowgraph to continue (catch an
exception / handle an error, lose some data and move on)?

On Mon, Oct 16, 2017 at 8:59 AM Gilad Beeri (ApolloShield) <
gi...@apolloshield.com> wrote:

> I'm writing a Python block that, in general, does the following:
> Input: a stream of numbers (assume integers for the sake of discussion).
> Output: a stream of numbers
>
> I made some generalizations to the real problem to simplify the question.
>
> The block looks for sequences of positive integers and tags the max
> integer in each sequence it finds.
> Example (^ means a tag):
>
> 0 0 1 0 0 2 1 0 2 3 2 0 0 0 7 0 4 2 5 3 8 2 4 6 3 6 4 2 7 9 3 1 0 5 0 -->
> 1^ 2^ 3^ 7^ 9^ 5^
>
> The trivial implementation - in each call to (general_)work() process the
> current window, fails when the scheduler cuts a sequence in the middle, for
> example, there's a long sequence above, the scheduler might process it as 2
> or more different calls to work(), which will end with wrong results (I'll
> get more than one value). Clarification: if a call to work() gets 0 4 2 5
> and then the next call gets 3 8 2 4 and then 6 3 6 4 2 7 9 3 1, the output
> will be 5^ 8^ 9^ and not only 9^.
>
> Note: The sequences can be of arbitrary lengths. I'm ok with a practical
> solution that says that above some very high sequence length, the block
> ignores the data or gives wrong results. I don't have practical memory
> limits in my desktop (the app has several GBs it can consume in addition to
> what it consumes now).
>
> I solved the issue by implementing a check: if the last input value is
> positive, this call of work() can't know for certain it is the last value
> of the sequence, so return 0 (no consumption) and ask for more data (I took
> this idea from peak_detector2_fb_impl.cc). The block insists on getting a
> sequence that is long enough such that it has a 0 in the end. For the sake
> of discussion, let's ignore the scenario that there are multiple sequences
> in a single call to work().
>
> I have several questions and issues with this solution:
>
>
>1. The only way that worked for me is using self.set_output_multiple()
>when necessary (when the block sees an unended sequence), and calling it
>again with lower values later when the sequence is ended (to improve
>latency). Since I don't know the sequence length, I keep calling
>set_output_multiple(2 * self.output_multiple()) until I get what I need.
>The question is: Why do I need the output multiple to begin with? If the
>block doesn't consume anything, and the upstream block keeps feeding it
>with data, I expect the input buffers to grow, thus the next call to work()
>should come with more items to process. Instead, I noticed it doesn't
>happen, and only an output multiple makes the scheduler provide more items
>for processing in the next call to work().
>2. At some point I get the error "sched:  is
>requesting more input data than we can provide. ninput_items_required = 74.
>max_possible_items_available = 63. If this is a filter, consider reducing
>the number of taps.". How do I increase the max_possible_items_available? I
>searched the source code but couldn't find a way that works in Python (not
>all methods are exposed to Python) that increases the input buffers so that
>max_possible_items_available (input buffer size - 1) is increased? Again, I
>can allow myself increasing the input buffer of this specific block to a
>lot more. I can also increase the input buffers application-wide, but
>really only this block needs them to be bigger.
>3. How can I handle this error at runtime without "crashing"? Ideally,
>I want to catch an exception and let the block decides it ignores the data
>/ gives false results, but block_executor::run_one_iteration() goes to
>were_done thus stopping the block. In the spirit of practicality, I can
>also live with workarounds like restarting the block.
>
>
> Thanks,
> Gilad
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Setting USRP's AGC Through GNU Radio's USRP Source

[Gilad Beeri (ApolloShield)]

Hi,
I'm not sure whether this question should be posted in this mailing list or
in usrp-users.

The USRP Source has a method called get_device() which returns an internal
pointer to the multi_usrp. The internal USRP object has a method of
set_rx_agc().

How can I access it through Python?
Assuming src is a USRP Source block,
src.get_device() returns: 

but then the returned object (dev) has no interesting functions
(only 'acquire', 'append', 'disown', 'next', 'own').

Is there a way to control the USRP B2xx's AGC (AD936x's AGC) through
Python? If not, what should I change in the source code to make it happen?

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

Re: [Discuss-gnuradio] Analyzing an Arbitrary Length Sequence in a Python Block

[Gilad Beeri (ApolloShield)]

I did generalize and simplify the problem presented to make it simpler.
The real calculation of the arbitrary-length sequence is made inside the
block. The block is actually a sync block. Some (not all) of the items it
outputs are tagged. Tags are determined by the calculation ran on the
sequence.
If I understand correctly, the fact that I need to tag items from the past
means that the approach of storing them in a memory buffer of the block
isn't going to solve my problem: I'll be able to find out what is the max
value, but I won't be able to tag the item if it was consumed by a former
call to work() - can't tag past items.

The solution presented in peak_detector2_fb was the inspiration to my
solution, and my questions in the original post arise from it (how do I
increase the maximum possible number of items, specifically in Python, how
do I handle the error if it indeed occurs, and a theoretical question - why
do I need to use output_multiple and the scheduler doesn't feed my block
with more items if it has more ready as an input because the last call to
work() didn't consume any).


On Tue, Oct 17, 2017 at 6:02 AM Kevin Reid <kpr...@switchb.org> wrote:

> On Sun, Oct 15, 2017 at 10:59 PM, Gilad Beeri (ApolloShield) <
> gi...@apolloshield.com> wrote:
>
>> I'm writing a Python block that, in general, does the following:
>> Input: a stream of numbers (assume integers for the sake of discussion).
>> Output: a stream of numbers
>>
> …
>
>> Note: The sequences can be of arbitrary lengths.
>>
>
> If you need to look at an arbitrary length of samples, it would likely be
> best for your block to store the samples it receives in a buffer it
> manages, not try to convince GNU Radio to store them for you.
>
> More narrowly, if the only _sample_ you want to output is the max value
> (you talked about "tagging the max value" but your example output sequences
> also didn't contain any "untagged" samples, so I'm not sure if that's what
> you actually meant), you should be able to just track the max-so-far value
> and not even need an unbounded buffer.
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Analyzing an Arbitrary Length Sequence in a Python Block

[Gilad Beeri (ApolloShield)]

I'm writing a Python block that, in general, does the following:
Input: a stream of numbers (assume integers for the sake of discussion).
Output: a stream of numbers

I made some generalizations to the real problem to simplify the question.

The block looks for sequences of positive integers and tags the max integer
in each sequence it finds.
Example (^ means a tag):

0 0 1 0 0 2 1 0 2 3 2 0 0 0 7 0 4 2 5 3 8 2 4 6 3 6 4 2 7 9 3 1 0 5 0 -->
1^ 2^ 3^ 7^ 9^ 5^

The trivial implementation - in each call to (general_)work() process the
current window, fails when the scheduler cuts a sequence in the middle, for
example, there's a long sequence above, the scheduler might process it as 2
or more different calls to work(), which will end with wrong results (I'll
get more than one value). Clarification: if a call to work() gets 0 4 2 5
and then the next call gets 3 8 2 4 and then 6 3 6 4 2 7 9 3 1, the output
will be 5^ 8^ 9^ and not only 9^.

Note: The sequences can be of arbitrary lengths. I'm ok with a practical
solution that says that above some very high sequence length, the block
ignores the data or gives wrong results. I don't have practical memory
limits in my desktop (the app has several GBs it can consume in addition to
what it consumes now).

I solved the issue by implementing a check: if the last input value is
positive, this call of work() can't know for certain it is the last value
of the sequence, so return 0 (no consumption) and ask for more data (I took
this idea from peak_detector2_fb_impl.cc). The block insists on getting a
sequence that is long enough such that it has a 0 in the end. For the sake
of discussion, let's ignore the scenario that there are multiple sequences
in a single call to work().

I have several questions and issues with this solution:


   1. The only way that worked for me is using self.set_output_multiple()
   when necessary (when the block sees an unended sequence), and calling it
   again with lower values later when the sequence is ended (to improve
   latency). Since I don't know the sequence length, I keep calling
   set_output_multiple(2 * self.output_multiple()) until I get what I need.
   The question is: Why do I need the output multiple to begin with? If the
   block doesn't consume anything, and the upstream block keeps feeding it
   with data, I expect the input buffers to grow, thus the next call to work()
   should come with more items to process. Instead, I noticed it doesn't
   happen, and only an output multiple makes the scheduler provide more items
   for processing in the next call to work().
   2. At some point I get the error "sched:  is
   requesting more input data than we can provide. ninput_items_required = 74.
   max_possible_items_available = 63. If this is a filter, consider reducing
   the number of taps.". How do I increase the max_possible_items_available? I
   searched the source code but couldn't find a way that works in Python (not
   all methods are exposed to Python) that increases the input buffers so that
   max_possible_items_available (input buffer size - 1) is increased? Again, I
   can allow myself increasing the input buffer of this specific block to a
   lot more. I can also increase the input buffers application-wide, but
   really only this block needs them to be bigger.
   3. How can I handle this error at runtime without "crashing"? Ideally, I
   want to catch an exception and let the block decides it ignores the data /
   gives false results, but block_executor::run_one_iteration() goes to
   were_done thus stopping the block. In the spirit of practicality, I can
   also live with workarounds like restarting the block.


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

[Discuss-gnuradio] Checking that a flowgraph is done

[Gilad Beeri (ApolloShield)]

I have a flowgraph used for simulations that uses a File Source with no
repeat.
I want to run some code after the flowgraph is done (-> when the source
returns -1).
How can I achieve that?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dBm and dB Measurements

[Gilad Beeri (ApolloShield)]

Can you convert the data to a table + 2 graphs (1st: SA level vs. input
power, 2nd: SDR level vs. input power)? It will help you and others
conclude the relationship between the behaviors

On Thu, Jun 29, 2017 at 11:16 PM GNUBeginner  wrote:

> Hello Everyone,
>
> I am using HackRF One and running gr-scan spectrum monitoring software. I
> am
> also utilizing vector signal generator and spectrum analyzer.
>
> Can anyone please help me understand the following measurement results from
> both spectrum analyzer (reference level: -20 dBm) and gr-scan?
>
> Spectrum Analyzer: -25 dBm VSG at 2437 MHz -> Peak Power: -47.26 dBm
> (Almost
> no loss since it is one foot cable directly connected to spectrum analyzer
> from vector signal generator)
>
> gr-scan: -25 dBm VSG at 2437 MHz -> Peak Power: -47.61 dB
>
> Spectrum Analyzer: -30 dBm VSG at 2437 MHz -> Peak Power: -52.85 dBm
> (Again,
> it is the same...Almost no loss)
>
> gr-scan: -30 dBm VSG at 2437 MHz -> Peak Power: -51.37 dB
>
> Spectrum Analyzer: -35 dBm VSG at 2437 MHz -> Peak Power: -58.22 dBm
> (Almost
> no loss)
>
> gr-scan: -35 dBm VSG at 2437 MHz -> Peak Power: -58.34 dB
>
> Spectrum Analyzer: -40 dBm VSG at 2437 MHz -> Peak Power: -63.21 dBm
>
> gr-scan: -40 dBm VSG at 2437 MHz -> Peak Power: -63.15 dB
>
> Spectrum Analyzer: -45 dBm VSG at 2437 MHz -> Peak Power: -67.63 dBm
>
> gr-scan: -45 dBm VSG at 2437 MHz -> Peak Power: -67.41 dB
>
> I guess there is no relationship between SDR dB values and spectrum
> analyzer
> dBm values but what I have noticed that SDR is linearly following VSG power
> increments.
>
> Thanks,
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/dBm-and-dB-Measurements-tp64413.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> 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] dB or dBm

[Gilad Beeri (ApolloShield)]

Yes - he meant a constant tone, a simple sinusoidal signal with fixed
frequency and amplitude (Acos(wt)).

And you can't measure the power directly. What you can measure is the graph
(function) between the injected power (as determined in your signal source)
to those strange dB values. After you get to the best function you can get,
you conclude power of other signals by comparing those dB values. As said,
you need to be aware of the different frequencies and gain values.



On Wed, Jun 21, 2017 at 9:04 PM GNUBeginner  wrote:

> Also, how could I measure power? The program is giving some strange dB
> values...
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/dB-or-dBm-tp64323p64330.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> 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] dB or dBm

[Gilad Beeri (ApolloShield)]

Marcus explained it better than me in your previous email, but in general,
those SDR devices aren't calibrated devices, as in you (the user) can't
infer from the sample value the signal power, so the apps (e.g.,
QSpectrumAnalyzer) can't tell you anything about dBm (power) values, only
dB values relative to some point (full scale according to Marcus).

If you want to measure the power values with those SDR devices, you need to
calibrate them by fixing the center frequency and the gain, then injecting
different levels of power, measuring the dB values you get, and inferring
the "dBm vs. dB-level" function (which depends on the center frequency and
gain, and possibly other factors).


On Wed, Jun 21, 2017 at 5:09 PM GNUBeginner  wrote:

> Hello Everybody,
>
> Could anyone please try to explain to me why I am seeing dB values instead
> of dBm in the spectrum analyzer GUIs such as QSpectrumAnalyzer or spectrum
> scan programs such as gr-scan or hackrf_sweep.
>
> Because when I inject a signal with -15 dBm power using 20 dB attenuator
> (no
> loss - just a short cable from the Vector Signal Generator to the HackRF
> One) to the HackRF One, somehow I see -53 dB as peak power.
>
> Thanks
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/dB-or-dBm-tp64323.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> 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] Kernel Ubuntu - USB 3.0 trouble - missed packets

[Gilad Beeri (ApolloShield)]

install (apt) cpufreq-utils and indicator-cpufreq, you'll get a UI icon to
set the CPU to "performance" mode.

On Fri, May 19, 2017 at 1:02 AM Marcus Müller 
wrote:

> Hi Cristian,
>
> hm, the Intel 8 series tends to work well.
>
> What is it that you're doing with these samples in GNU Radio? Just UHD
> Source -> Null Sink, right?
>
> Gut feeling: your computer might have adaptive power saving, so that your
> CPU is scaled down sporadically, and then has a hard time processing the
> samples in real time when they're there.
>
> Not being overly familiar with how that works under Ubuntu's UI: can you
> set the CPU to "performance" mode (or just disable frequency scaling
> alltogether) for a test?
>
> Best regards,
>
> Marcus
>
> On 18.05.2017 23:50, Cristian Rodríguez wrote:
>
> On 16/05/17 06:49, Neel Pandeya wrote:
>>
>> Hello Cristian:
>>
>> If you use Ubuntu 16.04.2, the kernel is 4.8, which should be fine.
>>
>> First at all, thank you very much for answering.
>
> My kernel version is: 4.8.0-49-generic
> Ubuntu Release:16.04.2 LTS
>
>
>> The specific USB controller is also very important. The Intel controllers
>> work best. Which controller do you have in your system? (run "lspci")
>>
>> It is the information dropped by "lspci"
>
> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
> Processor DRAM Controller (rev 06)
> 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
> Processor PCI Express x16 Controller (rev 06)
> 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core
> Processor Integrated Graphics Controller (rev 06)
> 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core
> Processor HD Audio Controller (rev 06)
> 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> Family USB xHCI (rev 05)
> 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series
> Chipset Family MEI Controller #1 (rev 04)
> 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> Family USB EHCI #2 (rev 05)
> 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High
> Definition Audio Controller (rev 05)
> 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family
> PCI Express Root Port #1 (rev d5)
> 00:1c.1 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family
> PCI Express Root Port #2 (rev d5)
> 00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family
> PCI Express Root Port #3 (rev d5)
> 00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family
> PCI Express Root Port #4 (rev d5)
> 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> Family USB EHCI #1 (rev 05)
> 00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev 05)
> 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset
> Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
> 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus
> Controller (rev 05)
> 01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 850M] (rev
> a2)
> 04:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network
> Adapter (rev 01)
> 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
>
>>
>> What flow control errors are you seeing? Are there any overruns ("O") or
>> underruns ("U") printed on the console?
>>
>> There are overruns "000"
>
>> Did you increase the socket buffer sizes?
>>
>> https://files.ettus.com/manual/page_transport.html#transport_udp_sockbufs
>>
>> No, i haven't. But i did modified the num_recv_frames to 1024. By doing
> it, I don't lose samples, but i'm not pretty sure about i'm in fact
> reciving all. Do you think it is a better solution that trying to install
> other USB3 controller?
>
> Thanks a lot for your time to read my message.
>
> Best regards,
>
> Cristian
>
> 2017-05-15 23:49 GMT-05:00 Neel Pandeya :
>
>> Hello Cristian:
>>
>> If you use Ubuntu 16.04.2, the kernel is 4.8, which should be fine.
>>
>> The specific USB controller is also very important. The Intel controllers
>> work best. Which controller do you have in your system? (run "lspci")
>>
>> What flow control errors are you seeing? Are there any overruns ("O") or
>> underruns ("U") printed on the console?
>>
>> Did you increase the socket buffer sizes?
>>
>> https://files.ettus.com/manual/page_transport.html#transport_udp_sockbufs
>>
>> --​Neel Pandeya
>>
>>
>>
>> On 15 May 2017 at 17:20, Cristian Rodríguez <
>> cristian.rodriguez...@gmail.com> wrote:
>>
>>> HI all.
>>>
>>> I was writing to the forum a time ago because i have missed packets when
>>> i build a simple flow graph in gnu radio and set the sample rate over
>>> 20Msamples/s.
>>>
>>> The conclusion was that i had to review my USB 3.0 drivers but i'm
>>> working on ubuntu (16.05) and the only way to change the drivers is by
>>> 

Re: [Discuss-gnuradio] How to write data periodically in file sink

[Gilad Beeri (ApolloShield)]

If you need accuracy, I think the asynchronous nature of your method might
problematic (will appreciate input from GR devs).
Maybe try a different approach - write the samples to a memory buffer, then
read from the buffer the exact # of samples you want to write to a file.

On Fri, May 19, 2017 at 5:02 PM Deepak Gautam  wrote:

> Dear luca,
>
> I had already tried with controlling flow graph dynamically using start(),
> stop(), lock(), unlock() function. Here i have the part of code i had used.
>
> tb=top_block_cls()
> count=1
> tb.start()
> while (count<5):
> time.sleep(1.0)   #data is recorded in the file
> tb.lock()
> tb.disconnect((tb.uhd_usrp_source_0,0),(tb.blocks_file_sink_0, 0))
> #disconnect source and block
> tb.blocks_file_sink_0= blocks.file_sink(gr.sizeof_gr_complex*1,
> filename,False)  # create new file sink to write
> tb.connect((tb.uhd_usrp_source_0,0),(tb.blocks_file_sink_0, 0))
>  #connect source with new file
> count=count+1
> time.sleep(2.0)   #wait
> tb.unlock()
> tb.stop()
>
>
> This program should write the data for 1 second in the file, wait for 2
> second and again write for 1 second to another file and so on for 5 4
> times. I expect the total data written in the file to be same. But total
> number of samples recorded in the files are different. for my sampling rate
> of 25MSps, it should record 25MS per file, but it is around 22Mega sample
> with different number of data in different file.  So it is difficult to
> reproduce the accurate signal from received data . My application requires
> very good phase coherence. So i am wondering whether there is something to
> do to solve in this method or i have to think of another idea.
>
>
> Best Regards,
> Deepak
>
>
>
> On Mon, May 15, 2017 at 9:02 PM Moritz Luca Schmid <
> luca.moritz.sch...@gmail.com> wrote:
>
>> Hey Deepak,
>>
>> my first idea is to reconfigure the flowgraph. You could connect and
>> disconnect your source for the time, you want to write data in your file
>> sink and the time you don't want to.
>>
>> You can find infos about the flowgraphs operations here
>> .
>>
>>
>> Best
>>
>> Luca
>>
>>
>>
>> On 15.05.2017 13:53, Deepak Gautam wrote:
>>
>> Currently i am working in the USRP using GNU Radio for my masters work.
>> In my transmitter side, i send data continuously from file source followed
>> by UHD Sink at the rate of 25 MSPS. In receiver side, I want to write the
>> data in every two/three seconds after receiving from receiver USRP.
>> Meaning, write data for 1 sec (25M samples), then dont write for next 2
>> second and again write for 1 sec and so on. Is there any suggestion for
>> this purpose. I look forward for the resposne
>>
>>
>> Best Regards,
>> Deepak
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Pentek & GR

[Gilad Beeri (ApolloShield)]

Hi,
Does anybody have experience with integrating Pentek's SDR devices and GNU
Radio? I wish to experiment with them together.
Basically it means having source and sink blocks implemented based on their
drivers, I was wondering whether anyone had the chance to do that.

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

Re: [Discuss-gnuradio] "from gnuradio import gr" fails with a Fatal Python error

[Gilad Beeri (ApolloShield)]

Hi,
Seems like you got it. I'm writing here analysis and fixing steps for
future generations.

   1. Reproduce the problem by running 'python -c "from gnuradio import gr'
   - that should crash and print the error
   2. Running "which python" should show the python binary used, most
   probably /usr/bin/python
   3. 'port list | grep "lang/python"' will show the installed MacPort
   Python versions.
   4. Assuming your default Python is 2.7 ("python -V" to verify),  "port
   contents python27 | grep bin/python" will show the binaries installed by
   that Python 2.7 port, which will probably be /opt/local/bin/python2.7
   (which symlinks
   to 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7).
   5. *Running '/opt/local/bin/python2.7 -c "from gnuradio import gr"'
   works as expected*
   6. So it's possible to work with GNU Radio as long as you use the
   correct Python binary. In my case, the PATH environment variable did have
   /opt/local/bin before /usr/local/bin, but MacPorts doesn't create a
   "python" symlink, so it can be fixed by either using "python2.7" (which
   exists in /opt/local/bin and will be used before the system's binary) or by
   creating a symlink with "ln -s /usr/local/bin/python2.7
   /usr/local/bin/python". After symlinking, 'python -c "from gnuradio import
   gr' works as expected.


On Mon, Nov 21, 2016 at 6:44 PM Michael Dickens <michael.dick...@ettus.com>
wrote:

> Hi Gilad - IIRC this error means that Python installs are being mixed
> between linking and runtime. For example, linking against the macOS
> provided Python and then trying to use MacPorts' Python for runtime
> execution. If this statement doesn't help, email me off-list & we'll work
> through your issue. - MLD
>
> On Mon, Nov 21, 2016, at 11:10 AM, Gilad Beeri (ApolloShield) wrote:
>
> The Python statement "from gnuradio import gr" crashes the Python process
> with "Fatal Python error: PyThreadState_Get: no current thread" (mac OS
> 10.12.1, GNU Radio 3.7.10.1 using Mac Ports, full log is attached).
>
> I tried following the cleanup process detailed in
> https://github.com/metacollin/homebrew-gnuradio/issues/47,
> which caused me to remove the GR modules foo, baz and ieee802_11, such
> that in a 2nd execution of that script it doesn't find anything.
> Tried reinstalling GNU Radio with "sudo port -f uninstall gnuradio; sudo
> port -t install gnuradio" but still no luck.
>
> Email had 1 attachment:
>
>- gnuradio_python_exception.txt
>  24k (text/plain)
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] "from gnuradio import gr" fails with a Fatal Python error

[Gilad Beeri (ApolloShield)]

Hi,
The Python statement "from gnuradio import gr" crashes the Python process
with "Fatal Python error: PyThreadState_Get: no current thread" (mac OS
10.12.1, GNU Radio 3.7.10.1 using Mac Ports, full log is attached).

I tried following the cleanup process detailed in
https://github.com/metacollin/homebrew-gnuradio/issues/47,
which caused me to remove the GR modules foo, baz and ieee802_11, such that
in a 2nd execution of that script it doesn't find anything.
Tried reinstalling GNU Radio with "sudo port -f uninstall gnuradio; sudo
port -t install gnuradio" but still no luck.
Process:   Python [44413]
Path:  
/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier:Python
Version:   2.7.10 (2.7.10)
Code Type: X86-64 (Native)
Parent Process:fish [528]
Responsible:   Python [44413]
User ID:   501

PlugIn Path: 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python
PlugIn Identifier:   org.python.python
PlugIn Version:  2.7.12, [c] 2001-2016 Python Software Foundation. 
(2.7.12)

Date/Time: 2016-11-21 14:40:53.268 +0200
OS Version:Mac OS X 10.12.1 (16B2555)
Report Version:12
Anonymous UUID:7FCC52F4-B5AD-E6C0-5A17-8D6F5AEEE2BA

Sleep/Wake UUID:   BCBAECE1-3F0E-4B80-BF6D-A408157ED236

Time Awake Since Boot: 61000 seconds
Time Since Wake:   1800 seconds

System Integrity Protection: enabled

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_CRASH (SIGABRT)
Exception Codes:   0x, 0x
Exception Note:EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib  0x7fffa68a1dda __pthread_kill + 10
1   libsystem_pthread.dylib 0x7fffa698d787 pthread_kill + 90
2   libsystem_c.dylib   0x7fffa6807420 abort + 129
3   org.python.python   0x000109c573f1 Py_FatalError + 49
4   org.python.python   0x000109c567ac PyThreadState_Get + 28
5   org.python.python   0x000109c5257e Py_InitModule4_64 + 62
6   _runtime_swig.so0x0001099bf211 init_runtime_swig + 629
7   org.python.python   0x0001095b7190 
_PyImport_LoadDynamicModule + 140
8   org.python.python   0x0001095b5e8c 0x10951c000 + 630412
9   org.python.python   0x0001095b5a60 0x10951c000 + 629344
10  org.python.python   0x0001095b4c70 
PyImport_ImportModuleLevel + 1185
11  org.python.python   0x00010959a066 0x10951c000 + 516198
12  org.python.python   0x0001095a2534 PyEval_EvalFrameEx + 
14624
13  org.python.python   0x00010959ea1e PyEval_EvalCodeEx + 1617
14  org.python.python   0x0001095a5442 0x10951c000 + 562242
15  org.python.python   0x0001095a1eae PyEval_EvalFrameEx + 
12954
16  org.python.python   0x0001095a54d5 0x10951c000 + 562389
17  org.python.python   0x0001095a1eae PyEval_EvalFrameEx + 
12954
18  org.python.python   0x00010959ea1e PyEval_EvalCodeEx + 1617
19  org.python.python   0x00010959e3c7 PyEval_EvalCode + 48
20  org.python.python   0x0001095b371d 
PyImport_ExecCodeModuleEx + 241
21  org.python.python   0x0001095b6427 0x10951c000 + 631847
22  org.python.python   0x0001095b5e8c 0x10951c000 + 630412
23  org.python.python   0x0001095b5a60 0x10951c000 + 629344
24  org.python.python   0x0001095b4c38 
PyImport_ImportModuleLevel + 1129
25  org.python.python   0x00010959a066 0x10951c000 + 516198
26  org.python.python   0x00010952675b PyObject_Call + 99
27  org.python.python   0x0001095a4e1b 
PyEval_CallObjectWithKeywords + 165
28  org.python.python   0x0001095a0c6f PyEval_EvalFrameEx + 8283
29  org.python.python   0x00010959ea1e PyEval_EvalCodeEx + 1617
30  org.python.python   0x00010959e3c7 PyEval_EvalCode + 48
31  org.python.python   0x0001095b371d 
PyImport_ExecCodeModuleEx + 241
32  org.python.python   0x0001095b6427 0x10951c000 + 631847
33  org.python.python   0x0001095b66af 0x10951c000 + 632495
34  org.python.python   0x0001095b5e8c 0x10951c000 + 630412
35  org.python.python   0x0001095b5cc2 0x10951c000 + 629954
36  org.python.python   0x0001095b4d0c 
PyImport_ImportModuleLevel + 1341
37  org.python.python   0x00010959a066 0x10951c000 + 516198
38  org.python.python   0x00010952675b PyObject_Call + 99
39  org.python.python   0x0001095a4e1b 

[Discuss-gnuradio] GNU Radio Tutorial Example Doesn't Work

[Gilad Beeri (ApolloShield)]

Hi,
Going over tutorial 2
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GRC,
trying the last example (a triangle wave, prove signal and a sine wave),
which based on common sense and the image in the tutorial, should result in
a periodic triangle shape in the waterfall scope.

I get a completely different result, see image attached.
My flowgraph seems to be accurate, also when running tutorial_two_7.grc
from the examples I get the same result.

GNU Radio 3.7.10.1, mac OS 10.12.1.

Do you have an idea why I don't get the expected shape?

This is the image from the tutorial:
https://raw.githubusercontent.com/gnuradio/gr-tutorial/master/examples/tutorial2/images/singing_waterfall.png

This is what I get (when running the example, not my own flowgraph):
[image: pasted1]
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio