Re: OOT module AttributeError - module has no attribute Arch Linux GR 3.8.1

[Nemanja Savic]

@Josh Blum-3 [via GnuRadio] 
You were right. This helped:
In the top CmakeLists.txt I added:
find_package(Gnuradio "3.8" REQUIRED COMPONENTS blocks)

In the lib/CMAKELists.txt I added:
find_package(gnuradio-blocks)
target_link_libraries(gnuradio-TPMS gnuradio::gnuradio-runtime
gnuradio::gnuradio-blocks)

Thanks a lot


On Mon, Jul 13, 2020 at 8:46 PM Josh  wrote:

> A lot of times the dreaded 'Module Not Found' error is caused by linker
> issues.
>
> In 3.8, the cmake files were modernized, but there are a few caveats
> especially if your OOT links against other GR modules (e.g. gr-digital).
> In order to use GR modules in your code, the target_link_libraries needs
> to specify the entire dependence.  For example, if you want to use
> functions from gr-analog, your target_link_libraries needs to have
> gnuradio::gnuradio-runtime gnuradio::gnuradio-fft gnuradio::gnuradio-filter
> gnuradio::gnuradio-analog
>
> You also have to specify the gnuradio components in the top level cmake
> file.
>
> Also make sure any external libraries are linked as well.
>
> Take a look at these as well as there may be some clues:
> https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide
> https://wiki.gnuradio.org/index.php/ModuleNotFoundError
>
>
> On Sun, Jul 12, 2020 at 8:21 PM Nemanja Savic  wrote:
>
>> Hi all,
>>
>> haven't been using GR and posting here for about 5 years. A few days ago
>> I installed GR on my machine which runs under Manjaro. I wanted to port
>> some of my old GR blocks (from 3.6.5) to the current GR version. I created
>> a new module and started adding some blocks. Making module works just fine
>> but when I want to use the blocks a python exception occurs saying my
>> module doesn't have the attribute it needs. My block is called TPMS and the
>> error is following:
>>
>> self.TPMS_min_max_threshold_detector_fb_0 =
>> TPMS.min_max_threshold_detector_fb(samp_rate, 0.01)
>> AttributeError: module 'TPMS' has no attribute
>> 'min_max_threshold_detector_fb'
>>
>> I dont seem to understand why is this happening. Namely, under this path:
>> /usr/lib/python3.8/site-packages/TPMS
>> I can see TPMS_swig.py and within that file there is a class
>> class min_max_threshold_detector_fb(object):
>>
>> It looks like something is wrong in the python but cant figure out what.
>>
>> sudo ld config didnt help.
>>
>> The output of cmake when preparing the block is following
>>
>> -- Build type not specified: defaulting to release.
>> CMake Warning (dev) at
>> /usr/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272
>> (message):
>>   The package name passed to `find_package_handle_standard_args`
>> (PkgConfig)
>>   does not match the name of the calling package (GMP).  This can lead to
>>   problems in calling code that expects `find_package` result variables
>>   (e.g., `_FOUND`) to follow a certain pattern.
>> Call Stack (most recent call first):
>>   /usr/share/cmake-3.17/Modules/FindPkgConfig.cmake:45
>> (find_package_handle_standard_args)
>>   /usr/lib64/cmake/gnuradio/FindGMP.cmake:1 (include)
>>   /usr/lib64/cmake/gnuradio/FindMPLIB.cmake:1 (find_package)
>>   /usr/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47
>> (find_package)
>>   /usr/lib64/cmake/gnuradio/GnuradioConfig.cmake:26 (find_dependency)
>>   CMakeLists.txt:88 (find_package)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>> CMake Warning (dev) at
>> /usr/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272
>> (message):
>>   The package name passed to `find_package_handle_standard_args`
>> (PkgConfig)
>>   does not match the name of the calling package (MPIR).  This can lead to
>>   problems in calling code that expects `find_package` result variables
>>   (e.g., `_FOUND`) to follow a certain pattern.
>> Call Stack (most recent call first):
>>   /usr/share/cmake-3.17/Modules/FindPkgConfig.cmake:45
>> (find_package_handle_standard_args)
>>   /usr/lib64/cmake/gnuradio/FindMPIR.cmake:1 (include)
>>   /usr/lib64/cmake/gnuradio/FindMPLIB.cmake:2 (find_package)
>>   /usr/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47
>> (find_package)
>>   /usr/lib64/cmake/gnuradio/GnuradioConfig.cmake:26 (find_dependency)
>>   CMakeLists.txt:88 (find_package)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>> -- Checking for module 'mpir >= 3.0'
>> --   Package 'mpir', required by 'virtual:world', not fo

Re: OOT module AttributeError - module has no attribute Arch Linux GR 3.8.1

[Nemanja Savic]

Thank you Josh. You answer came while I was making another post. I will
take a look at what you have suggested. Just would like to add, that my
module is created with gr_modtool from the gnuradio version i have at the
moment (3.8) - should in that case all dependencies be automatically solved
in the modern Cmake way? I also made another brand new module with a dummy
block and no dependencies. The block was realy just returning noutput_items
value or something. It was also making the same trouble. I have an
impression that if linking from my module to the gnuradio modules were bad,
it would raise some kind of runtime error, but I am no expert.

Here is what I wanted to ask before the answer from Josh came:

I decided to localize the problem, though without any success, but there
are some open questions:
1. during making of my module i see the following message and can't figure
out what that means, or is it wrong:
Set runtime path of "/usr/lib/python3.8/site-packages/TPMS/_TPMS_swig.so"
to ""
2. at the beginning of the swig.py file of my module there are following
lines:
# Import the low-level C/C++ module
if __package__ or "." in __name__:
print ("from . import _TPMS_swig")
from . import _TPMS_swig
print ("something")
else:
import _TPMS_swig
  I added those print commands. "something" is never printed, and I cant
explain why. No error special error is raised even if I write for example
"_TPMS-swig!" instead of "_TPMS_swig".

Best

On Mon, Jul 13, 2020 at 2:20 AM Nemanja Savic  wrote:

> Hi all,
>
> haven't been using GR and posting here for about 5 years. A few days ago I
> installed GR on my machine which runs under Manjaro. I wanted to port some
> of my old GR blocks (from 3.6.5) to the current GR version. I created a new
> module and started adding some blocks. Making module works just fine but
> when I want to use the blocks a python exception occurs saying my module
> doesn't have the attribute it needs. My block is called TPMS and the error
> is following:
>
> self.TPMS_min_max_threshold_detector_fb_0 =
> TPMS.min_max_threshold_detector_fb(samp_rate, 0.01)
> AttributeError: module 'TPMS' has no attribute
> 'min_max_threshold_detector_fb'
>
> I dont seem to understand why is this happening. Namely, under this path:
> /usr/lib/python3.8/site-packages/TPMS
> I can see TPMS_swig.py and within that file there is a class
> class min_max_threshold_detector_fb(object):
>
> It looks like something is wrong in the python but cant figure out what.
>
> sudo ld config didnt help.
>
> The output of cmake when preparing the block is following
>
> -- Build type not specified: defaulting to release.
> CMake Warning (dev) at
> /usr/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272
> (message):
>   The package name passed to `find_package_handle_standard_args`
> (PkgConfig)
>   does not match the name of the calling package (GMP).  This can lead to
>   problems in calling code that expects `find_package` result variables
>   (e.g., `_FOUND`) to follow a certain pattern.
> Call Stack (most recent call first):
>   /usr/share/cmake-3.17/Modules/FindPkgConfig.cmake:45
> (find_package_handle_standard_args)
>   /usr/lib64/cmake/gnuradio/FindGMP.cmake:1 (include)
>   /usr/lib64/cmake/gnuradio/FindMPLIB.cmake:1 (find_package)
>   /usr/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47
> (find_package)
>   /usr/lib64/cmake/gnuradio/GnuradioConfig.cmake:26 (find_dependency)
>   CMakeLists.txt:88 (find_package)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at
> /usr/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272
> (message):
>   The package name passed to `find_package_handle_standard_args`
> (PkgConfig)
>   does not match the name of the calling package (MPIR).  This can lead to
>   problems in calling code that expects `find_package` result variables
>   (e.g., `_FOUND`) to follow a certain pattern.
> Call Stack (most recent call first):
>   /usr/share/cmake-3.17/Modules/FindPkgConfig.cmake:45
> (find_package_handle_standard_args)
>   /usr/lib64/cmake/gnuradio/FindMPIR.cmake:1 (include)
>   /usr/lib64/cmake/gnuradio/FindMPLIB.cmake:2 (find_package)
>   /usr/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47
> (find_package)
>   /usr/lib64/cmake/gnuradio/GnuradioConfig.cmake:26 (find_dependency)
>   CMakeLists.txt:88 (find_package)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> -- Checking for module 'mpir >= 3.0'
> --   Package 'mpir', required by 'virtual:world', not found
> -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_INCLUD

OOT module AttributeError - module has no attribute Arch Linux GR 3.8.1

[Nemanja Savic]

Hi all,

haven't been using GR and posting here for about 5 years. A few days ago I
installed GR on my machine which runs under Manjaro. I wanted to port some
of my old GR blocks (from 3.6.5) to the current GR version. I created a new
module and started adding some blocks. Making module works just fine but
when I want to use the blocks a python exception occurs saying my module
doesn't have the attribute it needs. My block is called TPMS and the error
is following:

self.TPMS_min_max_threshold_detector_fb_0 =
TPMS.min_max_threshold_detector_fb(samp_rate, 0.01)
AttributeError: module 'TPMS' has no attribute
'min_max_threshold_detector_fb'

I dont seem to understand why is this happening. Namely, under this path:
/usr/lib/python3.8/site-packages/TPMS
I can see TPMS_swig.py and within that file there is a class
class min_max_threshold_detector_fb(object):

It looks like something is wrong in the python but cant figure out what.

sudo ld config didnt help.

The output of cmake when preparing the block is following

-- Build type not specified: defaulting to release.
CMake Warning (dev) at
/usr/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272
(message):
  The package name passed to `find_package_handle_standard_args` (PkgConfig)
  does not match the name of the calling package (GMP).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /usr/share/cmake-3.17/Modules/FindPkgConfig.cmake:45
(find_package_handle_standard_args)
  /usr/lib64/cmake/gnuradio/FindGMP.cmake:1 (include)
  /usr/lib64/cmake/gnuradio/FindMPLIB.cmake:1 (find_package)
  /usr/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47
(find_package)
  /usr/lib64/cmake/gnuradio/GnuradioConfig.cmake:26 (find_dependency)
  CMakeLists.txt:88 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at
/usr/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272
(message):
  The package name passed to `find_package_handle_standard_args` (PkgConfig)
  does not match the name of the calling package (MPIR).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /usr/share/cmake-3.17/Modules/FindPkgConfig.cmake:45
(find_package_handle_standard_args)
  /usr/lib64/cmake/gnuradio/FindMPIR.cmake:1 (include)
  /usr/lib64/cmake/gnuradio/FindMPLIB.cmake:2 (find_package)
  /usr/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47
(find_package)
  /usr/lib64/cmake/gnuradio/GnuradioConfig.cmake:26 (find_dependency)
  CMakeLists.txt:88 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Checking for module 'mpir >= 3.0'
--   Package 'mpir', required by 'virtual:world', not found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_INCLUDE_DIR)
CMake Warning (dev) at
/usr/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272
(message):
  The package name passed to `find_package_handle_standard_args` (VOLK) does
  not match the name of the calling package (Volk).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /usr/lib64/cmake/volk/VolkConfig.cmake:32
(find_package_handle_standard_args)
  /usr/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47
(find_package)
  /usr/lib64/cmake/gnuradio/GnuradioConfig.cmake:46 (find_dependency)
  CMakeLists.txt:88 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- User set python executable /usr/bin/python3
-- Found PythonLibs: /usr/lib/libpython3.8.so (found suitable exact version
"3.8.3")
-- Using install prefix: /usr/local
-- Building for version: v1.0-compat-xxx-xunknown / 1.0.0git
-- No C++ unit tests... skipping
-- 
-- Checking for module SWIG
-- Found SWIG version 4.0.1.
-- Found PythonLibs: /usr/lib/libpython3.8.so (found version "3.8.3")
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/user/work/gnuradio_module_test/gr-TPMS/build

In the past I used Red Hat, this is my first time using a distro based on
Arch Linux and I don't know if I am missing something regarding shared
libraries.

Best regards and thank you for your help

Re: [Discuss-gnuradio] message port declaration problem after changing to 3.7.8

[Nemanja Savic]

Hello,

I didn't deal with this since my post, still use good ol' 3.6.5.1, but I
will try what u have suggested. Maybe my module was not built correctly.

Nemanja

On Mon, Nov 30, 2015 at 11:31 PM, David Halls 
wrote:

> Hi Nemanja, Marcus,
>
>
>
> Did you get anywhere with this issue?
>
>
>
> We have an equivalent problem that sprung up with one of our flow graphs,
> seemingly randomly. We’re not sure what changed…! We then found that *any*
> of our blocks that used MSG input or output ports gave equivalent errors
> when in even the simplest of flowgraphs. The same does not happen with GR
> blocks.
>
>
>
> By rebuilding our whole out of tree module, the problem seems to have gone
> away. For now. Strange…
>
>
>
> Also strange is when I click ‘reload blocks’, all MSG connection arrows
> are deleted and have to be redrawn.
>
>
>
> Regards,
>
>
>
> David
>
>
>
> *From:* discuss-gnuradio-bounces+david.halls=toshiba-trel....@gnu.org
> [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] *On
> Behalf Of *Nemanja Savic
> *Sent:* 05 November 2015 12:20
> *To:* Marcus Müller 
> *Cc:* GNURadio Discussion List 
> *Subject:* Re: [Discuss-gnuradio] message port declaration problem after
> changing to 3.7.8
>
>
>
> Hi,
>
> here is a simple photo representing my block. The block is hierarchical
> and consists of a few deframers. When deframers decode correct message,
> they are supposed to send message to db_logger who write information from
> the message into a database. Deframers are written in c++ while db_logger
> is written in python. All deframers have output port whose name is
> hardcoded to "out_port", while db_logger has input port whose name was
> hardcoded as "in_port"
>
> In previous case, self is db_logger. I have shown there how the message
> port inside that block was defined.
>
>
> Inside hier block where everything is packed I have lines like this
> self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger,
> in_port)
>
> here self references hier block.
>
> Cheers,
>
> Nemanja
>
>
>
> On Wed, Nov 4, 2015 at 10:49 PM, Marcus Müller 
> wrote:
>
> I've lost oversight.. is self a hier block, in this case?
>
>
>
> On 11/04/2015 06:49 PM, Nemanja Savic wrote:
>
> So, a block called db_logger is written in python and port is defined in
> following way:
> self.message_port_register_in(pmt.pmt_intern(in_port))
>
> Well, I am not sure, this works fine in older version.
>
>
>
> On Wed, Nov 4, 2015 at 6:41 PM, Marcus Müller 
> wrote:
>
> What does your message_port_register_in call look like?
> Or is it a message_port_register_hier_in call? (should it be?)
>
> Cheers,
> Marcus
>
>
>
> On 11/04/2015 06:37 PM, Nemanja Savic wrote:
>
> Hi,
>
> ok thanks. Does it matter how I everything is declared, but it is clear
> that something changed since 3.6.5.1.
>
> So i have hier block written in python where i define
>
> in_port = 'in_port'
>
> out_port='out_port'
>
> These arguments are passed in the following way:
>
> in_port is receiving port of a block that receives messages from blocks
> which have registered out_block as their transmitting port.
>
> out_port is passed to constructors of all transmitting blocks. They are
> passed as type const char*. Blocks have member d_msg_out_port defined as
> string. So something like this:
> d_msg_out_port(msg_out_port)
> ...
>
> body of constructor:
> message_port_register_out(pmt::mp(d_msg_out_port));
>
> So, later on, at the end of hier block I call:
> self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger,
> in_port)
>
> Could it be that problem is something with strings (I am not sure is null
> character is passed, no idea)?
>
> Nemanja
>
>
>
> On Wed, Nov 4, 2015 at 6:26 PM, Marcus Müller 
> wrote:
>
> Hi,
>
> not really, what it says is really "I can't find  in  elements>", with that list being the names of the registered ports.
> So, the interesting thing is that seemingly,comparin
> pmt::symbol("in_port") with pmt::symbol("in_port") doesn't quite work well.
>
> I'd have to look into what pmt::comparator looks like; it's my first
> suspect for why that might fail.
>
> Best regards,
> Marcus
>
>
>
> On 11/04/2015 06:20 PM, Nemanja Savic wrote:
>
> Hi,
>
> hm, could just tell me if I am thinking wrong, but this looks like some of
> my blocks is also called in_port?
>
> Nemanja
>
>
>
> On Wed, Nov 4, 2015 at 6:14 PM, Marcus

Re: [Discuss-gnuradio] undefined reference to file_sink_base

[Nemanja Savic]

Hello,

thanx Alexandre, that's what i was looking for.
So with your suggestion the line looks like this:

/usr/bin/c++   -O3 -DNDEBUGCMakeFiles/test-TMS.dir/test_TMS.cc.o
CMakeFiles/test-TMS.dir/qa_TMS.cc.o  -o test-TMS -rdynamic
/usr/local/lib64/libgnuradio-core.so -lboost_filesystem-mt
-lboost_system-mt -lcppunit -ldl libgnuradio-TMS.so -lboost_filesystem-mt
-lboost_system-mt /usr/local/lib64/libgruel.so
/usr/local/lib64/libgnuradio-blocks.so /usr/local/lib64/libgnuradio-core.so
-Wl,-rpath,/scr1/work/gnuradio/gr-TMS/build/lib:/usr/local/lib64

part /usr/local/lib64/libgnuradio-blocks.so was added by me and it pased
linking. Before, that part was missing. The mistery is why it was missing.

Nemanja

On Fri, Nov 6, 2015 at 7:43 PM, Alexandre Raymond <
alexandre.j.raym...@gmail.com> wrote:

> Hi Nemanja,
>
> You can check the commands being executed by cmake using the following
> command in your build directory:
> VERBOSE=1 make
>
> Can you post the command that builds libgnuradio-TMS.so and any
> associated messages?
>
> Regards,
> Alexandre
>
> On Fri, Nov 6, 2015 at 9:19 AM, Nemanja Savic  wrote:
> > How can I check/add -L and then path to the gnuradio blocks library in
> order
> > to force setup to use it? Or maybe I am on th ewrong way?
> >
> > On Thu, Nov 5, 2015 at 6:25 PM, Nemanja Savic 
> wrote:
> >>
> >> Tried that already a few times and nothing. Is there any so called cash
> >> where cmake can mix something up. I was recently building gnuradio
> 3.7.8 and
> >> I think that administrator also removed all my manually installed
> packages
> >> and did package reset to default.
> >>
> >> On Thu, Nov 5, 2015 at 6:17 PM, Marcus Müller  >
> >> wrote:
> >>>
> >>> Ha! good catch; after you added BLOCKS to the REQUIRED_COMPONENTS list
> in
> >>> CMake, you might want to completely delete the build/ folder and start
> anew.
> >>> CMake occasionally misses such changes.
> >>>
> >>> Best regards,
> >>> Marcus
> >>>
> >>>
> >>> On 11/05/2015 06:14 PM, Nemanja Savic wrote:
> >>>
> >>> Maybe this can help somebody to help me. So, I have my .so library
> >>> installed (from the time when building was possible ;)) Now, when I
> run ldd
> >>> on installed and built library I get following:
> >>> existing:
> >>> [savi_ne@ts-070046nl build]$ ldd /usr/local/lib64/libgnuradio-TMS.so
> >>> linux-vdso.so.1 =>  (0x7ffd0cfab000)
> >>> libboost_filesystem-mt.so.5 =>
> /usr/lib64/libboost_filesystem-mt.so.5
> >>> (0x7f75c9b01000)
> >>> libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5
> >>> (0x7f75c98fd000)
> >>> libgruel-3.6.5.1.so.0.0.0 =>
> >>> /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0 (0x7f75c96b7000)
> >>> libgnuradio-core-3.6.5.1.so.0.0.0 =>
> >>> /usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x7f75c9221000)
> >>> libgnuradio-blocks-3.6.5.1.so.0.0.0 =>
> >>> /usr/local/lib64/libgnuradio-blocks-3.6.5.1.so.0.0.0
> (0x7f75c8e2b000)
> >>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7f75c8b25000)
> >>> libm.so.6 => /lib64/libm.so.6 (0x7f75c88a1000)
> >>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f75c868a000)
> >>> libc.so.6 => /lib64/libc.so.6 (0x7f75c82f6000)
> >>> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f75c80d9000)
> >>> librt.so.1 => /lib64/librt.so.1 (0x7f75c7ed)
> >>> libboost_date_time-mt.so.5 => /usr/lib64/libboost_date_time-mt.so.5
> >>> (0x7f75c7cbe000)
> >>> libboost_program_options-mt.so.5 =>
> >>> /usr/lib64/libboost_program_options-mt.so.5 (0x7f75c7a71000)
> >>> libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5
> >>> (0x7f75c785b000)
> >>> libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x7f75c7565000)
> >>> libfftw3f_threads.so.3 => /usr/lib64/libfftw3f_threads.so.3
> >>> (0x7f75c735f000)
> >>> libvolk.so.0.0.0 => /usr/local/lib64/libvolk.so.0.0.0
> >>> (0x7f75c7049000)
> >>> libdl.so.2 => /lib64/libdl.so.2 (0x7f75c6e45000)
> >>> liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x7f75c6bc5000)
> >>> /lib64/ld-linux-x86-64.so.2 (0x7f75c9fbd000)
> >>>
> >>> The one that makses prob

Re: [Discuss-gnuradio] undefined reference to file_sink_base

[Nemanja Savic]

How can I check/add -L and then path to the gnuradio blocks library in
order to force setup to use it? Or maybe I am on th ewrong way?

On Thu, Nov 5, 2015 at 6:25 PM, Nemanja Savic  wrote:

> Tried that already a few times and nothing. Is there any so called cash
> where cmake can mix something up. I was recently building gnuradio 3.7.8
> and I think that administrator also removed all my manually installed
> packages and did package reset to default.
>
> On Thu, Nov 5, 2015 at 6:17 PM, Marcus Müller 
> wrote:
>
>> Ha! good catch; after you added BLOCKS to the REQUIRED_COMPONENTS list in
>> CMake, you might want to completely delete the build/ folder and start
>> anew. CMake occasionally misses such changes.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 11/05/2015 06:14 PM, Nemanja Savic wrote:
>>
>> Maybe this can help somebody to help me. So, I have my .so library
>> installed (from the time when building was possible ;)) Now, when I run ldd
>> on installed and built library I get following:
>> existing:
>> [savi_ne@ts-070046nl build]$ ldd /usr/local/lib64/libgnuradio-TMS.so
>> linux-vdso.so.1 =>  (0x7ffd0cfab000)
>> libboost_filesystem-mt.so.5 => /usr/lib64/libboost_filesystem-mt.so.5
>> (0x7f75c9b01000)
>> libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5
>> (0x7f75c98fd000)
>> libgruel-3.6.5.1.so.0.0.0 =>
>> /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0 (0x7f75c96b7000)
>> libgnuradio-core-3.6.5.1.so.0.0.0 =>
>> /usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x7f75c9221000)
>> libgnuradio-blocks-3.6.5.1.so.0.0.0 =>
>> /usr/local/lib64/libgnuradio-blocks-3.6.5.1.so.0.0.0 (0x7f75c8e2b000)
>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7f75c8b25000)
>> libm.so.6 => /lib64/libm.so.6 (0x7f75c88a1000)
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f75c868a000)
>> libc.so.6 => /lib64/libc.so.6 (0x7f75c82f6000)
>> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f75c80d9000)
>> librt.so.1 => /lib64/librt.so.1 (0x7f75c7ed)
>> libboost_date_time-mt.so.5 => /usr/lib64/libboost_date_time-mt.so.5
>> (0x7f75c7cbe000)
>> libboost_program_options-mt.so.5 =>
>> /usr/lib64/libboost_program_options-mt.so.5 (0x7f75c7a71000)
>> libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5
>> (0x7f75c785b000)
>> libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x7f75c7565000)
>> libfftw3f_threads.so.3 => /usr/lib64/libfftw3f_threads.so.3
>> (0x7f75c735f000)
>> libvolk.so.0.0.0 => /usr/local/lib64/libvolk.so.0.0.0
>> (0x7f75c7049000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x7f75c6e45000)
>> liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x7f75c6bc5000)
>> /lib64/ld-linux-x86-64.so.2 (0x7f75c9fbd000)
>>
>> The one that makses problem:
>> [savi_ne@ts-070046nl build]$ ldd lib/libgnuradio-TMS.so
>> linux-vdso.so.1 =>  (0x7fff83398000)
>> libboost_filesystem-mt.so.5 => /usr/lib64/libboost_filesystem-mt.so.5
>> (0x7f42e79bd000)
>> libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5
>> (0x7f42e77b9000)
>> libgruel-3.6.5.1.so.0.0.0 =>
>> /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0 (0x7f42e7573000)
>> libgnuradio-core-3.6.5.1.so.0.0.0 =>
>> /usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x7f42e70dd000)
>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7f42e6dd6000)
>> libm.so.6 => /lib64/libm.so.6 (0x7f42e6b52000)
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f42e693c000)
>> libc.so.6 => /lib64/libc.so.6 (0x7f42e65a7000)
>> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f42e638a000)
>> librt.so.1 => /lib64/librt.so.1 (0x7f42e6182000)
>> libboost_date_time-mt.so.5 => /usr/lib64/libboost_date_time-mt.so.5
>> (0x7f42e5f6f000)
>> libboost_program_options-mt.so.5 =>
>> /usr/lib64/libboost_program_options-mt.so.5 (0x7f42e5d22000)
>> libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5
>> (0x7f42e5b0d000)
>> libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x7f42e5816000)
>> libfftw3f_threads.so.3 => /usr/lib64/libfftw3f_threads.so.3
>> (0x7f42e561)
>> libvolk.so.0.0.0 => /usr/local/lib64/libvolk.so.0.0.0
>> (0x7f42e52fb000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x7f42e50f6000)
>> liborc-0.4.so.0 => /usr/lib

Re: [Discuss-gnuradio] undefined reference to file_sink_base

[Nemanja Savic]

Tried that already a few times and nothing. Is there any so called cash
where cmake can mix something up. I was recently building gnuradio 3.7.8
and I think that administrator also removed all my manually installed
packages and did package reset to default.

On Thu, Nov 5, 2015 at 6:17 PM, Marcus Müller 
wrote:

> Ha! good catch; after you added BLOCKS to the REQUIRED_COMPONENTS list in
> CMake, you might want to completely delete the build/ folder and start
> anew. CMake occasionally misses such changes.
>
> Best regards,
> Marcus
>
>
> On 11/05/2015 06:14 PM, Nemanja Savic wrote:
>
> Maybe this can help somebody to help me. So, I have my .so library
> installed (from the time when building was possible ;)) Now, when I run ldd
> on installed and built library I get following:
> existing:
> [savi_ne@ts-070046nl build]$ ldd /usr/local/lib64/libgnuradio-TMS.so
> linux-vdso.so.1 =>  (0x7ffd0cfab000)
> libboost_filesystem-mt.so.5 => /usr/lib64/libboost_filesystem-mt.so.5
> (0x7f75c9b01000)
> libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5
> (0x7f75c98fd000)
> libgruel-3.6.5.1.so.0.0.0 =>
> /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0 (0x7f75c96b7000)
> libgnuradio-core-3.6.5.1.so.0.0.0 =>
> /usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x7f75c9221000)
> libgnuradio-blocks-3.6.5.1.so.0.0.0 =>
> /usr/local/lib64/libgnuradio-blocks-3.6.5.1.so.0.0.0 (0x7f75c8e2b000)
> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7f75c8b25000)
> libm.so.6 => /lib64/libm.so.6 (0x7f75c88a1000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f75c868a000)
> libc.so.6 => /lib64/libc.so.6 (0x7f75c82f6000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f75c80d9000)
> librt.so.1 => /lib64/librt.so.1 (0x7f75c7ed)
> libboost_date_time-mt.so.5 => /usr/lib64/libboost_date_time-mt.so.5
> (0x7f75c7cbe000)
> libboost_program_options-mt.so.5 =>
> /usr/lib64/libboost_program_options-mt.so.5 (0x7f75c7a71000)
> libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5
> (0x7f75c785b000)
> libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x7f75c7565000)
> libfftw3f_threads.so.3 => /usr/lib64/libfftw3f_threads.so.3
> (0x7f75c735f000)
> libvolk.so.0.0.0 => /usr/local/lib64/libvolk.so.0.0.0
> (0x7f75c7049000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7f75c6e45000)
> liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x7f75c6bc5000)
> /lib64/ld-linux-x86-64.so.2 (0x7f75c9fbd000)
>
> The one that makses problem:
> [savi_ne@ts-070046nl build]$ ldd lib/libgnuradio-TMS.so
> linux-vdso.so.1 =>  (0x7fff83398000)
> libboost_filesystem-mt.so.5 => /usr/lib64/libboost_filesystem-mt.so.5
> (0x7f42e79bd000)
> libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5
> (0x7f42e77b9000)
> libgruel-3.6.5.1.so.0.0.0 =>
> /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0 (0x7f42e7573000)
> libgnuradio-core-3.6.5.1.so.0.0.0 =>
> /usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x7f42e70dd000)
> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7f42e6dd6000)
> libm.so.6 => /lib64/libm.so.6 (0x7f42e6b52000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f42e693c000)
> libc.so.6 => /lib64/libc.so.6 (0x7f42e65a7000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f42e638a000)
> librt.so.1 => /lib64/librt.so.1 (0x7f42e6182000)
> libboost_date_time-mt.so.5 => /usr/lib64/libboost_date_time-mt.so.5
> (0x7f42e5f6f000)
> libboost_program_options-mt.so.5 =>
> /usr/lib64/libboost_program_options-mt.so.5 (0x7f42e5d22000)
> libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5
> (0x7f42e5b0d000)
> libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x7f42e5816000)
> libfftw3f_threads.so.3 => /usr/lib64/libfftw3f_threads.so.3
> (0x7f42e561)
> libvolk.so.0.0.0 => /usr/local/lib64/libvolk.so.0.0.0
> (0x7f42e52fb000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7f42e50f6000)
> liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x7f42e4e76000)
> /lib64/ld-linux-x86-64.so.2 (0x7f42e7e5e000)
>
> As you can see, I marke with red, the complete line about blocks library
> is missing in the newly built library.
>
> Cheers and thanx
>
> On Thu, Nov 5, 2015 at 5:53 PM, Marcus Müller 
> wrote:
>
>> Hm, that really was my hope. Sorry, I'm out of ideas.
>>
>> On 11/05/2015 05:39 PM, Nemanja Savic wrote:
>> > everything looks fine with that
>> >
>&

Re: [Discuss-gnuradio] undefined reference to file_sink_base

[Nemanja Savic]

Maybe this can help somebody to help me. So, I have my .so library
installed (from the time when building was possible ;)) Now, when I run ldd
on installed and built library I get following:
existing:
[savi_ne@ts-070046nl build]$ ldd /usr/local/lib64/libgnuradio-TMS.so
linux-vdso.so.1 =>  (0x7ffd0cfab000)
libboost_filesystem-mt.so.5 => /usr/lib64/libboost_filesystem-mt.so.5
(0x7f75c9b01000)
libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5
(0x7f75c98fd000)
libgruel-3.6.5.1.so.0.0.0 => /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0
(0x7f75c96b7000)
libgnuradio-core-3.6.5.1.so.0.0.0 =>
/usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x7f75c9221000)
libgnuradio-blocks-3.6.5.1.so.0.0.0 =>
/usr/local/lib64/libgnuradio-blocks-3.6.5.1.so.0.0.0 (0x7f75c8e2b000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7f75c8b25000)
libm.so.6 => /lib64/libm.so.6 (0x7f75c88a1000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f75c868a000)
libc.so.6 => /lib64/libc.so.6 (0x7f75c82f6000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f75c80d9000)
librt.so.1 => /lib64/librt.so.1 (0x7f75c7ed)
libboost_date_time-mt.so.5 => /usr/lib64/libboost_date_time-mt.so.5
(0x7f75c7cbe000)
libboost_program_options-mt.so.5 =>
/usr/lib64/libboost_program_options-mt.so.5 (0x7f75c7a71000)
libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5
(0x7f75c785b000)
libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x7f75c7565000)
libfftw3f_threads.so.3 => /usr/lib64/libfftw3f_threads.so.3
(0x7f75c735f000)
libvolk.so.0.0.0 => /usr/local/lib64/libvolk.so.0.0.0
(0x7f75c7049000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f75c6e45000)
liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x7f75c6bc5000)
/lib64/ld-linux-x86-64.so.2 (0x7f75c9fbd000)

The one that makses problem:
[savi_ne@ts-070046nl build]$ ldd lib/libgnuradio-TMS.so
linux-vdso.so.1 =>  (0x7fff83398000)
libboost_filesystem-mt.so.5 => /usr/lib64/libboost_filesystem-mt.so.5
(0x7f42e79bd000)
libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5
(0x7f42e77b9000)
libgruel-3.6.5.1.so.0.0.0 => /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0
(0x7f42e7573000)
libgnuradio-core-3.6.5.1.so.0.0.0 =>
/usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x7f42e70dd000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7f42e6dd6000)
libm.so.6 => /lib64/libm.so.6 (0x7f42e6b52000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f42e693c000)
libc.so.6 => /lib64/libc.so.6 (0x7f42e65a7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f42e638a000)
librt.so.1 => /lib64/librt.so.1 (0x7f42e6182000)
libboost_date_time-mt.so.5 => /usr/lib64/libboost_date_time-mt.so.5
(0x7f42e5f6f000)
libboost_program_options-mt.so.5 =>
/usr/lib64/libboost_program_options-mt.so.5 (0x7f42e5d22000)
libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5
(0x7f42e5b0d000)
libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x7f42e5816000)
libfftw3f_threads.so.3 => /usr/lib64/libfftw3f_threads.so.3
(0x7f42e561)
libvolk.so.0.0.0 => /usr/local/lib64/libvolk.so.0.0.0
(0x7f42e52fb000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f42e50f6000)
liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x7f42e4e76000)
/lib64/ld-linux-x86-64.so.2 (0x7f42e7e5e000)

As you can see, I marke with red, the complete line about blocks library is
missing in the newly built library.

Cheers and thanx

On Thu, Nov 5, 2015 at 5:53 PM, Marcus Müller 
wrote:

> Hm, that really was my hope. Sorry, I'm out of ideas.
>
> On 11/05/2015 05:39 PM, Nemanja Savic wrote:
> > everything looks fine with that
> >
> > [savi_ne@ts-070046nl build]$ ldd lib/libgnuradio-TMS.so
> > linux-vdso.so.1 =>  (0x7ffd93fa1000)
> > libboost_filesystem-mt.so.5 => /usr/lib64/libboost_filesystem-mt.so.5
> > (0x7fccb7e5f000)
> > libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5
> > (0x7fccb7c5b000)
> > libgruel-3.6.5.1.so.0.0.0 =>
> /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0
> > (0x7fccb7a15000)
> > libgnuradio-core-3.6.5.1.so.0.0.0 =>
> > /usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x7fccb757f000)
> > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7fccb7278000)
> > libm.so.6 => /lib64/libm.so.6 (0x7fccb6ff4000)
> > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fccb6dde000)
> > libc.so.6 => /lib64/libc.so.6 (0x7fccb6a49000)
> > libpthread.so.0 => /lib64/libpthread.so.0 (0x7fccb682c000)
> > librt.so.1 => /lib64/librt.so.1 (0x00

Re: [Discuss-gnuradio] undefined reference to file_sink_base

[Nemanja Savic]

everything looks fine with that

[savi_ne@ts-070046nl build]$ ldd lib/libgnuradio-TMS.so
linux-vdso.so.1 =>  (0x7ffd93fa1000)
libboost_filesystem-mt.so.5 => /usr/lib64/libboost_filesystem-mt.so.5
(0x7fccb7e5f000)
libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5
(0x7fccb7c5b000)
libgruel-3.6.5.1.so.0.0.0 => /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0
(0x7fccb7a15000)
libgnuradio-core-3.6.5.1.so.0.0.0 =>
/usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x7fccb757f000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7fccb7278000)
libm.so.6 => /lib64/libm.so.6 (0x7fccb6ff4000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fccb6dde000)
libc.so.6 => /lib64/libc.so.6 (0x7fccb6a49000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7fccb682c000)
librt.so.1 => /lib64/librt.so.1 (0x7fccb6624000)
libboost_date_time-mt.so.5 => /usr/lib64/libboost_date_time-mt.so.5
(0x7fccb6411000)
libboost_program_options-mt.so.5 =>
/usr/lib64/libboost_program_options-mt.so.5 (0x7fccb61c4000)
libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5
(0x7fccb5faf000)
libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x7fccb5cb8000)
libfftw3f_threads.so.3 => /usr/lib64/libfftw3f_threads.so.3
(0x7fccb5ab2000)
libvolk.so.0.0.0 => /usr/local/lib64/libvolk.so.0.0.0
(0x7fccb579d000)
libdl.so.2 => /lib64/libdl.so.2 (0x7fccb5598000)
liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x7fccb5318000)
/lib64/ld-linux-x86-64.so.2 (0x7fccb830)

Core library is there I checked. I also tried with nm to look for symbols
inside core library and they are really there.


On Thu, Nov 5, 2015 at 5:29 PM, Marcus Müller 
wrote:

> Hm, make sure your program really uses those; "ldd libgnuradio-TMS.so"
> might point to the right places.
>
> On 11/05/2015 05:21 PM, Nemanja Savic wrote:
> > Anything else I could try with this silly problem? I am sure 100% that
> > libraries are in /usr/local/lib64
> >
> > On Thu, Nov 5, 2015 at 5:12 PM, Nemanja Savic 
> wrote:
> >
> >> In my gnuradio 3.6.5.1 file_sink_base constructor takes otwo arguments,
> >> filename and bool.
> >>
> >> On Thu, Nov 5, 2015 at 5:06 PM, Marcus Müller  >
> >> wrote:
> >>
> >>> Does it get better when you do blocks::file_sink_base(filename, true,
> >>> false)?
> >>>
> >>>
> >>> On 11/05/2015 05:04 PM, Nemanja Savic wrote:
> >>>
> >>> This is rather strange. This module was working ok, I just didn't build
> >>> it for quite some time.
> >>> I use file_sink_base as a base class for one of my file sinks that has
> >>> some kind of history buffer inside.
> >>> And, the structure of that block is identical as the structure of
> >>> file_sink that comes with GR.
> >>> So my block is defined as
> >>> class TMS_API file_sink_lim_b : virtual public gr_sync_block,
> >>>  virtual public
> blocks::file_sink_base
> >>>
> >>> pretty much as normal file sink, except I have blocks:: namsespace.
> >>> Inside the constructor is also the same:
> >>> blocks::file_sink_base(filename, true).
> >>>
> >>>
> >>>
> >>> On Thu, Nov 5, 2015 at 3:57 PM, Marcus Müller <
> marcus.muel...@ettus.com>
> >>> wrote:
> >>>
> >>>> Hi Nemanja,
> >>>>
> >>>> file_sink_base only has a parameterless public constructor these days
> >>>> (from gr-blocks/include/.../file_sink_base.h)
> >>>>  47 protected:
> >>>>  48   file_sink_base(const char *filename, bool is_binary, bool
> >>>> append);
> >>>>  49
> >>>>  50 public:
> >>>>  51   file_sink_base() {}
> >>>>  52   ~file_sink_base();
> >>>>  53
> >>>> and the protected one takes a second bool now.
> >>>> That doesn't explain the problems with the d'tor and do_update, but
> >>>> maybe it's a start.
> >>>>
> >>>> Best regards,
> >>>> Marcus
> >>>>
> >>>>
> >>>> On 11/05/2015 01:50 PM, Nemanja Savic wrote:
> >>>>
> >>>> Hi all guys,
> >>>>
> >>>> i have encountered a new problem which was not present before. I have
> my
> >>>&g

Re: [Discuss-gnuradio] undefined reference to file_sink_base

[Nemanja Savic]

Anything else I could try with this silly problem? I am sure 100% that
libraries are in /usr/local/lib64

On Thu, Nov 5, 2015 at 5:12 PM, Nemanja Savic  wrote:

> In my gnuradio 3.6.5.1 file_sink_base constructor takes otwo arguments,
> filename and bool.
>
> On Thu, Nov 5, 2015 at 5:06 PM, Marcus Müller 
> wrote:
>
>> Does it get better when you do blocks::file_sink_base(filename, true,
>> false)?
>>
>>
>> On 11/05/2015 05:04 PM, Nemanja Savic wrote:
>>
>> This is rather strange. This module was working ok, I just didn't build
>> it for quite some time.
>> I use file_sink_base as a base class for one of my file sinks that has
>> some kind of history buffer inside.
>> And, the structure of that block is identical as the structure of
>> file_sink that comes with GR.
>> So my block is defined as
>> class TMS_API file_sink_lim_b : virtual public gr_sync_block,
>>  virtual public blocks::file_sink_base
>>
>> pretty much as normal file sink, except I have blocks:: namsespace.
>> Inside the constructor is also the same:
>> blocks::file_sink_base(filename, true).
>>
>>
>>
>> On Thu, Nov 5, 2015 at 3:57 PM, Marcus Müller 
>> wrote:
>>
>>> Hi Nemanja,
>>>
>>> file_sink_base only has a parameterless public constructor these days
>>> (from gr-blocks/include/.../file_sink_base.h)
>>>  47 protected:
>>>  48   file_sink_base(const char *filename, bool is_binary, bool
>>> append);
>>>  49
>>>  50 public:
>>>  51   file_sink_base() {}
>>>  52   ~file_sink_base();
>>>  53
>>> and the protected one takes a second bool now.
>>> That doesn't explain the problems with the d'tor and do_update, but
>>> maybe it's a start.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 11/05/2015 01:50 PM, Nemanja Savic wrote:
>>>
>>> Hi all guys,
>>>
>>> i have encountered a new problem which was not present before. I have my
>>> old GR module (out of tree) for years. Yesterday I wanted to change
>>> something and couldn't build it cause of the linker error.
>>>
>>> libgnuradio-TMS.so: undefined reference to
>>> `gr::blocks::file_sink_base::file_sink_base(char const*, bool)'
>>> libgnuradio-TMS.so: undefined reference to
>>> `gr::blocks::file_sink_base::~file_sink_base()'
>>> libgnuradio-TMS.so: undefined reference to
>>> `gr::blocks::file_sink_base::do_update()'
>>>
>>> I know that before, I had similar error on some other machine, so I
>>> added lines:
>>>
>>> set(GR_REQUIRED_COMPONENTS CORE BLOCKS)
>>> find_package(Gnuradio "3.6.5.1")
>>>
>>> in my top CMakeLists.txt file but unfortunately nothing changed. I am
>>> sure that everything is there, but can't figure out why it can't find it.
>>>
>>> Cheers and thanx,
>>> --
>>> Nemanja Savić
>>>
>>>
>>> ___
>>> 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
>>>
>>>
>>
>>
>> --
>> Nemanja Savić
>>
>>
>>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] undefined reference to file_sink_base

[Nemanja Savic]

This is rather strange. This module was working ok, I just didn't build it
for quite some time.
I use file_sink_base as a base class for one of my file sinks that has some
kind of history buffer inside.
And, the structure of that block is identical as the structure of file_sink
that comes with GR.
So my block is defined as
class TMS_API file_sink_lim_b : virtual public gr_sync_block,
 virtual public blocks::file_sink_base

pretty much as normal file sink, except I have blocks:: namsespace. Inside
the constructor is also the same:
blocks::file_sink_base(filename, true).



On Thu, Nov 5, 2015 at 3:57 PM, Marcus Müller 
wrote:

> Hi Nemanja,
>
> file_sink_base only has a parameterless public constructor these days
> (from gr-blocks/include/.../file_sink_base.h)
>  47 protected:
>  48   file_sink_base(const char *filename, bool is_binary, bool
> append);
>  49
>  50 public:
>  51   file_sink_base() {}
>  52   ~file_sink_base();
>  53
> and the protected one takes a second bool now.
> That doesn't explain the problems with the d'tor and do_update, but maybe
> it's a start.
>
> Best regards,
> Marcus
>
>
> On 11/05/2015 01:50 PM, Nemanja Savic wrote:
>
> Hi all guys,
>
> i have encountered a new problem which was not present before. I have my
> old GR module (out of tree) for years. Yesterday I wanted to change
> something and couldn't build it cause of the linker error.
>
> libgnuradio-TMS.so: undefined reference to
> `gr::blocks::file_sink_base::file_sink_base(char const*, bool)'
> libgnuradio-TMS.so: undefined reference to
> `gr::blocks::file_sink_base::~file_sink_base()'
> libgnuradio-TMS.so: undefined reference to
> `gr::blocks::file_sink_base::do_update()'
>
> I know that before, I had similar error on some other machine, so I added
> lines:
>
> set(GR_REQUIRED_COMPONENTS CORE BLOCKS)
> find_package(Gnuradio "3.6.5.1")
>
> in my top CMakeLists.txt file but unfortunately nothing changed. I am sure
> that everything is there, but can't figure out why it can't find it.
>
> Cheers and thanx,
> --
> Nemanja Savić
>
>
> ___
> 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
>
>


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

Re: [Discuss-gnuradio] undefined reference to file_sink_base

[Nemanja Savic]

In my gnuradio 3.6.5.1 file_sink_base constructor takes otwo arguments,
filename and bool.

On Thu, Nov 5, 2015 at 5:06 PM, Marcus Müller 
wrote:

> Does it get better when you do blocks::file_sink_base(filename, true,
> false)?
>
>
> On 11/05/2015 05:04 PM, Nemanja Savic wrote:
>
> This is rather strange. This module was working ok, I just didn't build it
> for quite some time.
> I use file_sink_base as a base class for one of my file sinks that has
> some kind of history buffer inside.
> And, the structure of that block is identical as the structure of
> file_sink that comes with GR.
> So my block is defined as
> class TMS_API file_sink_lim_b : virtual public gr_sync_block,
>  virtual public blocks::file_sink_base
>
> pretty much as normal file sink, except I have blocks:: namsespace. Inside
> the constructor is also the same:
> blocks::file_sink_base(filename, true).
>
>
>
> On Thu, Nov 5, 2015 at 3:57 PM, Marcus Müller 
> wrote:
>
>> Hi Nemanja,
>>
>> file_sink_base only has a parameterless public constructor these days
>> (from gr-blocks/include/.../file_sink_base.h)
>>  47 protected:
>>  48   file_sink_base(const char *filename, bool is_binary, bool
>> append);
>>  49
>>  50 public:
>>  51   file_sink_base() {}
>>  52   ~file_sink_base();
>>  53
>> and the protected one takes a second bool now.
>> That doesn't explain the problems with the d'tor and do_update, but maybe
>> it's a start.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 11/05/2015 01:50 PM, Nemanja Savic wrote:
>>
>> Hi all guys,
>>
>> i have encountered a new problem which was not present before. I have my
>> old GR module (out of tree) for years. Yesterday I wanted to change
>> something and couldn't build it cause of the linker error.
>>
>> libgnuradio-TMS.so: undefined reference to
>> `gr::blocks::file_sink_base::file_sink_base(char const*, bool)'
>> libgnuradio-TMS.so: undefined reference to
>> `gr::blocks::file_sink_base::~file_sink_base()'
>> libgnuradio-TMS.so: undefined reference to
>> `gr::blocks::file_sink_base::do_update()'
>>
>> I know that before, I had similar error on some other machine, so I added
>> lines:
>>
>> set(GR_REQUIRED_COMPONENTS CORE BLOCKS)
>> find_package(Gnuradio "3.6.5.1")
>>
>> in my top CMakeLists.txt file but unfortunately nothing changed. I am
>> sure that everything is there, but can't figure out why it can't find it.
>>
>> Cheers and thanx,
>> --
>> Nemanja Savić
>>
>>
>> ___
>> 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
>>
>>
>
>
> --
> Nemanja Savić
>
>
>


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

[Discuss-gnuradio] undefined reference to file_sink_base

[Nemanja Savic]

Hi all guys,

i have encountered a new problem which was not present before. I have my
old GR module (out of tree) for years. Yesterday I wanted to change
something and couldn't build it cause of the linker error.

libgnuradio-TMS.so: undefined reference to
`gr::blocks::file_sink_base::file_sink_base(char const*, bool)'
libgnuradio-TMS.so: undefined reference to
`gr::blocks::file_sink_base::~file_sink_base()'
libgnuradio-TMS.so: undefined reference to
`gr::blocks::file_sink_base::do_update()'

I know that before, I had similar error on some other machine, so I added
lines:

set(GR_REQUIRED_COMPONENTS CORE BLOCKS)
find_package(Gnuradio "3.6.5.1")

in my top CMakeLists.txt file but unfortunately nothing changed. I am sure
that everything is there, but can't figure out why it can't find it.

Cheers and thanx,
-- 
Nemanja Savić
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] message port declaration problem after changing to 3.7.8

[Nemanja Savic]

Hi,

here is a simple photo representing my block. The block is hierarchical and
consists of a few deframers. When deframers decode correct message, they
are supposed to send message to db_logger who write information from the
message into a database. Deframers are written in c++ while db_logger is
written in python. All deframers have output port whose name is hardcoded
to "out_port", while db_logger has input port whose name was hardcoded as
"in_port"

In previous case, self is db_logger. I have shown there how the message
port inside that block was defined.

Inside hier block where everything is packed I have lines like this
self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger,
in_port)
here self references hier block.

Cheers,
Nemanja

On Wed, Nov 4, 2015 at 10:49 PM, Marcus Müller 
wrote:

> I've lost oversight.. is self a hier block, in this case?
>
>
> On 11/04/2015 06:49 PM, Nemanja Savic wrote:
>
> So, a block called db_logger is written in python and port is defined in
> following way:
> self.message_port_register_in(pmt.pmt_intern(in_port))
>
> Well, I am not sure, this works fine in older version.
>
> On Wed, Nov 4, 2015 at 6:41 PM, Marcus Müller 
> wrote:
>
>> What does your message_port_register_in call look like?
>> Or is it a message_port_register_hier_in call? (should it be?)
>>
>> Cheers,
>> Marcus
>>
>>
>> On 11/04/2015 06:37 PM, Nemanja Savic wrote:
>>
>> Hi,
>>
>> ok thanks. Does it matter how I everything is declared, but it is clear
>> that something changed since 3.6.5.1.
>> So i have hier block written in python where i define
>> in_port = 'in_port'
>> out_port='out_port'
>>
>> These arguments are passed in the following way:
>> in_port is receiving port of a block that receives messages from blocks
>> which have registered out_block as their transmitting port.
>> out_port is passed to constructors of all transmitting blocks. They are
>> passed as type const char*. Blocks have member d_msg_out_port defined as
>> string. So something like this:
>> d_msg_out_port(msg_out_port)
>> ...
>> body of constructor:
>> message_port_register_out(pmt::mp(d_msg_out_port));
>>
>> So, later on, at the end of hier block I call:
>> self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger,
>> in_port)
>>
>> Could it be that problem is something with strings (I am not sure is null
>> character is passed, no idea)?
>>
>> Nemanja
>>
>> On Wed, Nov 4, 2015 at 6:26 PM, Marcus Müller 
>> wrote:
>>
>>> Hi,
>>>
>>> not really, what it says is really "I can't find  in >> elements>", with that list being the names of the registered ports.
>>> So, the interesting thing is that seemingly,comparin
>>> pmt::symbol("in_port") with pmt::symbol("in_port") doesn't quite work well.
>>>
>>> I'd have to look into what pmt::comparator looks like; it's my first
>>> suspect for why that might fail.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>>
>>> On 11/04/2015 06:20 PM, Nemanja Savic wrote:
>>>
>>> Hi,
>>>
>>> hm, could just tell me if I am thinking wrong, but this looks like some
>>> of my blocks is also called in_port?
>>>
>>> Nemanja
>>>
>>> On Wed, Nov 4, 2015 at 6:14 PM, Marcus Müller 
>>> wrote:
>>>
>>>> Hi Nemanja,
>>>>
>>>> a blind suspicion: as "system" is a port that should be registered by
>>>> the runtime for each block, there might be some confusion happening.
>>>> Does it work better when you rename your block to something else?
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>> On 11/04/2015 06:05 PM, Nemanja Savic wrote:
>>>>
>>>> Hi all guys,
>>>>
>>>> I recently installed 3.7.8, and before that I had 3.6.5.1.
>>>> I was using message passing in some of my blocks, but now I get error
>>>> which is following:
>>>>
>>>> Could not find port: in_port in:
>>>> in_port
>>>> system
>>>>
>>>> Traceback (most recent call last):
>>>>   File "./top_block.py", line 178, in 
>>>> tb = top_block()
>>>>   File "./top_block.py", line 124, in __init__
>>>> self.TPMS_univ_TPMS_rec2_0 = TPMS.univ_TPMS_rec2("WBX_proba",
>>>> samp

Re: [Discuss-gnuradio] message port declaration problem after changing to 3.7.8

[Nemanja Savic]

So, a block called db_logger is written in python and port is defined in
following way:
self.message_port_register_in(pmt.pmt_intern(in_port))

Well, I am not sure, this works fine in older version.

On Wed, Nov 4, 2015 at 6:41 PM, Marcus Müller 
wrote:

> What does your message_port_register_in call look like?
> Or is it a message_port_register_hier_in call? (should it be?)
>
> Cheers,
> Marcus
>
>
> On 11/04/2015 06:37 PM, Nemanja Savic wrote:
>
> Hi,
>
> ok thanks. Does it matter how I everything is declared, but it is clear
> that something changed since 3.6.5.1.
> So i have hier block written in python where i define
> in_port = 'in_port'
> out_port='out_port'
>
> These arguments are passed in the following way:
> in_port is receiving port of a block that receives messages from blocks
> which have registered out_block as their transmitting port.
> out_port is passed to constructors of all transmitting blocks. They are
> passed as type const char*. Blocks have member d_msg_out_port defined as
> string. So something like this:
> d_msg_out_port(msg_out_port)
> ...
> body of constructor:
> message_port_register_out(pmt::mp(d_msg_out_port));
>
> So, later on, at the end of hier block I call:
> self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger,
> in_port)
>
> Could it be that problem is something with strings (I am not sure is null
> character is passed, no idea)?
>
> Nemanja
>
> On Wed, Nov 4, 2015 at 6:26 PM, Marcus Müller 
> wrote:
>
>> Hi,
>>
>> not really, what it says is really "I can't find  in > elements>", with that list being the names of the registered ports.
>> So, the interesting thing is that seemingly,comparin
>> pmt::symbol("in_port") with pmt::symbol("in_port") doesn't quite work well.
>>
>> I'd have to look into what pmt::comparator looks like; it's my first
>> suspect for why that might fail.
>>
>> Best regards,
>> Marcus
>>
>>
>>
>> On 11/04/2015 06:20 PM, Nemanja Savic wrote:
>>
>> Hi,
>>
>> hm, could just tell me if I am thinking wrong, but this looks like some
>> of my blocks is also called in_port?
>>
>> Nemanja
>>
>> On Wed, Nov 4, 2015 at 6:14 PM, Marcus Müller 
>> wrote:
>>
>>> Hi Nemanja,
>>>
>>> a blind suspicion: as "system" is a port that should be registered by
>>> the runtime for each block, there might be some confusion happening.
>>> Does it work better when you rename your block to something else?
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 11/04/2015 06:05 PM, Nemanja Savic wrote:
>>>
>>> Hi all guys,
>>>
>>> I recently installed 3.7.8, and before that I had 3.6.5.1.
>>> I was using message passing in some of my blocks, but now I get error
>>> which is following:
>>>
>>> Could not find port: in_port in:
>>> in_port
>>> system
>>>
>>> Traceback (most recent call last):
>>>   File "./top_block.py", line 178, in 
>>> tb = top_block()
>>>   File "./top_block.py", line 124, in __init__
>>> self.TPMS_univ_TPMS_rec2_0 = TPMS.univ_TPMS_rec2("WBX_proba",
>>> samp_rate, 0.5, 45, "localhost", 2, "TEST_TRACK_TPMS", "nemanja",
>>> "nemanja", "det_id_proba", "detectors")
>>>   File
>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/TPMS/univ_TPMS_rec2.py",
>>> line 145, in __init__
>>> self.msg_connect(self.SEL_90518407_pkt_def.SCHRADER_def, out_port,
>>> self.db_logger, in_port)
>>>   File
>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/hier_block2.py",
>>> line 59, in wrapped
>>> func(self, src.to_basic_block(), srcport, dst.to_basic_block(),
>>> dstport)
>>>   File
>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/hier_block2.py",
>>> line 131, in msg_connect
>>> self.primitive_msg_connect(*args)
>>>   File
>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/runtime_swig.py",
>>> line 3043, in primitive_msg_connect
>>> return _runtime_swig.hier_block2_sptr_primitive_msg_connect(self,
>>> *args)
>>> RuntimeError: invalid msg port in connect() or disconnect()
>>>
>>> I see that there is a function for checking whether the ports are valid,
>>> but don't get what's wrong with my ports. Namely, I have hier block and a
>>> few blocks are sending messages to a single blocks where the messages are
>>> decoded and written to darabase. I tried to hardcode names of the blocks
>>> and that also didn't help.
>>>
>>> Thanx,
>>>
>>> --
>>> Nemanja Savić
>>>
>>>
>>> ___
>>> 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
>>>
>>>
>>
>>
>> --
>> Nemanja Savić
>>
>>
>>
>
>
> --
> Nemanja Savić
>
>
>


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

Re: [Discuss-gnuradio] message port declaration problem after changing to 3.7.8

[Nemanja Savic]

Hi,

ok thanks. Does it matter how I everything is declared, but it is clear
that something changed since 3.6.5.1.
So i have hier block written in python where i define
in_port = 'in_port'
out_port='out_port'

These arguments are passed in the following way:
in_port is receiving port of a block that receives messages from blocks
which have registered out_block as their transmitting port.
out_port is passed to constructors of all transmitting blocks. They are
passed as type const char*. Blocks have member d_msg_out_port defined as
string. So something like this:
d_msg_out_port(msg_out_port)
...
body of constructor:
message_port_register_out(pmt::mp(d_msg_out_port));

So, later on, at the end of hier block I call:
self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger,
in_port)

Could it be that problem is something with strings (I am not sure is null
character is passed, no idea)?

Nemanja

On Wed, Nov 4, 2015 at 6:26 PM, Marcus Müller 
wrote:

> Hi,
>
> not really, what it says is really "I can't find  in  elements>", with that list being the names of the registered ports.
> So, the interesting thing is that seemingly,comparin
> pmt::symbol("in_port") with pmt::symbol("in_port") doesn't quite work well.
>
> I'd have to look into what pmt::comparator looks like; it's my first
> suspect for why that might fail.
>
> Best regards,
> Marcus
>
>
>
> On 11/04/2015 06:20 PM, Nemanja Savic wrote:
>
> Hi,
>
> hm, could just tell me if I am thinking wrong, but this looks like some of
> my blocks is also called in_port?
>
> Nemanja
>
> On Wed, Nov 4, 2015 at 6:14 PM, Marcus Müller 
> wrote:
>
>> Hi Nemanja,
>>
>> a blind suspicion: as "system" is a port that should be registered by the
>> runtime for each block, there might be some confusion happening.
>> Does it work better when you rename your block to something else?
>>
>> Best regards,
>> Marcus
>>
>> On 11/04/2015 06:05 PM, Nemanja Savic wrote:
>>
>> Hi all guys,
>>
>> I recently installed 3.7.8, and before that I had 3.6.5.1.
>> I was using message passing in some of my blocks, but now I get error
>> which is following:
>>
>> Could not find port: in_port in:
>> in_port
>> system
>>
>> Traceback (most recent call last):
>>   File "./top_block.py", line 178, in 
>> tb = top_block()
>>   File "./top_block.py", line 124, in __init__
>> self.TPMS_univ_TPMS_rec2_0 = TPMS.univ_TPMS_rec2("WBX_proba",
>> samp_rate, 0.5, 45, "localhost", 2, "TEST_TRACK_TPMS", "nemanja",
>> "nemanja", "det_id_proba", "detectors")
>>   File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/TPMS/univ_TPMS_rec2.py",
>> line 145, in __init__
>> self.msg_connect(self.SEL_90518407_pkt_def.SCHRADER_def, out_port,
>> self.db_logger, in_port)
>>   File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/hier_block2.py",
>> line 59, in wrapped
>> func(self, src.to_basic_block(), srcport, dst.to_basic_block(),
>> dstport)
>>   File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/hier_block2.py",
>> line 131, in msg_connect
>> self.primitive_msg_connect(*args)
>>   File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/runtime_swig.py",
>> line 3043, in primitive_msg_connect
>> return _runtime_swig.hier_block2_sptr_primitive_msg_connect(self,
>> *args)
>> RuntimeError: invalid msg port in connect() or disconnect()
>>
>> I see that there is a function for checking whether the ports are valid,
>> but don't get what's wrong with my ports. Namely, I have hier block and a
>> few blocks are sending messages to a single blocks where the messages are
>> decoded and written to darabase. I tried to hardcode names of the blocks
>> and that also didn't help.
>>
>> Thanx,
>>
>> --
>> Nemanja Savić
>>
>>
>> ___
>> 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
>>
>>
>
>
> --
> Nemanja Savić
>
>
>


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

Re: [Discuss-gnuradio] message port declaration problem after changing to 3.7.8

[Nemanja Savic]

Hi,

hm, could just tell me if I am thinking wrong, but this looks like some of
my blocks is also called in_port?

Nemanja

On Wed, Nov 4, 2015 at 6:14 PM, Marcus Müller 
wrote:

> Hi Nemanja,
>
> a blind suspicion: as "system" is a port that should be registered by the
> runtime for each block, there might be some confusion happening.
> Does it work better when you rename your block to something else?
>
> Best regards,
> Marcus
>
> On 11/04/2015 06:05 PM, Nemanja Savic wrote:
>
> Hi all guys,
>
> I recently installed 3.7.8, and before that I had 3.6.5.1.
> I was using message passing in some of my blocks, but now I get error
> which is following:
>
> Could not find port: in_port in:
> in_port
> system
>
> Traceback (most recent call last):
>   File "./top_block.py", line 178, in 
> tb = top_block()
>   File "./top_block.py", line 124, in __init__
> self.TPMS_univ_TPMS_rec2_0 = TPMS.univ_TPMS_rec2("WBX_proba",
> samp_rate, 0.5, 45, "localhost", 2, "TEST_TRACK_TPMS", "nemanja",
> "nemanja", "det_id_proba", "detectors")
>   File
> "/scr1/nemanja/install/lib64/python2.6/site-packages/TPMS/univ_TPMS_rec2.py",
> line 145, in __init__
> self.msg_connect(self.SEL_90518407_pkt_def.SCHRADER_def, out_port,
> self.db_logger, in_port)
>   File
> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/hier_block2.py",
> line 59, in wrapped
> func(self, src.to_basic_block(), srcport, dst.to_basic_block(),
> dstport)
>   File
> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/hier_block2.py",
> line 131, in msg_connect
> self.primitive_msg_connect(*args)
>   File
> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/runtime_swig.py",
> line 3043, in primitive_msg_connect
> return _runtime_swig.hier_block2_sptr_primitive_msg_connect(self,
> *args)
> RuntimeError: invalid msg port in connect() or disconnect()
>
> I see that there is a function for checking whether the ports are valid,
> but don't get what's wrong with my ports. Namely, I have hier block and a
> few blocks are sending messages to a single blocks where the messages are
> decoded and written to darabase. I tried to hardcode names of the blocks
> and that also didn't help.
>
> Thanx,
>
> --
> Nemanja Savić
>
>
> ___
> 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
>
>


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

[Discuss-gnuradio] message port declaration problem after changing to 3.7.8

[Nemanja Savic]

Hi all guys,

I recently installed 3.7.8, and before that I had 3.6.5.1.
I was using message passing in some of my blocks, but now I get error which
is following:

Could not find port: in_port in:
in_port
system

Traceback (most recent call last):
  File "./top_block.py", line 178, in 
tb = top_block()
  File "./top_block.py", line 124, in __init__
self.TPMS_univ_TPMS_rec2_0 = TPMS.univ_TPMS_rec2("WBX_proba",
samp_rate, 0.5, 45, "localhost", 2, "TEST_TRACK_TPMS", "nemanja",
"nemanja", "det_id_proba", "detectors")
  File
"/scr1/nemanja/install/lib64/python2.6/site-packages/TPMS/univ_TPMS_rec2.py",
line 145, in __init__
self.msg_connect(self.SEL_90518407_pkt_def.SCHRADER_def, out_port,
self.db_logger, in_port)
  File
"/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/hier_block2.py",
line 59, in wrapped
func(self, src.to_basic_block(), srcport, dst.to_basic_block(), dstport)
  File
"/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/hier_block2.py",
line 131, in msg_connect
self.primitive_msg_connect(*args)
  File
"/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/runtime_swig.py",
line 3043, in primitive_msg_connect
return _runtime_swig.hier_block2_sptr_primitive_msg_connect(self, *args)
RuntimeError: invalid msg port in connect() or disconnect()

I see that there is a function for checking whether the ports are valid,
but don't get what's wrong with my ports. Namely, I have hier block and a
few blocks are sending messages to a single blocks where the messages are
decoded and written to darabase. I tried to hardcode names of the blocks
and that also didn't help.

Thanx,

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

Re: [Discuss-gnuradio] Error when running GRC

[Nemanja Savic]

Hi,

so, the flowgraph is very simple. Just signal generator, throttle and gui
qt sink (it is attached).
When I close GUI, the flowgraph isn't terminated, but in order to do so, I
have to press rex button in GRC to kill it. The return code is -9.

>>> Done (return code -9)

Also, when I close GRC it is not closed properly but with Seg fault.

Best,
Nemanja

On Thu, Oct 29, 2015 at 7:46 PM, Marcus Müller 
wrote:

> Hi Nemanja,
>
> well Marcus, you were right (like usual) ...
>
> ha! I wish that was true! Usually I'm not right, trust me.
>
> I tried GRC and it worked. What was strange for me is that flowchart was
> not terminated when I closed QT scope.
>
> That's a bit surprising; you don't happen to have a .grc with which I can
> recreate that?
>
> Cheers,
> Marcus
>
>
>
> On 10/29/2015 05:46 PM, Nemanja Savic wrote:
>
> Hello,
>
> well Marcus, you were right (like usual) ...
> I don't know what exactly problem was, but concerning GRC, it looks like
> in my first attempt to buld sphinx executable couldn't be found.
> As for the min test, it doesn't work, it just stays blocked, no particular
> output.
>
> I tried GRC and it worked. What was strange for me is that flowchart was
> not terminated when I closed QT scope.
>
> Best,
> Nemanja
>
> On Mon, Oct 26, 2015 at 6:19 PM, Marcus Müller 
> wrote:
>
>> First, try to run the test in isolation:
>> in your build/ directory,
>>
>> ctest -V -R min
>>
>> should run your test alone. If that doesn't give you additional insight,
>> try running
>> ./gr-blocks/python/blocks/qa_min_test.sh
>> directly.
>>
>> You should also inspect the reason GRC core dumps, there's a small wiki
>> page for that [1]; but to be completely honest: qa_min failing and GRC
>> segfaulting sounds like there's some mismatch between the libraries used at
>> build time and the libraries loaded at run time, in my experience.
>>
>> Best regards,
>> Marcus
>>
>> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
>>
>> On 26.10.2015 11:42, Nemanja Savic wrote:
>>
>> Hi,
>>
>> as for the test, I didn't copy correct lines. My test literally blocks in
>> test 11 and never get out of that.
>> test 11
>> Start  11: qa_min
>>
>> 11: Test command: /bin/sh
>> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/python/blocks/qa_min_test.sh"
>> 11: Test timeout computed to be: 9.99988e+06
>>
>> Yes, when I remove keyword argument it finishes with core dumped.
>> No, my previous Gnuradio installation is there, but with another prefix.
>> My machine runs on RHEL6, so can't really change python cause, it makes a
>> lot of trouble with administrators.
>>
>> How can I trace more what cases this error. Few days ago I built gnuradio
>> usinc anaconda python, but had some issues with graphics and then I moved
>> back to my native python.
>>
>> Nemanja
>>
>>
>> On Mon, Oct 26, 2015 at 10:23 AM, Marcus Müller > > wrote:
>>
>>> Hi,
>>> I think this is what that test is supposed to look like, so reading that
>>> is a good sign!
>>> You say you get a segfault when running GRC, right? That's a bit
>>> surprising, because GRC is pure Python, so it's probably something that
>>> gets loaded along the way. Have you uninstalled your previous GNU Radio
>>> installation?
>>> By the way, I thought pre-2.7 Python was practically extinct; out of
>>> curiosity: which OS are you on?
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> Am 26. Oktober 2015 09:10:04 MEZ, schrieb Nemanja Savic <
>>> vlasi...@gmail.com>:
>>>>
>>>> Hello,
>>>>
>>>> I use Python 2.6.6.
>>>> When I make suggested change I got Segmentation Fault error.
>>>> I don't know if it is connected with this, but when I run test, it
>>>> blocks in test n. 10. with this output:
>>>>
>>>> 10: Test command: /bin/sh
>>>> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/lib/test_gr_blocks_test.sh"
>>>> 10: Test timeout computed to be: 9.99988e+06
>>>> 10:
>>>> 10: NOTE: This is supposed to produce an error from block_executor
>>>> 10: Error: block_executor: propagation_policy 'ONE-TO-ONE' requires
>>>> ninputs == noutputs
>>>> 10: Using Volk machine: avx_64_mmx_orc
>>>> 10: .

Re: [Discuss-gnuradio] Error when running GRC

[Nemanja Savic]

Hello,

well Marcus, you were right (like usual) ...
I don't know what exactly problem was, but concerning GRC, it looks like in
my first attempt to buld sphinx executable couldn't be found.
As for the min test, it doesn't work, it just stays blocked, no particular
output.

I tried GRC and it worked. What was strange for me is that flowchart was
not terminated when I closed QT scope.

Best,
Nemanja

On Mon, Oct 26, 2015 at 6:19 PM, Marcus Müller 
wrote:

> First, try to run the test in isolation:
> in your build/ directory,
>
> ctest -V -R min
>
> should run your test alone. If that doesn't give you additional insight,
> try running
> ./gr-blocks/python/blocks/qa_min_test.sh
> directly.
>
> You should also inspect the reason GRC core dumps, there's a small wiki
> page for that [1]; but to be completely honest: qa_min failing and GRC
> segfaulting sounds like there's some mismatch between the libraries used at
> build time and the libraries loaded at run time, in my experience.
>
> Best regards,
> Marcus
>
> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
>
> On 26.10.2015 11:42, Nemanja Savic wrote:
>
> Hi,
>
> as for the test, I didn't copy correct lines. My test literally blocks in
> test 11 and never get out of that.
> test 11
> Start  11: qa_min
>
> 11: Test command: /bin/sh
> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/python/blocks/qa_min_test.sh"
> 11: Test timeout computed to be: 9.99988e+06
>
> Yes, when I remove keyword argument it finishes with core dumped.
> No, my previous Gnuradio installation is there, but with another prefix.
> My machine runs on RHEL6, so can't really change python cause, it makes a
> lot of trouble with administrators.
>
> How can I trace more what cases this error. Few days ago I built gnuradio
> usinc anaconda python, but had some issues with graphics and then I moved
> back to my native python.
>
> Nemanja
>
>
> On Mon, Oct 26, 2015 at 10:23 AM, Marcus Müller 
> wrote:
>
>> Hi,
>> I think this is what that test is supposed to look like, so reading that
>> is a good sign!
>> You say you get a segfault when running GRC, right? That's a bit
>> surprising, because GRC is pure Python, so it's probably something that
>> gets loaded along the way. Have you uninstalled your previous GNU Radio
>> installation?
>> By the way, I thought pre-2.7 Python was practically extinct; out of
>> curiosity: which OS are you on?
>>
>> Best regards,
>> Marcus
>>
>>
>> Am 26. Oktober 2015 09:10:04 MEZ, schrieb Nemanja Savic <
>> vlasi...@gmail.com>:
>>>
>>> Hello,
>>>
>>> I use Python 2.6.6.
>>> When I make suggested change I got Segmentation Fault error.
>>> I don't know if it is connected with this, but when I run test, it
>>> blocks in test n. 10. with this output:
>>>
>>> 10: Test command: /bin/sh
>>> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/lib/test_gr_blocks_test.sh"
>>> 10: Test timeout computed to be: 9.99988e+06
>>> 10:
>>> 10: NOTE: This is supposed to produce an error from block_executor
>>> 10: Error: block_executor: propagation_policy 'ONE-TO-ONE' requires
>>> ninputs == noutputs
>>> 10: Using Volk machine: avx_64_mmx_orc
>>> 10: ..
>>> 10:
>>>  10/170 Test  #10: test_gr_blocks ...   Passed
>>> 0.86 sec
>>> test 11
>>> Start  11: qa_min
>>>
>>>
>>> Can these two be connected?
>>>
>>> Nemanja
>>>
>>> On Mon, Oct 26, 2015 at 2:25 AM, Marcus Müller <
>>> marcus.muel...@ettus.com> wrote:
>>>
>>>> Hi!
>>>>
>>>> First intuition is that there might be something wrong with the Python
>>>> version in use. Which is it? Python pre-2.7 doesn't know the keyword
>>>> arguments, so it would have to read
>>>> .decode('utf-8','replace')
>>>> Instead of
>>>> .decode('utf-8',errors='replace')
>>>>
>>>> Cheetah is, as far as I know, not Python 3 compatible.
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>>
>>>> Am 26. Oktober 2015 01:46:09 MEZ, schrieb Nemanja Savic <
>>>> vlasi...@gmail.com>:
>>>>
>>>>> Hi all guys,
>>>>>
>>>>> i built yesterday 3.7.8. When I wanted to run GRC the following

Re: [Discuss-gnuradio] Error when running GRC

[Nemanja Savic]

Hi,

as for the test, I didn't copy correct lines. My test literally blocks in
test 11 and never get out of that.
test 11
Start  11: qa_min

11: Test command: /bin/sh
"/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/python/blocks/qa_min_test.sh"
11: Test timeout computed to be: 9.99988e+06

Yes, when I remove keyword argument it finishes with core dumped.
No, my previous Gnuradio installation is there, but with another prefix. My
machine runs on RHEL6, so can't really change python cause, it makes a lot
of trouble with administrators.

How can I trace more what cases this error. Few days ago I built gnuradio
usinc anaconda python, but had some issues with graphics and then I moved
back to my native python.

Nemanja


On Mon, Oct 26, 2015 at 10:23 AM, Marcus Müller 
wrote:

> Hi,
> I think this is what that test is supposed to look like, so reading that
> is a good sign!
> You say you get a segfault when running GRC, right? That's a bit
> surprising, because GRC is pure Python, so it's probably something that
> gets loaded along the way. Have you uninstalled your previous GNU Radio
> installation?
> By the way, I thought pre-2.7 Python was practically extinct; out of
> curiosity: which OS are you on?
>
> Best regards,
> Marcus
>
>
> Am 26. Oktober 2015 09:10:04 MEZ, schrieb Nemanja Savic <
> vlasi...@gmail.com>:
>>
>> Hello,
>>
>> I use Python 2.6.6.
>> When I make suggested change I got Segmentation Fault error.
>> I don't know if it is connected with this, but when I run test, it blocks
>> in test n. 10. with this output:
>>
>> 10: Test command: /bin/sh
>> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/lib/test_gr_blocks_test.sh"
>> 10: Test timeout computed to be: 9.99988e+06
>> 10:
>> 10: NOTE: This is supposed to produce an error from block_executor
>> 10: Error: block_executor: propagation_policy 'ONE-TO-ONE' requires
>> ninputs == noutputs
>> 10: Using Volk machine: avx_64_mmx_orc
>> 10: ..
>> 10:
>>  10/170 Test  #10: test_gr_blocks ...   Passed
>> 0.86 sec
>> test 11
>> Start  11: qa_min
>>
>>
>> Can these two be connected?
>>
>> Nemanja
>>
>> On Mon, Oct 26, 2015 at 2:25 AM, Marcus Müller 
>> wrote:
>>
>>> Hi!
>>>
>>> First intuition is that there might be something wrong with the Python
>>> version in use. Which is it? Python pre-2.7 doesn't know the keyword
>>> arguments, so it would have to read
>>> .decode('utf-8','replace')
>>> Instead of
>>> .decode('utf-8',errors='replace')
>>>
>>> Cheetah is, as far as I know, not Python 3 compatible.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> Am 26. Oktober 2015 01:46:09 MEZ, schrieb Nemanja Savic <
>>> vlasi...@gmail.com>:
>>>
>>>> Hi all guys,
>>>>
>>>> i built yesterday 3.7.8. When I wanted to run GRC the following error
>>>> occured:
>>>>
>>>> Traceback (most recent call last):
>>>>   File "/scr1/nemanja/install/bin/gnuradio-companion", line 128, in
>>>> 
>>>> main()
>>>>   File "/scr1/nemanja/install/bin/gnuradio-companion", line 121, in main
>>>> ActionHandler(args, Platform())
>>>>   File
>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
>>>> line 62, in __init__
>>>> self.main_window = MainWindow(platform)
>>>>   File
>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/MainWindow.py",
>>>> line 96, in __init__
>>>> self.btwin = BlockTreeWindow(platform, self.get_flow_graph);
>>>>   File
>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>>>> line 107, in __init__
>>>> self.platform.load_block_tree(self)
>>>>   File
>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/base/Platform.py",
>>>> line 228, in load_block_tree
>>>> block_tree.add_block(block.get_category(), block)
>>>>   File
>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>>>> line 144, in add_block
>>>> treestore.set_value(iter, DOC_INDEX,
>>&g

Re: [Discuss-gnuradio] Error when running GRC

[Nemanja Savic]

Hello,

I use Python 2.6.6.
When I make suggested change I got Segmentation Fault error.
I don't know if it is connected with this, but when I run test, it blocks
in test n. 10. with this output:

10: Test command: /bin/sh
"/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/lib/test_gr_blocks_test.sh"
10: Test timeout computed to be: 9.99988e+06
10:
10: NOTE: This is supposed to produce an error from block_executor
10: Error: block_executor: propagation_policy 'ONE-TO-ONE' requires ninputs
== noutputs
10: Using Volk machine: avx_64_mmx_orc
10: ..
10:
 10/170 Test  #10: test_gr_blocks ...   Passed0.86
sec
test 11
Start  11: qa_min


Can these two be connected?

Nemanja

On Mon, Oct 26, 2015 at 2:25 AM, Marcus Müller 
wrote:

> Hi!
>
> First intuition is that there might be something wrong with the Python
> version in use. Which is it? Python pre-2.7 doesn't know the keyword
> arguments, so it would have to read
> .decode('utf-8','replace')
> Instead of
> .decode('utf-8',errors='replace')
>
> Cheetah is, as far as I know, not Python 3 compatible.
>
> Best regards,
> Marcus
>
>
> Am 26. Oktober 2015 01:46:09 MEZ, schrieb Nemanja Savic <
> vlasi...@gmail.com>:
>
>> Hi all guys,
>>
>> i built yesterday 3.7.8. When I wanted to run GRC the following error
>> occured:
>>
>> Traceback (most recent call last):
>>   File "/scr1/nemanja/install/bin/gnuradio-companion", line 128, in
>> 
>> main()
>>   File "/scr1/nemanja/install/bin/gnuradio-companion", line 121, in main
>> ActionHandler(args, Platform())
>>   File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
>> line 62, in __init__
>> self.main_window = MainWindow(platform)
>>   File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/MainWindow.py",
>> line 96, in __init__
>> self.btwin = BlockTreeWindow(platform, self.get_flow_graph);
>>   File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>> line 107, in __init__
>> self.platform.load_block_tree(self)
>>   File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/base/Platform.py",
>> line 228, in load_block_tree
>> block_tree.add_block(block.get_category(), block)
>>   File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>> line 144, in add_block
>> treestore.set_value(iter, DOC_INDEX,
>> Utils.parse_template(DOC_MARKUP_TMPL, doc=block.get_doc()))
>>   File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
>> line 116, in parse_template
>> return str(Template(tmpl_str, kwargs))
>>   File "/usr/lib64/python2.6/site-packages/Cheetah/Template.py", line
>> 1003, in __str__
>> rc = getattr(self, mainMethName)()
>>   File
>> "cheetah_DynamicallyCompiledCheetahTemplate_1445820074_12_55642.py", line
>> 83, in respond
>>   File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
>> line 100, in encode
>> valid_utf8 = value.decode('utf-8', errors='replace').encode('utf-8')
>> TypeError: decode() takes no keyword arguments
>>
>>
>> It looks like Cheetah problem but can't make it work. There was
>> suggestion few years ago to remove errors='replace', but it didn't work for
>> me.
>>
>> THanx
>> --
>> Nemanja Savić
>>
>> --
>>
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>



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

[Discuss-gnuradio] Error when running GRC

[Nemanja Savic]

Hi all guys,

i built yesterday 3.7.8. When I wanted to run GRC the following error
occured:

Traceback (most recent call last):
  File "/scr1/nemanja/install/bin/gnuradio-companion", line 128, in 
main()
  File "/scr1/nemanja/install/bin/gnuradio-companion", line 121, in main
ActionHandler(args, Platform())
  File
"/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
line 62, in __init__
self.main_window = MainWindow(platform)
  File
"/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/MainWindow.py",
line 96, in __init__
self.btwin = BlockTreeWindow(platform, self.get_flow_graph);
  File
"/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
line 107, in __init__
self.platform.load_block_tree(self)
  File
"/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/base/Platform.py",
line 228, in load_block_tree
block_tree.add_block(block.get_category(), block)
  File
"/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
line 144, in add_block
treestore.set_value(iter, DOC_INDEX,
Utils.parse_template(DOC_MARKUP_TMPL, doc=block.get_doc()))
  File
"/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
line 116, in parse_template
return str(Template(tmpl_str, kwargs))
  File "/usr/lib64/python2.6/site-packages/Cheetah/Template.py", line 1003,
in __str__
rc = getattr(self, mainMethName)()
  File "cheetah_DynamicallyCompiledCheetahTemplate_1445820074_12_55642.py",
line 83, in respond
  File
"/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
line 100, in encode
valid_utf8 = value.decode('utf-8', errors='replace').encode('utf-8')
TypeError: decode() takes no keyword arguments


It looks like Cheetah problem but can't make it work. There was suggestion
few years ago to remove errors='replace', but it didn't work for me.

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

[Discuss-gnuradio] import Qwt error

[Nemanja Savic]

Hi all guys,

i am trying to install gnuradio 3.7.7.1 version og gnuradio on my RHEL6
machine in a local path and to preserve my 3.6.5.1 version. After instaling
many different programs i also screwed my old version. Ok it was not that
bad but filter design tool doesn't work for me. I get the following error

Traceback (most recent call last):
  File "/usr/local/bin/gr_filter_design", line 22, in 
import PyQt4.Qwt5 as Qwt
  File "/usr/lib64/python2.6/site-packages/PyQt4/Qwt5/__init__.py", line
32, in 
from Qwt import *
RuntimeError: the sip module implements API v11.0 to v11.1 but the
PyQt4.Qwt5.Qwt module requires API v6.0


Did anybody has already ex[erienced this error and maybe have suggestion
how to solve it?

Cheers,

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

Re: [Discuss-gnuradio] block without work function won't stop

[Nemanja Savic]

Namely,

my workless function block blocks my flowgraph when I call unlock(). I made
a method where I set d_finished to True, but this doesn't help.

Nemanja

On Wed, Sep 2, 2015 at 2:16 PM, Nemanja Savic  wrote:

> Hello again,
>
> could you please Marcus, or somebody else, give me some hint for sending
> done message to a block's "system" port. Are all blocks by default
> subscribed to system port?
>
> Best,
> Nemanja
>
> On Tue, May 26, 2015 at 2:37 PM, Nemanja Savic  wrote:
>
>> Hi,
>>
>> thank you Marcus for your fast answer. Well, the problem is that nobody
>> ecept scheduler knows when the flowgraph has finished, so I don't know who
>> should sent that message to the block. This is however not of crucial
>> importance for me. Namely I wanted to test some of my custom blocks, and
>> test flowgraph necever reached completion, but as soon as message accepting
>> dummy block was out everything was fine.
>>
>> Best,
>> Nemanja
>>
>> On Tue, May 26, 2015 at 2:29 PM, Marcus Müller 
>> wrote:
>>
>>> Hi Nemanja,
>>>
>>> the point is that with message passing, it's not clear that your block
>>> is ever finished.
>>> Hence in block.cc, we have a mechanism to retrieve the "finishedness" of
>>> a pure-message-block.
>>>
>>>   bool
>>>   block::finished()
>>>   {
>>> if((detail()->ninputs() != 0) || (detail()->noutputs() != 0))
>>>   return false;
>>> else
>>>   return d_finished;
>>>   }
>>>
>>>
>>> So, you'll have to set the d_finished variable of your block; sadly,
>>> that's a private one by design (I think there are thread-safety reasons
>>> this is not directly exposed, but I'm not sure -- I'd have to as T[io]m
>>> about that).
>>> The proper way to do so is to send your block a message to its
>>> pmt::mp("system") port, containing pmt::mp("done").
>>>
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 05/26/2015 02:10 PM, Nemanja Savic wrote:
>>>
>>> Hi all,
>>>
>>> I have a block that is used only for acepting messages and writing their
>>> content into database. The block is written in python and it has no work
>>> function, but only constructor and message handler. However when I run my
>>> flowgraph it won't finish until I terminate it. When I exclude this block
>>> it runs to completion normally.
>>> Is there any issue with messages in this case. Should I manually delete
>>> messages from the message queue or something like that.
>>>
>>> Best,
>>>
>>> --
>>> Nemanja Savić
>>>
>>>
>>> ___
>>> 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
>>>
>>>
>>
>>
>> --
>> Nemanja Savić
>>
>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] block without work function won't stop

[Nemanja Savic]

Hello again,

could you please Marcus, or somebody else, give me some hint for sending
done message to a block's "system" port. Are all blocks by default
subscribed to system port?

Best,
Nemanja

On Tue, May 26, 2015 at 2:37 PM, Nemanja Savic  wrote:

> Hi,
>
> thank you Marcus for your fast answer. Well, the problem is that nobody
> ecept scheduler knows when the flowgraph has finished, so I don't know who
> should sent that message to the block. This is however not of crucial
> importance for me. Namely I wanted to test some of my custom blocks, and
> test flowgraph necever reached completion, but as soon as message accepting
> dummy block was out everything was fine.
>
> Best,
> Nemanja
>
> On Tue, May 26, 2015 at 2:29 PM, Marcus Müller 
> wrote:
>
>> Hi Nemanja,
>>
>> the point is that with message passing, it's not clear that your block is
>> ever finished.
>> Hence in block.cc, we have a mechanism to retrieve the "finishedness" of
>> a pure-message-block.
>>
>>   bool
>>   block::finished()
>>   {
>> if((detail()->ninputs() != 0) || (detail()->noutputs() != 0))
>>   return false;
>> else
>>   return d_finished;
>>   }
>>
>>
>> So, you'll have to set the d_finished variable of your block; sadly,
>> that's a private one by design (I think there are thread-safety reasons
>> this is not directly exposed, but I'm not sure -- I'd have to as T[io]m
>> about that).
>> The proper way to do so is to send your block a message to its
>> pmt::mp("system") port, containing pmt::mp("done").
>>
>>
>> Best regards,
>> Marcus
>>
>>
>> On 05/26/2015 02:10 PM, Nemanja Savic wrote:
>>
>> Hi all,
>>
>> I have a block that is used only for acepting messages and writing their
>> content into database. The block is written in python and it has no work
>> function, but only constructor and message handler. However when I run my
>> flowgraph it won't finish until I terminate it. When I exclude this block
>> it runs to completion normally.
>> Is there any issue with messages in this case. Should I manually delete
>> messages from the message queue or something like that.
>>
>> Best,
>>
>> --
>> Nemanja Savić
>>
>>
>> ___
>> 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
>>
>>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] core dumped when closing GRC

[Nemanja Savic]

Hi,

yeah basically it's not a big deal, just a bit anonying. However it can be
probably problem with glib since my RHEL6 probably has some ancient version
...

Thanks,
Nemanja

On Fri, Jun 5, 2015 at 12:32 AM, Tom Rondeau  wrote:

> On Thu, Jun 4, 2015 at 12:58 PM, Martin Braun 
> wrote:
>
>> OK, in that case probably some other issue. Can't really say more from
>> afar.
>>
>> Cheers,
>> Martin
>>
>> On 04.06.2015 09:33, Nemanja Savic wrote:
>> > Hi,
>> >
>> > so, well, I did like it should be, first I installed UHD and then
>> > GNURadio...
>> > The point is that segmentation fault happens when I am closing GRC. So,
>> > even without any flowgraph.
>> >
>> > Nemanja
>> >
>> > On Thu, Jun 4, 2015 at 5:43 PM, Martin Braun > > <mailto:martin.br...@ettus.com>> wrote:
>> >
>> >
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#My-application-segfaults-immediately-It-used-to-work-and-I-didnt-change-it-What-the
>> >
>> > M
>> >
>> > On 04.06.2015 05:42, Nemanja Savic wrote:
>> > > Hi all,
>> > >
>> > > i finally managed to install newest version of gnuradio (3.7.7.1)
>> > on mu
>> > > RHEL6. Everyrhing look sjust fine except segmentation fault when
>> > closing
>> > > GRC. Didi anybody experience something like this and how can I
>> > debug it?
>> > >
>> > > Best
>> > >
>> > > --
>> > > Nemanja Savić
>>
>
> I think we've seen this before with certain versions of glibc (possibly
> another library that we haven't looked at). It used to effect older
> versions of Ubuntu (14.04 IIRC) but not the latest couple of versions. We
> tried to track it down, but since it looked like it was in glibc and was
> fixed with newer versions (and it only happens on exit), we didn't go too
> far in looking into this one.
>
> Tom
>
>



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

[Discuss-gnuradio] core dumped when closing GRC

[Nemanja Savic]

Hi all,

i finally managed to install newest version of gnuradio (3.7.7.1) on mu
RHEL6. Everyrhing look sjust fine except segmentation fault when closing
GRC. Didi anybody experience something like this and how can I debug it?

Best

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

[Discuss-gnuradio] can't install gnuradio 3.7.7.1 and newest UHD

[Nemanja Savic]

Hi all,

I am stil using gnuradio 3.6.5.1 and yesterday I wanted to install newest
version of both gnuradio and UHD driver. I wanted to install them on some
different path and to preserve working environment until I am sure that
newcomers work.

First I downloaded and built UHD. I followed instructions and the first
problem was that I couldn't run test. It simply says can't find test.
However I installed it (on a different path where my old UHD driver is).

Next I built gnuradio. In ccmake i provided new paths to the fresh UHD:

UHD_DIR   /scr1/nemanja/install/lib64/cmake/uhd

UHD_INCLUDE_DIRS   /scr1/nemanja/install/include
UHD_LIBRARIES
/scr1/nemanja/install/lib64/libgnuradio-uhd-3.7.7.so.0.0.0

However at the end of the building process I get following error:

make[2]: *** No rule to make target
`/scr1/nemanja/install/lib64/libgnuradio-uhd-3.7.7.so.0.0.0', needed by
`gr-uhd/lib/libgnuradio-uhd-3.7.7.so.0.0.0'.  Stop.
make[1]: *** [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/all] Error 2
make: *** [all] Error 2

What might be the problem here?

Thanx,

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

[Discuss-gnuradio] bfile sink base undefined symbol error

[Nemanja Savic]

Hi all guys,

I encounter following error when running my test:

ImportError: /usr/local/lib/libgnuradio-TPMS.so: undefined symbol:
_ZN2gr6blocks14file_sink_baseC2EPKcb

There was a similar problem explained here:
http://stackoverflow.com/questions/28859517/gnuradio-importerror-undefined-symbol

I use gnuradio 3.6.5.1.
After doing suggested c++filter I got:
gr::blocks::file_sink_base::file_sink_base(char const*, bool)

And yes, one of my blocks is derived from file sink base class in the
similar way as it was donein default gnuradio file sink:

class RDK_API file_sink_lim_b : virtual public gr_sync_block,
virtual public
blocks::file_sink_base

In the suggested solution,the guy sugest adding extra lines in cmake file,
which I did:

set(GR_REQUIRED_COMPONENTS BLOCKS)
find_package(Gnuradio "3.6.5.1")

later
${GNURADIO_ALL_INCLUDE_DIRS}

and
${GNURADIO_ALL_LIBRARIES}

Then, after running cmake in my build folder, it can be seen that
everything was found:
Checking for GNU Radio Module: BLOCKS
 * INCLUDES=/usr/local/include/gnuradio
 * LIBS=/usr/local/lib/libgnuradio-blocks.so
GNURADIO_BLOCKS_FOUND = TRUE

But still I have the same error. What else could be done. If worth of
mentioning, my module is made on RHEL6 maschine, while this error occures
on ubuntu after copying my source files (basically everything except build
folder)

Thanx

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

Re: [Discuss-gnuradio] block without work function won't stop

[Nemanja Savic]

Hi,

thank you Marcus for your fast answer. Well, the problem is that nobody
ecept scheduler knows when the flowgraph has finished, so I don't know who
should sent that message to the block. This is however not of crucial
importance for me. Namely I wanted to test some of my custom blocks, and
test flowgraph necever reached completion, but as soon as message accepting
dummy block was out everything was fine.

Best,
Nemanja

On Tue, May 26, 2015 at 2:29 PM, Marcus Müller 
wrote:

>  Hi Nemanja,
>
> the point is that with message passing, it's not clear that your block is
> ever finished.
> Hence in block.cc, we have a mechanism to retrieve the "finishedness" of a
> pure-message-block.
>
>   bool
>   block::finished()
>   {
> if((detail()->ninputs() != 0) || (detail()->noutputs() != 0))
>   return false;
> else
>   return d_finished;
>   }
>
>
> So, you'll have to set the d_finished variable of your block; sadly,
> that's a private one by design (I think there are thread-safety reasons
> this is not directly exposed, but I'm not sure -- I'd have to as T[io]m
> about that).
> The proper way to do so is to send your block a message to its
> pmt::mp("system") port, containing pmt::mp("done").
>
>
> Best regards,
> Marcus
>
>
> On 05/26/2015 02:10 PM, Nemanja Savic wrote:
>
>   Hi all,
>
>  I have a block that is used only for acepting messages and writing their
> content into database. The block is written in python and it has no work
> function, but only constructor and message handler. However when I run my
> flowgraph it won't finish until I terminate it. When I exclude this block
> it runs to completion normally.
>  Is there any issue with messages in this case. Should I manually delete
> messages from the message queue or something like that.
>
>  Best,
>
> --
> Nemanja Savić
>
>
> ___
> 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
>
>


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

[Discuss-gnuradio] block without work function won't stop

[Nemanja Savic]

Hi all,

I have a block that is used only for acepting messages and writing their
content into database. The block is written in python and it has no work
function, but only constructor and message handler. However when I run my
flowgraph it won't finish until I terminate it. When I exclude this block
it runs to completion normally.
Is there any issue with messages in this case. Should I manually delete
messages from the message queue or something like that.

Best,

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

[Discuss-gnuradio] missing GRC block panel

[Nemanja Savic]

Hi all,

did anybody experience missing complete blocks panel in GRC? 3.6.5.1.

Thanx

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

Re: [Discuss-gnuradio] No change when set_processor affinity() is used

[Nemanja Savic]

You are right, cause I was looking in a process manager and only one core
was 100% busy, but since the middle filter had 37k taps it might be that
the other two were starving a little bit.
BTW, in the shown flograph, I would like to have signal in upper and down
paths synchronized, so I introduced delay of (N-1)/2, where N is the number
of taps in the middle filter. However signals in the files are not
synchronized. What could cause that?

On Tue, May 12, 2015 at 7:01 PM, Marcus D. Leech  wrote:

>  On 05/12/2015 12:52 PM, Nemanja Savic wrote:
>
>
> You are probably right, cause that file doesn't even exist. I looked at
> default gnuradio-core.conf in conf.d.
>  I suppose that something like that should be written in
> gnuradi-core.conf, but really nothing.
>  Where can I find which option should be added?
>
> How are you determining that this is only occupying a single core?
>
> Are you running on a VM?   If so, how many cores does your VM simulate?
>
>
> On Tue, May 12, 2015 at 6:33 PM, Marcus D. Leech 
> wrote:
>
>>   On 05/12/2015 12:25 PM, Nemanja Savic wrote:
>>
>>   Hi all guys,
>>
>>  I have a flowgraph where I have three parallel paths for filtering
>> signal stored in a file. Here the picture of my flowgraph:
>>
>> [image: Inline image 1]
>>
>>  I use gnuradio 3.6.5.1. When I run the script it uses only one
>> processor, and since I have 4 cores, I would like to run every of the paths
>> on another processor. For every filter I do set_processr_affinity[some
>> number between 0 and ]. When I run the script nothing changes, it still
>> runs on a single core. Am I missing something with set_processor_affinity
>> method?
>>
>>  Best,
>>
>> --
>> Nemanja Savić
>>
>>
>>  ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>  My guess is that your ~/.gnuradio/config.conf   specifies to use the
>> single-threaded scheduler.
>>
>>
>>
>
>
> --
> Nemanja Savić
>
>
>


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

Re: [Discuss-gnuradio] No change when set_processor affinity() is used

[Nemanja Savic]

@Marcus Mueller: But when I run the shown flowgraph it uses only one core.

On Tue, May 12, 2015 at 6:48 PM, Marcus Müller 
wrote:

>  What Marcus said; GNU Radio 3.6 with its default scheduler, which is
> aptly named thread-per-block scheduler, automatically runs every block in
> its own thread, and by default (ie. unless you explicitely specify
> affinity) lets the OS handle distribution to CPUs; that's the reason GNU
> Radio applications tend to scale very well on multiple CPUs, even if the
> algorithms in the individual blocks are not heavily multithreaded.
>
> Greetings,
> Marcus
>
>
> On 05/12/2015 06:33 PM, Marcus D. Leech wrote:
>
> On 05/12/2015 12:25 PM, Nemanja Savic wrote:
>
>  Hi all guys,
>
>  I have a flowgraph where I have three parallel paths for filtering signal
> stored in a file. Here the picture of my flowgraph:
>
> [image: Inline image 1]
>
>  I use gnuradio 3.6.5.1. When I run the script it uses only one
> processor, and since I have 4 cores, I would like to run every of the paths
> on another processor. For every filter I do set_processr_affinity[some
> number between 0 and ]. When I run the script nothing changes, it still
> runs on a single core. Am I missing something with set_processor_affinity
> method?
>
>  Best,
>
> --
> Nemanja Savić
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  My guess is that your ~/.gnuradio/config.conf   specifies to use the
> single-threaded scheduler.
>
>
>
>
> ___
> 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
>
>


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

Re: [Discuss-gnuradio] No change when set_processor affinity() is used

[Nemanja Savic]

You are probably right, cause that file doesn't even exist. I looked at
default gnuradio-core.conf in conf.d.
I suppose that something like that should be written in gnuradi-core.conf,
but really nothing.
Where can I find which option should be added?

On Tue, May 12, 2015 at 6:33 PM, Marcus D. Leech  wrote:

>  On 05/12/2015 12:25 PM, Nemanja Savic wrote:
>
>  Hi all guys,
>
>  I have a flowgraph where I have three parallel paths for filtering signal
> stored in a file. Here the picture of my flowgraph:
>
> [image: Inline image 1]
>
>  I use gnuradio 3.6.5.1. When I run the script it uses only one
> processor, and since I have 4 cores, I would like to run every of the paths
> on another processor. For every filter I do set_processr_affinity[some
> number between 0 and ]. When I run the script nothing changes, it still
> runs on a single core. Am I missing something with set_processor_affinity
> method?
>
>  Best,
>
> --
> Nemanja Savić
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  My guess is that your ~/.gnuradio/config.conf   specifies to use the
> single-threaded scheduler.
>
>
>


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

[Discuss-gnuradio] No change when set_processor affinity() is used

[Nemanja Savic]

Hi all guys,

I have a flowgraph where I have three parallel paths for filtering signal
stored in a file. Here the picture of my flowgraph:

[image: Inline image 1]

I use gnuradio 3.6.5.1. When I run the script it uses only one processor,
and since I have 4 cores, I would like to run every of the paths on another
processor. For every filter I do set_processr_affinity[some number between
0 and ]. When I run the script nothing changes, it still runs on a single
core. Am I missing something with set_processor_affinity method?

Best,

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

Re: [Discuss-gnuradio] "Catching" end of flowgraph execution with GUI

[Nemanja Savic]

Hi all guys,

I understand more or less what you are suggesting, although I am not
familiar with any multithreading framework, but at least I could ask
somebody here in the house. The problem is following, as I described in my
other (recent :)) posts:

I have top block which consists of two flowgraphs, ie. tx path and rx path.
Tx path transmitts limited number of frames and then stops, but RX
continues to work, which means that top block will also never stop. I want
to be able to stop also RX path after the TX has finished. For this reason
I don't know how to catch that TX has finished and to proceed with stopping
RX.

Best and thanx,
Nemanja

On Tue, May 5, 2015 at 8:10 PM, Koslowski, Sebastian (CEL) <
sebastian.koslow...@kit.edu> wrote:

> I had a similar problem recently. My solution was to subclass the
> flowgraph adding the required functionality. Check out the
> _top_block_waiter class in top_block.py. You can reimplement that logic
> to e.g. add a time-out the the wait() call on the event or have a
> callback executed.
>
> Sebastian
>
> On 05/05/2015 02:00 PM, Nemanja Savic wrote:
> > Hi all (again),
> >
> > is there any way to catch that my flowgraph has finished execution, to
> > reconfigure it after that and to be able to watch signals in GUI?
> >
> > In my application I I would like to set some start and end values and
> > to press some kind of start button. After that flowgraph runs for the
> > first set of config parameters and after the execution is finished, it
> > should reconfigure itself and restart it for the second set of
> > parameters, and so on ... Meanwhile I would like to watch some signals
> > in GUI.
> >
> > I see that top_block_gui class calls infinite main loop and then it
> > blocks there. I suppose that in order to acomplish above stated tast,
> > I would need some kind of callback on flowgraph execution end. Is it
> > possible to make something like this?
> >
> > Thanx,
> >
> > --
> > Nemanja Savić
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Sebastian Koslowski
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe, Germany
>
> Phone: +49 721 608-46275
> Fax:   +49 721 608-46071
> Email: sebastian.koslow...@kit.edu
> Web:   http://www.cel.kit.edu/
>
> KIT – University of the State of Baden-Wuerttemberg and National Research
> Center of the Helmholtz Association
>
>
>


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

[Discuss-gnuradio] "Catching" end of flowgraph execution with GUI

[Nemanja Savic]

Hi all (again),

is there any way to catch that my flowgraph has finished execution, to
reconfigure it after that and to be able to watch signals in GUI?

In my application I I would like to set some start and end values and to
press some kind of start button. After that flowgraph runs for the first
set of config parameters and after the execution is finished, it should
reconfigure itself and restart it for the second set of parameters, and so
on ... Meanwhile I would like to watch some signals in GUI.

I see that top_block_gui class calls infinite main loop and then it blocks
there. I suppose that in order to acomplish above stated tast, I would need
some kind of callback on flowgraph execution end. Is it possible to make
something like this?

Thanx,

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

Re: [Discuss-gnuradio] error when calling method of base class block

[Nemanja Savic]

Hello,

well after a lot of digging in the mailing list I added this into my swig.i
file:

%include "gnuradio/blocks/file_sink_base.h"

and I also added this into my CMakeLists.txt:

set(GR_REQUIRED_COMPONENTS BLOCKS)

It turned out that only first change is required.

Best and hope that this will help somebody in the future.

Nemanja


On Mon, May 4, 2015 at 6:41 PM, Martin Braun  wrote:

> What do your swig file changes look like?
>
> M
>
> On 04.05.2015 05:13, Nemanja Savic wrote:
> > Hi all guys,
> >
> > I am making a file sink block with limited number of elements allowed to
> > be written in a file. I coded my block in the same way as it was done in
> > file_sink block found in blocks module. Namely, I derived my block from
> > file_sink_base and gr_sync_block, and so on, the rest is copied from the
> > existing block and finally the work function is slightly changed.
> > Unfortunately I am not able to call methods inherited from
> > file_sink_base class. I believe it is swig issue but don't know how to
> > make it. The error that I get when calling close() method inside my test:
> >
> > 1: Test timeout computed to be: 9.99988e+06
> > 1: thread[thread-per-block[1]: ]:
> > gr_block_detail::n_output_items
> > 1: thread[thread-per-block[1]: ]:
> > gr_block_detail::n_output_items
> > 1: E
> > 1: ==
> > 1: ERROR: test_001_t (__main__.qa_file_sink_lim_b)
> > 1: --
> > 1: Traceback (most recent call last):
> > 1:   File
> > "/home/savi_ne/work/gnuradio/gr-TPMS/python/qa_file_sink_lim_b.py", line
> > 44, in test_001_t
> > 1: self.dst.close()
> > 1: AttributeError: 'file_sink_lim_b_sptr' object has no attribute 'close'
> > 1:
> >
> > I use gnuradio 3.6.5.1 version.
> >
> > --
> > Nemanja Savić
> >
> >
> > ___
> > 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
>



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

[Discuss-gnuradio] error when calling method of base class block

[Nemanja Savic]

Hi all guys,

I am making a file sink block with limited number of elements allowed to be
written in a file. I coded my block in the same way as it was done in
file_sink block found in blocks module. Namely, I derived my block from
file_sink_base and gr_sync_block, and so on, the rest is copied from the
existing block and finally the work function is slightly changed.
Unfortunately I am not able to call methods inherited from file_sink_base
class. I believe it is swig issue but don't know how to make it. The error
that I get when calling close() method inside my test:

1: Test timeout computed to be: 9.99988e+06
1: thread[thread-per-block[1]: ]:
gr_block_detail::n_output_items
1: thread[thread-per-block[1]: ]:
gr_block_detail::n_output_items
1: E
1: ==
1: ERROR: test_001_t (__main__.qa_file_sink_lim_b)
1: --
1: Traceback (most recent call last):
1:   File
"/home/savi_ne/work/gnuradio/gr-TPMS/python/qa_file_sink_lim_b.py", line
44, in test_001_t
1: self.dst.close()
1: AttributeError: 'file_sink_lim_b_sptr' object has no attribute 'close'
1:

I use gnuradio 3.6.5.1 version.

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

Re: [Discuss-gnuradio] Terminating flowgraph inside

[Nemanja Savic]

Hi,

ok don't mind elaborating my problem again, gladly, but just didn't want to
bore you guys more.

What I want to do is to measure BER of my receiver built with USRP1 and WBX
board. Here is the diagram, it is probably much better than written
explanation:[image: Inline image 1]
TX path consists of random source and a block that makes digital signal out
of pseudorandom bit sequence.
RX path consists of my receiver.

The idea is that top block code sets the number of symbole that will be
transmitted, power level, etc ...
My main problem was how to stop RX path after certain number of received
symbols. I had following ideas:
1) TX path informs RX path somehow that the sequence has been transmitted.
[i didn't know how to proceed with this one]
2) I made a file sink block with limited number written elements which
returns -1 after that number is reached.

The practical problem that I had was how to inform upstream blocks from RC
path that they should stop. In one moment I figured out that my GUI based
top_block also makes troubles cause it blocks in infinite loop and I didn't
know how to call some callback in order to "restart" flowgraph.

So this is basically the idea. I am going now with 2) approach. I realized
that sink block can also return -1 and the top_block will go out of wait().
If you have any suggestion I would be happy to hear.

Best,
Nemanja


On Mon, May 4, 2015 at 8:56 AM, Marcus Müller 
wrote:

>  Hi Nemanja,
>
> What happens when arbitrary block in the middle of the flowgraph returns
> -1?
>
> That block is set to the DONE state. After that, all output that still can
> be processed is processed, successively setting the downstream blocks to an
> "don't call me, there can be no input" state.
> After that, the top_block.wait() call returns.
>
> You probably want to have a look at Tom's presentation linked in[1].
>
> is there any way that block inside a flowgraph terminate that flowgraph
> should stop.
>
> Well, returning WORK_DONE==-1, but you've already figured that out, so my
> guess is you want something else; would you mind elaborating on your
> problem?
>
> Best regards,
> Marcus
>
> [1]
> http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html
>
>
>
>
> On 05/03/2015 04:11 PM, Nemanja Savic wrote:
>
>  Hello again,
>
>  is there any way that block inside a flowgraph terminate that flowgraph
> should stop. Something like when source block returns -1 from work function.
>  What happens when arbitrary block in the middle of the flowgraph returns
> -1?
>
> --
> Nemanja Savić
>
>
> ___
> 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
>
>


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

[Discuss-gnuradio] Terminating flowgraph inside

[Nemanja Savic]

Hello again,

is there any way that block inside a flowgraph terminate that flowgraph
should stop. Something like when source block returns -1 from work function.
What happens when arbitrary block in the middle of the flowgraph returns -1?

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

[Discuss-gnuradio] catching the end of flowgraph execution

[Nemanja Savic]

Hello again guys,

this is some kind of next stage of my previous queston. Namely, I have top
block with two flowgraphs, rx_path and tx_path. tx_path produces known
number of samples during which time rx_path receivees. As soon as tx_path
is finishes I should also stop rx_path, or at least to close certain file
sinks. Is there any way to catch that flowgraph (in this case subflograph)
is finished with execution and have no more samples to produce?

Best and thanx again,

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

Re: [Discuss-gnuradio] restarting sub flow graph

[Nemanja Savic]

It is always funny to answer my own questions. But the previous problem I
addressed is easily solved with lock() and unlock() methods.

On Thu, Apr 30, 2015 at 12:31 PM, Nemanja Savic  wrote:

> In fact I would like to explain a bit more.
> The flowgraph consists of rx and tx path:
>
> WBX daughterboard ---> RX path
> TX path > LFTX daughterboard
>
> I have random source inside tx path. I want to set a number of bits that
> will be produced, then run TX path and record received symbols in RX path.
> When I set a certain number of bits inside TX path, after the bits are
> generated, TX path doesn't have anything to do and should stop. So my
> question is how to rerun it again.
>
> Nemanja
>
> On Thu, Apr 30, 2015 at 12:20 PM, Nemanja Savic 
> wrote:
>
>> Hello again guys,
>>
>> in my applicatoin I have two flow graphs, namely, rx and tx paths,
>> separated.
>> TX path generates pseudorandom bit sequence which is then turned into
>> digital signal and transmitted over LFTX board. This signal is fed into
>> signal generator in order to modulate FKS signal. Modulated signal is fed
>> back to WBX board, and the idea is to measure BER.
>> I want now to be able to restart TX and RX paths. If i Call lock() and
>> unlock() will flowgraph be restarted?
>>
>> Thanx
>>
>> --
>> Nemanja Savić
>>
>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] restarting sub flow graph

[Nemanja Savic]

In fact I would like to explain a bit more.
The flowgraph consists of rx and tx path:

WBX daughterboard ---> RX path
TX path > LFTX daughterboard

I have random source inside tx path. I want to set a number of bits that
will be produced, then run TX path and record received symbols in RX path.
When I set a certain number of bits inside TX path, after the bits are
generated, TX path doesn't have anything to do and should stop. So my
question is how to rerun it again.

Nemanja

On Thu, Apr 30, 2015 at 12:20 PM, Nemanja Savic  wrote:

> Hello again guys,
>
> in my applicatoin I have two flow graphs, namely, rx and tx paths,
> separated.
> TX path generates pseudorandom bit sequence which is then turned into
> digital signal and transmitted over LFTX board. This signal is fed into
> signal generator in order to modulate FKS signal. Modulated signal is fed
> back to WBX board, and the idea is to measure BER.
> I want now to be able to restart TX and RX paths. If i Call lock() and
> unlock() will flowgraph be restarted?
>
> Thanx
>
> --
> Nemanja Savić
>



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

[Discuss-gnuradio] restarting sub flow graph

[Nemanja Savic]

Hello again guys,

in my applicatoin I have two flow graphs, namely, rx and tx paths,
separated.
TX path generates pseudorandom bit sequence which is then turned into
digital signal and transmitted over LFTX board. This signal is fed into
signal generator in order to modulate FKS signal. Modulated signal is fed
back to WBX board, and the idea is to measure BER.
I want now to be able to restart TX and RX paths. If i Call lock() and
unlock() will flowgraph be restarted?

Thanx

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

Re: [Discuss-gnuradio] Multiple flowgraphs and GUI elements

[Nemanja Savic]

The one suggested for multiple flowgraphs in the gnuradio page Writing
python applications. Walkie talkie nbfm example (can't provide the name at
the moment).

Best,
Nemanja

On Mon, Apr 27, 2015 at 2:23 PM, Marcus Müller 
wrote:

> Hi Nemanja
>
> On 04/27/2015 01:18 PM, Nemanja Savic wrote:
> > Hi all guys,
> and girls :)
> >
> > I am building a gnuradio top block application where I want to have rx
> > and tx flographs. Something similar to the example provided with
> gnuradio.
> Which one of the dozens of examples?
>
> Greetings,
> Marcus
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



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

[Discuss-gnuradio] Multiple flowgraphs and GUI elements

[Nemanja Savic]

Hi all guys,

I am building a gnuradio top block application where I want to have rx and
tx flographs. Something similar to the example provided with gnuradio. I
want to make rx path and tx path, but the example doesn't use "common" way
for making GUI elements. Now, I am a little bit confused. Should GUI
elements be part of rx and tx path while in the top block, I should only
add them using Add or GridAdd methods?

Thanx

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

Re: [Discuss-gnuradio] two WBX boards synchronization

[Nemanja Savic]

Thank you Marcus. When I think of my application I can combine signals
after demodulator where the prolblem of phase shift is not present.
At the end I would like to ask what is the name of such architecture where
I receive with hor and ver antennas and combine baseband signal?

On Wed, Dec 10, 2014 at 1:41 AM, Marcus D. Leech  wrote:

>  On 12/09/2014 07:32 PM, Nemanja Savic wrote:
>
> is there any way to synchronize those two clocks sources?
>
> Not on a USRP1.
>
> On N200, there's support for "timed commands", which allows both
> synthesizers to be locked to the same phase when they're re-tuned, but
> that'll
>   leave you with a 0/180deg ambiguity, because the *mixer* used on the WBX
> uses a 2XLO scheme, and the LO phase splitter can't be forced into
>   a specific state on tuning.
>
> Synthesized LOs have this inherent property.  Even when two synthesizers
> share a common reference, it's unpredictable what their phase will be
>   when they lock to the LO.  More so for so-called fractional-N
> synthesizers, which are what's used in nearly everything these days.  In
> the case of
>   the WBX and SBX, they use a synthesizer from ADI (ADF4351) that has a
> fairly-rare "phase resynch" feature which allows the chip to bring the
>   resulting LO into a particular phase relative to the reference clock,
> using a hardware synchronization signal.  That signal, and the FPGA code to
>   make it work, is only available in the N2xx and X3xx family.  The USRP1
> FPGA codebase has been utterly-frozen for many years, and there's
>   *zero* room to do anything fancy, without leaving stuff out.
>
> The usual way around this is to use a calibration signal that is common to
> both receivers, and use that to calibrate-out the "per run" phase
>   difference.
>
>
>
>
>
> On Tue, Dec 9, 2014 at 4:51 PM, Marcus D. Leech  wrote:
>
>>  On 12/09/2014 04:42 AM, Nemanja Savic wrote:
>>
>> Shouldn't relative phase be constant and 90 degrees for example if
>> transmitted wave had circular polarization?
>>
>>  The samples will be time-aligned, but those samples will have been
>> derived from two independent analog downconversion
>>   chains, which means that the synthesized LO will have a different
>> relative phase (between the two sides) every time.
>>
>>
>>
>>
>> On Tue, Dec 9, 2014 at 10:38 AM, Nemanja Savic 
>> wrote:
>>
>>> Yes, the platform is USRP1. What is relative phase in this case if they
>>> are alligned in time?
>>>
>>> On Mon, Dec 8, 2014 at 4:19 PM,  wrote:
>>>
>>>>  You haven't stated which USRP motherboard platform, but I assume
>>>> you're talking about the USRP1, given the 4RX image.  Yes, the samples
>>>>  will be aligned in time, but the relative phase will be random every
>>>> time you re-tune or start a new session.
>>>>
>>>>
>>>>
>>>>
>>>> On 2014-12-08 06:03, Nemanja Savic wrote:
>>>>
>>>>   Hi all guys,
>>>>
>>>>  I am about to make a receiver with two WBX daughterboards. I want to
>>>> receive simultaneusly with horizontal and vertical antenna. For this
>>>> purpose I want to use 4RX FPGA image. My question signals obtained in this
>>>> way, from two daughterboards, alligned in time?
>>>>
>>>>  Many thanks,
>>>>
>>>> --
>>>> Nemanja Savić
>>>>
>>>>  ___
>>>> Discuss-gnuradio mailing 
>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>
>>>
>>>  --
>>> Nemanja Savić
>>>
>>
>>
>>
>> --
>> Nemanja Savić
>>
>>
>>
>>   --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
>
>
> --
> Nemanja Savić
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>


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

Re: [Discuss-gnuradio] two WBX boards synchronization

[Nemanja Savic]

is there any way to synchronize those two clocks sources?

On Tue, Dec 9, 2014 at 4:51 PM, Marcus D. Leech  wrote:

>  On 12/09/2014 04:42 AM, Nemanja Savic wrote:
>
> Shouldn't relative phase be constant and 90 degrees for example if
> transmitted wave had circular polarization?
>
> The samples will be time-aligned, but those samples will have been derived
> from two independent analog downconversion
>   chains, which means that the synthesized LO will have a different
> relative phase (between the two sides) every time.
>
>
>
>
> On Tue, Dec 9, 2014 at 10:38 AM, Nemanja Savic  wrote:
>
>> Yes, the platform is USRP1. What is relative phase in this case if they
>> are alligned in time?
>>
>> On Mon, Dec 8, 2014 at 4:19 PM,  wrote:
>>
>>>  You haven't stated which USRP motherboard platform, but I assume
>>> you're talking about the USRP1, given the 4RX image.  Yes, the samples
>>>  will be aligned in time, but the relative phase will be random every
>>> time you re-tune or start a new session.
>>>
>>>
>>>
>>>
>>> On 2014-12-08 06:03, Nemanja Savic wrote:
>>>
>>>   Hi all guys,
>>>
>>>  I am about to make a receiver with two WBX daughterboards. I want to
>>> receive simultaneusly with horizontal and vertical antenna. For this
>>> purpose I want to use 4RX FPGA image. My question signals obtained in this
>>> way, from two daughterboards, alligned in time?
>>>
>>>  Many thanks,
>>>
>>> --
>>> Nemanja Savić
>>>
>>>  ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>>  --
>> Nemanja Savić
>>
>
>
>
> --
> Nemanja Savić
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>


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

Re: [Discuss-gnuradio] two WBX boards synchronization

[Nemanja Savic]

Shouldn't relative phase be constant and 90 degrees for example if
transmitted wave had circular polarization?

On Tue, Dec 9, 2014 at 10:38 AM, Nemanja Savic  wrote:

> Yes, the platform is USRP1. What is relative phase in this case if they
> are alligned in time?
>
> On Mon, Dec 8, 2014 at 4:19 PM,  wrote:
>
>>  You haven't stated which USRP motherboard platform, but I assume you're
>> talking about the USRP1, given the 4RX image.  Yes, the samples
>>  will be aligned in time, but the relative phase will be random every
>> time you re-tune or start a new session.
>>
>>
>>
>>
>> On 2014-12-08 06:03, Nemanja Savic wrote:
>>
>>  Hi all guys,
>>
>> I am about to make a receiver with two WBX daughterboards. I want to
>> receive simultaneusly with horizontal and vertical antenna. For this
>> purpose I want to use 4RX FPGA image. My question signals obtained in this
>> way, from two daughterboards, alligned in time?
>>
>> Many thanks,
>>
>> --
>> Nemanja Savić
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] two WBX boards synchronization

[Nemanja Savic]

Yes, the platform is USRP1. What is relative phase in this case if they are
alligned in time?

On Mon, Dec 8, 2014 at 4:19 PM,  wrote:

>  You haven't stated which USRP motherboard platform, but I assume you're
> talking about the USRP1, given the 4RX image.  Yes, the samples
>  will be aligned in time, but the relative phase will be random every time
> you re-tune or start a new session.
>
>
>
>
> On 2014-12-08 06:03, Nemanja Savic wrote:
>
>  Hi all guys,
>
> I am about to make a receiver with two WBX daughterboards. I want to
> receive simultaneusly with horizontal and vertical antenna. For this
> purpose I want to use 4RX FPGA image. My question signals obtained in this
> way, from two daughterboards, alligned in time?
>
> Many thanks,
>
> --
> Nemanja Savić
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

[Discuss-gnuradio] two WBX boards synchronization

[Nemanja Savic]

Hi all guys,

I am about to make a receiver with two WBX daughterboards. I want to
receive simultaneusly with horizontal and vertical antenna. For this
purpose I want to use 4RX FPGA image. My question signals obtained in this
way, from two daughterboards, alligned in time?

Many thanks,

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

Re: [Discuss-gnuradio] pfb_arb_resampler test fail (3.7.3)

[Nemanja Savic]

Hi,

no, not any progress at all. I am still using good ol' 3.6.5.1 :)
actually i don't know what can be the problem and from where to start.
I can provide all the info u need for solving the problem if that is
important.
And yes, I didn't want to post again cause I thought nobody cares,so thank
you.



On Fri, Jun 13, 2014 at 3:25 PM, Tom Rondeau  wrote:

> On Mon, May 26, 2014 at 4:49 AM, Nemanja Savic  wrote:
>
>> Hi all guys,
>>
>> I am experiencing error when testing 3.7.3. The error report is following:
>>
>> OK
>> Using Volk machine: avx_64_mmx
>> -- Process completed
>>Passed
>>  95/177 Testing qa_pfb_arb_resampler
>> Test command: /bin/sh
>> /home/savi_ne/tools/gnuradio-3.7.3/build/gr-filter/python/filter/qa_pfb_arb_resampler_test.sh
>> Test timeout computed to be: 9.99988e+06
>> ...F.
>> ==
>> FAIL: test_ccf_001 (__main__.test_pfb_arb_resampler)
>> --
>> Traceback (most recent call last):
>>   File
>> "/home/savi_ne/tools/gnuradio-3.7.3/gr-filter/python/filter/qa_pfb_arb_resampler.py",
>> line 153, in test_ccf_001
>> self.assertComplexTuplesAlmostEqual(expected_data[-Ntest:],
>> dst_data[-Ntest:], 2)
>>   File
>> "/home/savi_ne/tools/gnuradio-3.7.3/gnuradio-runtime/python/gnuradio/gr_unittest.py",
>> line 74, in assertComplexTuplesAlmostEqual
>> self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>>   File
>> "/home/savi_ne/tools/gnuradio-3.7.3/gnuradio-runtime/python/gnuradio/gr_unittest.py",
>> line 47, in assertComplexAlmostEqual
>> (msg or '%s != %s within %s places' % (`first`, `second`, `places` ))
>> AssertionError: (-0.32564974754236342-0.94549047690899302j) !=
>> (-0.56183856725692749-0.82724255323410034j) within 2 places
>>
>> The processor is Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz. I use RHEL6.
>> Has anybody experienced this prolem?
>>
>> Best,
>>
>> --
>> Nemanja Savić
>>
>
>
> Hi Nemanja,
>
> Any progress on this from your end? Sounds like no one else is having this
> issue, including me. Without being able to reproduce it, I'm not sure what
> else I can do.
>
> Tom
>
>


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

[Discuss-gnuradio] pfb_arb_resampler test fail (3.7.3)

[Nemanja Savic]

Hi all guys,

I am experiencing error when testing 3.7.3. The error report is following:

OK
Using Volk machine: avx_64_mmx
-- Process completed
   Passed
 95/177 Testing qa_pfb_arb_resampler
Test command: /bin/sh
/home/savi_ne/tools/gnuradio-3.7.3/build/gr-filter/python/filter/qa_pfb_arb_resampler_test.sh
Test timeout computed to be: 9.99988e+06
...F.
==
FAIL: test_ccf_001 (__main__.test_pfb_arb_resampler)
--
Traceback (most recent call last):
  File
"/home/savi_ne/tools/gnuradio-3.7.3/gr-filter/python/filter/qa_pfb_arb_resampler.py",
line 153, in test_ccf_001
self.assertComplexTuplesAlmostEqual(expected_data[-Ntest:],
dst_data[-Ntest:], 2)
  File
"/home/savi_ne/tools/gnuradio-3.7.3/gnuradio-runtime/python/gnuradio/gr_unittest.py",
line 74, in assertComplexTuplesAlmostEqual
self.assertComplexAlmostEqual (a[i], b[i], places, msg)
  File
"/home/savi_ne/tools/gnuradio-3.7.3/gnuradio-runtime/python/gnuradio/gr_unittest.py",
line 47, in assertComplexAlmostEqual
(msg or '%s != %s within %s places' % (`first`, `second`, `places` ))
AssertionError: (-0.32564974754236342-0.94549047690899302j) !=
(-0.56183856725692749-0.82724255323410034j) within 2 places

The processor is Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz. I use RHEL6.
Has anybody experienced this prolem?

Best,

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

Re: [Discuss-gnuradio] error while building 3.7.3 on RHEL6

[Nemanja Savic]

So, is there any solution or nobody did see the last email?

Best,
Nemanja


On Tue, May 13, 2014 at 12:15 PM, Nemanja Savic  wrote:

> It is written:
> Using Volk machine: avx_64_mmx
>
> Best
>
>
> On Tue, May 13, 2014 at 10:49 AM, Martin Braun wrote:
>
>> On 12.05.2014 12:53, Nemanja Savic wrote:
>>
>>> I finally disabled doxygen and everything was built fine, but the test
>>> fails at pfb_arb_resampler:
>>>
>>> FAIL: test_ccf_001 (__main__.test_pfb_arb_resampler)
>>> --
>>> Traceback (most recent call last):
>>>File
>>> "/home/savi_ne/tools/gnuradio-3.7.3/gr-filter/python/filter/
>>> qa_pfb_arb_resampler.py",
>>> line 153, in test_ccf_001
>>>  self.assertComplexTuplesAlmostEqual(expected_data[-Ntest:],
>>> dst_data[-Ntest:], 2)
>>>File
>>> "/home/savi_ne/tools/gnuradio-3.7.3/gnuradio-runtime/python/
>>> gnuradio/gr_unittest.py",
>>> line 74, in assertComplexTuplesAlmostEqual
>>>  self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>>>File
>>> "/home/savi_ne/tools/gnuradio-3.7.3/gnuradio-runtime/python/
>>> gnuradio/gr_unittest.py",
>>> line 47, in assertComplexAlmostEqual
>>>  (msg or '%s != %s within %s places' % (`first`, `second`, `places`
>>> ))
>>> AssertionError: (-0.32564974754236342-0.94549047690899302j) !=
>>> (-0.56183856725692749-0.82724255323410034j) within 2 places
>>>
>>
>> Which VOLK machine are you using?
>>
>> Martin
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] Frequency modulation in GRC

[Nemanja Savic]

Well, when I use the same sensitivity as u, I cant see, but with higher
value u can see.U can use average option but still with that sensitivity u
will not see much.


On Fri, May 23, 2014 at 6:26 AM, jason sam  wrote:

> Hi,
> I have made the flowgraph as attached..It is showing the modulation in
> scope but in fft block it's continuously changing  so I am still unable to
> find out that what are the max and min frequencies??I know how to find that
> in theory but i want to prove it from my results..
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

[Discuss-gnuradio] multiple subscription to a single output message output port

[Nemanja Savic]

Hi all guys,

I currently have a hier block, and a several sub blocks are sending
messages to a block outside of hier block. Is it possible that all
subblocks subscribe to a unique output message port? At the moment I have
to change a lot of code when i am about to add a new block which sends
message.

Best,

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

Re: [Discuss-gnuradio] error while building 3.7.3 on RHEL6

[Nemanja Savic]

It is written:
Using Volk machine: avx_64_mmx

Best


On Tue, May 13, 2014 at 10:49 AM, Martin Braun wrote:

> On 12.05.2014 12:53, Nemanja Savic wrote:
>
>> I finally disabled doxygen and everything was built fine, but the test
>> fails at pfb_arb_resampler:
>>
>> FAIL: test_ccf_001 (__main__.test_pfb_arb_resampler)
>> --
>> Traceback (most recent call last):
>>File
>> "/home/savi_ne/tools/gnuradio-3.7.3/gr-filter/python/filter/
>> qa_pfb_arb_resampler.py",
>> line 153, in test_ccf_001
>>  self.assertComplexTuplesAlmostEqual(expected_data[-Ntest:],
>> dst_data[-Ntest:], 2)
>>File
>> "/home/savi_ne/tools/gnuradio-3.7.3/gnuradio-runtime/python/
>> gnuradio/gr_unittest.py",
>> line 74, in assertComplexTuplesAlmostEqual
>>  self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>>File
>> "/home/savi_ne/tools/gnuradio-3.7.3/gnuradio-runtime/python/
>> gnuradio/gr_unittest.py",
>> line 47, in assertComplexAlmostEqual
>>  (msg or '%s != %s within %s places' % (`first`, `second`, `places` ))
>> AssertionError: (-0.32564974754236342-0.94549047690899302j) !=
>> (-0.56183856725692749-0.82724255323410034j) within 2 places
>>
>
> Which VOLK machine are you using?
>
> Martin
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



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

Re: [Discuss-gnuradio] error while building 3.7.3 on RHEL6

[Nemanja Savic]

I finally disabled doxygen and everything was built fine, but the test
fails at pfb_arb_resampler:

FAIL: test_ccf_001 (__main__.test_pfb_arb_resampler)
--
Traceback (most recent call last):
  File
"/home/savi_ne/tools/gnuradio-3.7.3/gr-filter/python/filter/qa_pfb_arb_resampler.py",
line 153, in test_ccf_001
self.assertComplexTuplesAlmostEqual(expected_data[-Ntest:],
dst_data[-Ntest:], 2)
  File
"/home/savi_ne/tools/gnuradio-3.7.3/gnuradio-runtime/python/gnuradio/gr_unittest.py",
line 74, in assertComplexTuplesAlmostEqual
self.assertComplexAlmostEqual (a[i], b[i], places, msg)
  File
"/home/savi_ne/tools/gnuradio-3.7.3/gnuradio-runtime/python/gnuradio/gr_unittest.py",
line 47, in assertComplexAlmostEqual
(msg or '%s != %s within %s places' % (`first`, `second`, `places` ))
AssertionError: (-0.32564974754236342-0.94549047690899302j) !=
(-0.56183856725692749-0.82724255323410034j) within 2 places

Did anybody has the same problem?

Best,
Nemanja


On Fri, May 9, 2014 at 4:06 PM, Tom Rondeau  wrote:

> On Fri, May 9, 2014 at 10:00 AM, Nemanja Savic  wrote:
>
>> It look like RHEL6 use really old library:
>> qt3-3.3.8b-30.el6.x86_64
>>
>
> Well that doesn't make any sense. gr-qtgui looks for QT 4.2 or higher. It
> should not have even been enabled without finding QT4 on your system. Are
> you sure that's the only version of QT you have installed?
>
> And yes, Redhat is years behind. I suggest using pybombs (
> gnuradio.org/pybombs), which was build for such purposes.
>
> Tom
>
>
>
>
>> On Fri, May 9, 2014 at 3:49 PM, Tom Rondeau  wrote:
>>
>>> On Fri, May 9, 2014 at 9:43 AM, Nemanja Savic wrote:
>>>
>>>> Ok, I'll try there. Do you have any idea what is the problem with QFile
>>>> while building qtgui.
>>>>
>>>
>>> That one seems strange, being such an integral part of QT. But my guess
>>> is that it's an API change in a QT version that we missed. (We'll be
>>> updating the QT minimum version in 3.8).
>>>
>>> When asking questions related to a dependency like this, it's always
>>> best to give us the the version of the library.
>>>
>>> Tom
>>>
>>>
>>>
>>>> On Fri, May 9, 2014 at 3:37 PM, Tom Rondeau  wrote:
>>>>
>>>>> On Fri, May 9, 2014 at 9:29 AM, Nemanja Savic wrote:
>>>>>
>>>>>> make in gr-trellis folder works, but when I run again from build
>>>>>> folder the same error appears.
>>>>>>
>>>>>
>>>>> Ok, well this is getting boring. For things like this, best to jump
>>>>> into our IRC chatroom to work through it. No one wants to see us go back 
>>>>> in
>>>>> forth on "try this and that." Any followup should be a resolution.
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Fri, May 9, 2014 at 3:15 PM, Tom Rondeau  wrote:
>>>>>>
>>>>>>> On Fri, May 9, 2014 at 9:14 AM, Nemanja Savic wrote:
>>>>>>>
>>>>>>>> I am trying to build 3.7.3, and doxygen version is:
>>>>>>>> doxygen-1.6.1-6.el6.x86_64.
>>>>>>>> I tried to run again and got the error again.
>>>>>>>>
>>>>>>>
>>>>>>> try: "cd gr-trellis; make" and let that complete. Then try again.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>  On Fri, May 9, 2014 at 3:09 PM, Tom Rondeau wrote:
>>>>>>>>
>>>>>>>>> On Fri, May 9, 2014 at 8:01 AM, Nemanja Savic 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Unfortunatelly there is another error which is not reported by
>>>>>>>>>> anybody since now:
>>>>>>>>>>
>>>>>>>>>> [ 74%] Building CXX object
>>>>>>>>>> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/qtgui_util.cc.o
>>>>>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc: In
>>>>>>>>>> function ‘QString get_qt_style_sheet(QString)’:
>>>>>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-q

Re: [Discuss-gnuradio] broken gnuplot

[Nemanja Savic]

If somebody have the same problem, just install pyopengl from source.


On Thu, May 8, 2014 at 6:11 PM, Nemanja Savic  wrote:

> Hi all again,
>
> actually yes, the problem was due to numpy. Namely, I uninstalled 1.4.1
> which I have on my RHEL6 and installed 1.5 or something. During that opengl
> was somehow deleted and when I installed using package manager, numpy 1.4.1
> was installed again.
>
> best
>
>
> On Wed, Feb 26, 2014 at 6:27 PM, Tom Rondeau  wrote:
>
>> On Wed, Feb 26, 2014 at 6:23 AM, Nemanja Savic 
>> wrote:
>> > When I use nongl option, then the gui looks like on the figure I
>> posted, and
>> > when I use gl option, the follosing error occures:
>> > Traceback (most recent call last):
>> >   File "/home/savi_ne/work/gnuradio/GRC/top_block.py", line 14, in
>> 
>> > from gnuradio.wxgui import fftsink2
>> >   File
>> > "/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/fftsink2.py",
>> line
>> > 34, in 
>> > raise RuntimeError("Unable to import OpenGL.  Are Python wrappers
>> for
>> > OpenGL installed?")
>> > RuntimeError: Unable to import OpenGL.  Are Python wrappers for OpenGL
>> > installed?
>>
>> Ok, so definitely stick with the non-OpenGL version.
>>
>> As to why it's stopped working for you, I can't say. Can you roll back
>> to an older version of GNU Radio that you know was working to see if
>> it's something there? If not, it's something with your system, and we
>> can't really be much help with that.
>>
>> Tom
>>
>>
>>
>> > On Tue, Feb 25, 2014 at 11:45 PM, Nemanja Savic 
>> wrote:
>> >>
>> >> Thank you Tom. I try tomorrow.
>> >>
>> >>
>> >> On Tue, Feb 25, 2014 at 4:20 PM, Tom Rondeau  wrote:
>> >>>
>> >>> On Tue, Feb 25, 2014 at 9:35 AM, Nemanja Savic 
>> >>> wrote:
>> >>> > Is there any way to repair this, because one or two months ago,
>> >>> > everything
>> >>> > was ok? Or, is there any log where I can figure what is the exact
>> >>> > problem?
>> >>>
>> >>> Well, since we don't know what you changed on your side, it's hard to
>> >>> help you fix it. Again, numpy, matplotlib, and gnuplot have nothing to
>> >>> do with this.
>> >>>
>> >>> Have you tried my suggestion of turning opengl off? That tends to be
>> >>> the main problem people have with using wxgui.
>> >>>
>> >>> Tom
>> >>>
>> >>>
>> >>>
>> >>> > On Tue, Feb 25, 2014 at 3:02 PM, Tom Rondeau 
>> wrote:
>> >>> >>
>> >>> >> On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic > >
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> So, it is default installation. I use RHEL6. Some time ago I
>> >>> >>> uninstalled
>> >>> >>> numpy due to installation of new version of matplotlib (I don't
>> know
>> >>> >>> if this
>> >>> >>> is important).
>> >>> >>> Now my gui looks like this
>> >>> >>
>> >>> >>
>> >>> >> That's using wxPython, not gnuplot. It doesn't use matplotlib,
>> either
>> >>> >> (which depends on numpy, so if you installed matplotlib, you also
>> >>> >> still have
>> >>> >> numpy). That will have no effect on the wxgui plots.
>> >>> >>
>> >>> >> This is possibly related to opengl, though. You can turn that off
>> by
>> >>> >> editing $prefix/etc/gnuradio/conf.d/gr-wxgui.conf.
>> >>> >>
>> >>> >> Tom
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>>
>> >>> >>> On Tue, Feb 25, 2014 at 1:13 PM, Martin Braun
>> >>> >>> 
>> >>> >>> wrote:
>> >>> >>>>
>> >>> >>>> On 02/25/2014 12:49 PM, Nemanja Savic wrote:
>> >>> >>>> > Hi all guys,
>> >>> >>>> >
>> >>> >>>> > lately I have experienced some problems with showing scope and
>> fft
>> >>> >>>> > plot.
>> >>> >>>> > Namely, the plots looks raw and ugly. Once there was an report
>> >>> >>>> > that
>> >>> >>>> > gnuplot was killed.
>> >>> >>>> >
>> >>> >>>> > Any idea how to check and repair this?
>> >>> >>>>
>> >>> >>>> Are you using gnuplot?
>> >>> >>>>
>> >>> >>>> What exactly are doing and which tools are you using?
>> >>> >>>>
>> >>> >>>> M
>> >>> >>>>
>> >>> >>>> ___
>> >>> >>>> Discuss-gnuradio mailing list
>> >>> >>>> Discuss-gnuradio@gnu.org
>> >>> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> --
>> >>> >>> Nemanja Savić
>> >>> >>>
>> >>> >>> ___
>> >>> >>> Discuss-gnuradio mailing list
>> >>> >>> Discuss-gnuradio@gnu.org
>> >>> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>> >>>
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Nemanja Savić
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Nemanja Savić
>> >
>> >
>> >
>> >
>> > --
>> > Nemanja Savić
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>>
>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] error while building 3.7.3 on RHEL6

[Nemanja Savic]

It look like RHEL6 use really old library:
qt3-3.3.8b-30.el6.x86_64


On Fri, May 9, 2014 at 3:49 PM, Tom Rondeau  wrote:

> On Fri, May 9, 2014 at 9:43 AM, Nemanja Savic  wrote:
>
>> Ok, I'll try there. Do you have any idea what is the problem with QFile
>> while building qtgui.
>>
>
> That one seems strange, being such an integral part of QT. But my guess is
> that it's an API change in a QT version that we missed. (We'll be updating
> the QT minimum version in 3.8).
>
> When asking questions related to a dependency like this, it's always best
> to give us the the version of the library.
>
> Tom
>
>
>
>> On Fri, May 9, 2014 at 3:37 PM, Tom Rondeau  wrote:
>>
>>> On Fri, May 9, 2014 at 9:29 AM, Nemanja Savic wrote:
>>>
>>>> make in gr-trellis folder works, but when I run again from build folder
>>>> the same error appears.
>>>>
>>>
>>> Ok, well this is getting boring. For things like this, best to jump into
>>> our IRC chatroom to work through it. No one wants to see us go back in
>>> forth on "try this and that." Any followup should be a resolution.
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>>> On Fri, May 9, 2014 at 3:15 PM, Tom Rondeau  wrote:
>>>>
>>>>> On Fri, May 9, 2014 at 9:14 AM, Nemanja Savic wrote:
>>>>>
>>>>>> I am trying to build 3.7.3, and doxygen version is:
>>>>>> doxygen-1.6.1-6.el6.x86_64.
>>>>>> I tried to run again and got the error again.
>>>>>>
>>>>>
>>>>> try: "cd gr-trellis; make" and let that complete. Then try again.
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>  On Fri, May 9, 2014 at 3:09 PM, Tom Rondeau wrote:
>>>>>>
>>>>>>> On Fri, May 9, 2014 at 8:01 AM, Nemanja Savic wrote:
>>>>>>>
>>>>>>>> Unfortunatelly there is another error which is not reported by
>>>>>>>> anybody since now:
>>>>>>>>
>>>>>>>> [ 74%] Building CXX object
>>>>>>>> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/qtgui_util.cc.o
>>>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc: In
>>>>>>>> function ‘QString get_qt_style_sheet(QString)’:
>>>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:30:
>>>>>>>> error: ‘QFile’ was not declared in this scope
>>>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:30:
>>>>>>>> error: expected ‘;’ before ‘ss’
>>>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:31:
>>>>>>>> error: ‘ss’ was not declared in this scope
>>>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:35:
>>>>>>>> error: ‘ss’ was not declared in this scope
>>>>>>>> make[2]: ***
>>>>>>>> [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/qtgui_util.cc.o] Error 1
>>>>>>>> make[1]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error
>>>>>>>> 2
>>>>>>>> make: *** [all] Error 2
>>>>>>>>
>>>>>>>> Since I use only WXGui I tried to turn off QtGUI in the
>>>>>>>> configuration by running ccmake and setting the flag to off, but then 
>>>>>>>> some
>>>>>>>> other problems appear rgarding doxigen:
>>>>>>>>
>>>>>>>> Scanning dependencies of target digital_generated_includes
>>>>>>>> [  6%] Generating chunks_to_symbols_bf.h, chunks_to_symbols_bc.h,
>>>>>>>> chunks_to_symbols_sf.h, chunks_to_symbols_sc.h, chunks_to_symbols_if.h,
>>>>>>>> chunks_to_symbols_ic.h
>>>>>>>> [  6%] Built target digital_generated_includes
>>>>>>>> Scanning dependencies of target doxygen_target
>>>>>>>> make[2]: *** No rule to make target `trellis_generated_includes',
>>>>>>>> needed by `docs/doxygen/xml'.  Stop.
>>>>>>>> make[1]: *** [docs/doxygen/CMakeFiles/doxygen_target.dir/all] Error
>>>>>>>> 2
>>>>>>>> make: **

Re: [Discuss-gnuradio] error while building 3.7.3 on RHEL6

[Nemanja Savic]

Ok, I'll try there. Do you have any idea what is the problem with QFile
while building qtgui.


On Fri, May 9, 2014 at 3:37 PM, Tom Rondeau  wrote:

> On Fri, May 9, 2014 at 9:29 AM, Nemanja Savic  wrote:
>
>> make in gr-trellis folder works, but when I run again from build folder
>> the same error appears.
>>
>
> Ok, well this is getting boring. For things like this, best to jump into
> our IRC chatroom to work through it. No one wants to see us go back in
> forth on "try this and that." Any followup should be a resolution.
>
> Tom
>
>
>
>
>> On Fri, May 9, 2014 at 3:15 PM, Tom Rondeau  wrote:
>>
>>> On Fri, May 9, 2014 at 9:14 AM, Nemanja Savic wrote:
>>>
>>>> I am trying to build 3.7.3, and doxygen version is:
>>>> doxygen-1.6.1-6.el6.x86_64.
>>>> I tried to run again and got the error again.
>>>>
>>>
>>> try: "cd gr-trellis; make" and let that complete. Then try again.
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>>>  On Fri, May 9, 2014 at 3:09 PM, Tom Rondeau  wrote:
>>>>
>>>>> On Fri, May 9, 2014 at 8:01 AM, Nemanja Savic wrote:
>>>>>
>>>>>> Unfortunatelly there is another error which is not reported by
>>>>>> anybody since now:
>>>>>>
>>>>>> [ 74%] Building CXX object
>>>>>> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/qtgui_util.cc.o
>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc: In
>>>>>> function ‘QString get_qt_style_sheet(QString)’:
>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:30:
>>>>>> error: ‘QFile’ was not declared in this scope
>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:30:
>>>>>> error: expected ‘;’ before ‘ss’
>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:31:
>>>>>> error: ‘ss’ was not declared in this scope
>>>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:35:
>>>>>> error: ‘ss’ was not declared in this scope
>>>>>> make[2]: ***
>>>>>> [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/qtgui_util.cc.o] Error 1
>>>>>> make[1]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
>>>>>> make: *** [all] Error 2
>>>>>>
>>>>>> Since I use only WXGui I tried to turn off QtGUI in the configuration
>>>>>> by running ccmake and setting the flag to off, but then some other 
>>>>>> problems
>>>>>> appear rgarding doxigen:
>>>>>>
>>>>>> Scanning dependencies of target digital_generated_includes
>>>>>> [  6%] Generating chunks_to_symbols_bf.h, chunks_to_symbols_bc.h,
>>>>>> chunks_to_symbols_sf.h, chunks_to_symbols_sc.h, chunks_to_symbols_if.h,
>>>>>> chunks_to_symbols_ic.h
>>>>>> [  6%] Built target digital_generated_includes
>>>>>> Scanning dependencies of target doxygen_target
>>>>>> make[2]: *** No rule to make target `trellis_generated_includes',
>>>>>> needed by `docs/doxygen/xml'.  Stop.
>>>>>> make[1]: *** [docs/doxygen/CMakeFiles/doxygen_target.dir/all] Error 2
>>>>>> make: *** [all] Error 2
>>>>>>
>>>>>> Hw can I now overcome this?
>>>>>>
>>>>>> Thanx,
>>>>>> Nemanja
>>>>>>
>>>>>
>>>>> Just try running 'make' again. What version are you using? That
>>>>> doxygen bug should have been fixed already.
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>  On Fri, May 9, 2014 at 12:39 PM, Nemanja Savic 
>>>>>> wrote:
>>>>>>
>>>>>>> You are right regarding search, I have no excuse, and thanks for
>>>>>>> helping me.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, May 9, 2014 at 12:02 PM, Marcus Müller <
>>>>>>> marcus.muel...@ettus.com> wrote:
>>>>>>>
>>>>>>>> Hi Nemanja,
>>>>>>>>
>>>>>>>> that issue has been fixed in more recent GR versions (it was a
>>>>>

Re: [Discuss-gnuradio] error while building 3.7.3 on RHEL6

[Nemanja Savic]

make in gr-trellis folder works, but when I run again from build folder the
same error appears.


On Fri, May 9, 2014 at 3:15 PM, Tom Rondeau  wrote:

> On Fri, May 9, 2014 at 9:14 AM, Nemanja Savic  wrote:
>
>> I am trying to build 3.7.3, and doxygen version is:
>> doxygen-1.6.1-6.el6.x86_64.
>> I tried to run again and got the error again.
>>
>
> try: "cd gr-trellis; make" and let that complete. Then try again.
>
> Tom
>
>
>
>
>>  On Fri, May 9, 2014 at 3:09 PM, Tom Rondeau  wrote:
>>
>>> On Fri, May 9, 2014 at 8:01 AM, Nemanja Savic wrote:
>>>
>>>> Unfortunatelly there is another error which is not reported by anybody
>>>> since now:
>>>>
>>>> [ 74%] Building CXX object
>>>> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/qtgui_util.cc.o
>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc: In
>>>> function ‘QString get_qt_style_sheet(QString)’:
>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:30:
>>>> error: ‘QFile’ was not declared in this scope
>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:30:
>>>> error: expected ‘;’ before ‘ss’
>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:31:
>>>> error: ‘ss’ was not declared in this scope
>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:35:
>>>> error: ‘ss’ was not declared in this scope
>>>> make[2]: ***
>>>> [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/qtgui_util.cc.o] Error 1
>>>> make[1]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
>>>> make: *** [all] Error 2
>>>>
>>>> Since I use only WXGui I tried to turn off QtGUI in the configuration
>>>> by running ccmake and setting the flag to off, but then some other problems
>>>> appear rgarding doxigen:
>>>>
>>>> Scanning dependencies of target digital_generated_includes
>>>> [  6%] Generating chunks_to_symbols_bf.h, chunks_to_symbols_bc.h,
>>>> chunks_to_symbols_sf.h, chunks_to_symbols_sc.h, chunks_to_symbols_if.h,
>>>> chunks_to_symbols_ic.h
>>>> [  6%] Built target digital_generated_includes
>>>> Scanning dependencies of target doxygen_target
>>>> make[2]: *** No rule to make target `trellis_generated_includes',
>>>> needed by `docs/doxygen/xml'.  Stop.
>>>> make[1]: *** [docs/doxygen/CMakeFiles/doxygen_target.dir/all] Error 2
>>>> make: *** [all] Error 2
>>>>
>>>> Hw can I now overcome this?
>>>>
>>>> Thanx,
>>>> Nemanja
>>>>
>>>
>>> Just try running 'make' again. What version are you using? That doxygen
>>> bug should have been fixed already.
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>>>  On Fri, May 9, 2014 at 12:39 PM, Nemanja Savic wrote:
>>>>
>>>>> You are right regarding search, I have no excuse, and thanks for
>>>>> helping me.
>>>>>
>>>>>
>>>>> On Fri, May 9, 2014 at 12:02 PM, Marcus Müller <
>>>>> marcus.muel...@ettus.com> wrote:
>>>>>
>>>>>> Hi Nemanja,
>>>>>>
>>>>>> that issue has been fixed in more recent GR versions (it was a
>>>>>> incompatibility with old Boost versions).
>>>>>> If you do not wish to update GNU Radio, just replace
>>>>>> boost::random::mt19937 by boost::mt19937 in
>>>>>>  message_strobe_random_impl.
>>>>>>
>>>>>> Greetings,
>>>>>> Marcus
>>>>>>
>>>>>> PS: Googling for "error: ‘mt19937’ in namespace ‘boost::random’ does
>>>>>> not
>>>>>> name a type" turns up my previous posts about the issue. This is
>>>>>> really
>>>>>> just a friendly reminder that you should make sure that your questions
>>>>>> have not yet been answered before posting to the list, since this is
>>>>>> more often than not even faster than asking :)
>>>>>>
>>>>>> On 09.05.2014 11:12, Nemanja Savic wrote:
>>>>>> > Hi all guys,
>>>>>> >
>>>>>> > I have again prob;lem building new version of gnuradio on my RHEL6
>>>>>> machine.
>>>>>> > The error is following:
>

Re: [Discuss-gnuradio] error while building 3.7.3 on RHEL6

[Nemanja Savic]

I am trying to build 3.7.3, and doxygen version is:
doxygen-1.6.1-6.el6.x86_64.
I tried to run again and got the error again.



On Fri, May 9, 2014 at 3:09 PM, Tom Rondeau  wrote:

> On Fri, May 9, 2014 at 8:01 AM, Nemanja Savic  wrote:
>
>> Unfortunatelly there is another error which is not reported by anybody
>> since now:
>>
>> [ 74%] Building CXX object
>> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/qtgui_util.cc.o
>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc: In
>> function ‘QString get_qt_style_sheet(QString)’:
>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:30: error:
>> ‘QFile’ was not declared in this scope
>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:30: error:
>> expected ‘;’ before ‘ss’
>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:31: error:
>> ‘ss’ was not declared in this scope
>> /home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:35: error:
>> ‘ss’ was not declared in this scope
>> make[2]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/qtgui_util.cc.o]
>> Error 1
>> make[1]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> Since I use only WXGui I tried to turn off QtGUI in the configuration by
>> running ccmake and setting the flag to off, but then some other problems
>> appear rgarding doxigen:
>>
>> Scanning dependencies of target digital_generated_includes
>> [  6%] Generating chunks_to_symbols_bf.h, chunks_to_symbols_bc.h,
>> chunks_to_symbols_sf.h, chunks_to_symbols_sc.h, chunks_to_symbols_if.h,
>> chunks_to_symbols_ic.h
>> [  6%] Built target digital_generated_includes
>> Scanning dependencies of target doxygen_target
>> make[2]: *** No rule to make target `trellis_generated_includes', needed
>> by `docs/doxygen/xml'.  Stop.
>> make[1]: *** [docs/doxygen/CMakeFiles/doxygen_target.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> Hw can I now overcome this?
>>
>> Thanx,
>> Nemanja
>>
>
> Just try running 'make' again. What version are you using? That doxygen
> bug should have been fixed already.
>
> Tom
>
>
>
>
>> On Fri, May 9, 2014 at 12:39 PM, Nemanja Savic wrote:
>>
>>> You are right regarding search, I have no excuse, and thanks for helping
>>> me.
>>>
>>>
>>> On Fri, May 9, 2014 at 12:02 PM, Marcus Müller >> > wrote:
>>>
>>>> Hi Nemanja,
>>>>
>>>> that issue has been fixed in more recent GR versions (it was a
>>>> incompatibility with old Boost versions).
>>>> If you do not wish to update GNU Radio, just replace
>>>> boost::random::mt19937 by boost::mt19937 in  message_strobe_random_impl.
>>>>
>>>> Greetings,
>>>> Marcus
>>>>
>>>> PS: Googling for "error: ‘mt19937’ in namespace ‘boost::random’ does not
>>>> name a type" turns up my previous posts about the issue. This is really
>>>> just a friendly reminder that you should make sure that your questions
>>>> have not yet been answered before posting to the list, since this is
>>>> more often than not even faster than asking :)
>>>>
>>>> On 09.05.2014 11:12, Nemanja Savic wrote:
>>>> > Hi all guys,
>>>> >
>>>> > I have again prob;lem building new version of gnuradio on my RHEL6
>>>> machine.
>>>> > The error is following:
>>>> >
>>>> > [ 26%] Building CXX object
>>>> >
>>>> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/message_strobe_random_impl.cc.o
>>>> > In file included from
>>>> >
>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:27:
>>>> >
>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.h:48:
>>>> > error: ‘mt19937’ in namespace ‘boost::random’ does not name a type
>>>> >
>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:
>>>> > In constructor
>>>> >
>>>> ‘gr::blocks::message_strobe_random_impl::message_strobe_random_impl(pmt::pmt_t,
>>>> > gr::blocks::message_strobe_random_distribution_t, float, float)’:
>>>> >
>>>> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:57:
>>>> > error: class ‘gr::blocks::message_strobe_random_impl’ does not have
>>>&g

Re: [Discuss-gnuradio] error while building 3.7.3 on RHEL6

[Nemanja Savic]

Unfortunatelly there is another error which is not reported by anybody
since now:

[ 74%] Building CXX object
gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/qtgui_util.cc.o
/home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc: In function
‘QString get_qt_style_sheet(QString)’:
/home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:30: error:
‘QFile’ was not declared in this scope
/home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:30: error:
expected ‘;’ before ‘ss’
/home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:31: error:
‘ss’ was not declared in this scope
/home/savi_ne/tools/gnuradio-3.7.3/gr-qtgui/lib/qtgui_util.cc:35: error:
‘ss’ was not declared in this scope
make[2]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/qtgui_util.cc.o]
Error 1
make[1]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
make: *** [all] Error 2

Since I use only WXGui I tried to turn off QtGUI in the configuration by
running ccmake and setting the flag to off, but then some other problems
appear rgarding doxigen:

Scanning dependencies of target digital_generated_includes
[  6%] Generating chunks_to_symbols_bf.h, chunks_to_symbols_bc.h,
chunks_to_symbols_sf.h, chunks_to_symbols_sc.h, chunks_to_symbols_if.h,
chunks_to_symbols_ic.h
[  6%] Built target digital_generated_includes
Scanning dependencies of target doxygen_target
make[2]: *** No rule to make target `trellis_generated_includes', needed by
`docs/doxygen/xml'.  Stop.
make[1]: *** [docs/doxygen/CMakeFiles/doxygen_target.dir/all] Error 2
make: *** [all] Error 2

Hw can I now overcome this?

Thanx,
Nemanja



On Fri, May 9, 2014 at 12:39 PM, Nemanja Savic  wrote:

> You are right regarding search, I have no excuse, and thanks for helping
> me.
>
>
> On Fri, May 9, 2014 at 12:02 PM, Marcus Müller 
> wrote:
>
>> Hi Nemanja,
>>
>> that issue has been fixed in more recent GR versions (it was a
>> incompatibility with old Boost versions).
>> If you do not wish to update GNU Radio, just replace
>> boost::random::mt19937 by boost::mt19937 in  message_strobe_random_impl.
>>
>> Greetings,
>> Marcus
>>
>> PS: Googling for "error: ‘mt19937’ in namespace ‘boost::random’ does not
>> name a type" turns up my previous posts about the issue. This is really
>> just a friendly reminder that you should make sure that your questions
>> have not yet been answered before posting to the list, since this is
>> more often than not even faster than asking :)
>>
>> On 09.05.2014 11:12, Nemanja Savic wrote:
>> > Hi all guys,
>> >
>> > I have again prob;lem building new version of gnuradio on my RHEL6
>> machine.
>> > The error is following:
>> >
>> > [ 26%] Building CXX object
>> >
>> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/message_strobe_random_impl.cc.o
>> > In file included from
>> >
>> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:27:
>> >
>> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.h:48:
>> > error: ‘mt19937’ in namespace ‘boost::random’ does not name a type
>> >
>> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:
>> > In constructor
>> >
>> ‘gr::blocks::message_strobe_random_impl::message_strobe_random_impl(pmt::pmt_t,
>> > gr::blocks::message_strobe_random_distribution_t, float, float)’:
>> >
>> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:57:
>> > error: class ‘gr::blocks::message_strobe_random_impl’ does not have any
>> > field named ‘d_rng’
>> >
>> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:
>> > In member function ‘void
>> > gr::blocks::message_strobe_random_impl::update_dist()’:
>> >
>> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:89:
>> > error: ‘d_rng’ was not declared in this scope
>> > make[2]: ***
>> >
>> [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/message_strobe_random_impl.cc.o]
>> > Error 1
>> > make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2
>> >
>> > Has anybody had this error before?
>> >
>> > Best,
>> >
>> >
>> >
>> > ___
>> > 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
>>
>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] error while building 3.7.3 on RHEL6

[Nemanja Savic]

You are right regarding search, I have no excuse, and thanks for helping me.


On Fri, May 9, 2014 at 12:02 PM, Marcus Müller wrote:

> Hi Nemanja,
>
> that issue has been fixed in more recent GR versions (it was a
> incompatibility with old Boost versions).
> If you do not wish to update GNU Radio, just replace
> boost::random::mt19937 by boost::mt19937 in  message_strobe_random_impl.
>
> Greetings,
> Marcus
>
> PS: Googling for "error: ‘mt19937’ in namespace ‘boost::random’ does not
> name a type" turns up my previous posts about the issue. This is really
> just a friendly reminder that you should make sure that your questions
> have not yet been answered before posting to the list, since this is
> more often than not even faster than asking :)
>
> On 09.05.2014 11:12, Nemanja Savic wrote:
> > Hi all guys,
> >
> > I have again prob;lem building new version of gnuradio on my RHEL6
> machine.
> > The error is following:
> >
> > [ 26%] Building CXX object
> >
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/message_strobe_random_impl.cc.o
> > In file included from
> >
> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:27:
> >
> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.h:48:
> > error: ‘mt19937’ in namespace ‘boost::random’ does not name a type
> >
> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:
> > In constructor
> >
> ‘gr::blocks::message_strobe_random_impl::message_strobe_random_impl(pmt::pmt_t,
> > gr::blocks::message_strobe_random_distribution_t, float, float)’:
> >
> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:57:
> > error: class ‘gr::blocks::message_strobe_random_impl’ does not have any
> > field named ‘d_rng’
> >
> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:
> > In member function ‘void
> > gr::blocks::message_strobe_random_impl::update_dist()’:
> >
> /home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:89:
> > error: ‘d_rng’ was not declared in this scope
> > make[2]: ***
> >
> [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/message_strobe_random_impl.cc.o]
> > Error 1
> > make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2
> >
> > Has anybody had this error before?
> >
> > Best,
> >
> >
> >
> > ___
> > 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
>



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

[Discuss-gnuradio] error while building 3.7.3 on RHEL6

[Nemanja Savic]

Hi all guys,

I have again prob;lem building new version of gnuradio on my RHEL6 machine.
The error is following:

[ 26%] Building CXX object
gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/message_strobe_random_impl.cc.o
In file included from
/home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:27:
/home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.h:48:
error: ‘mt19937’ in namespace ‘boost::random’ does not name a type
/home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:
In constructor
‘gr::blocks::message_strobe_random_impl::message_strobe_random_impl(pmt::pmt_t,
gr::blocks::message_strobe_random_distribution_t, float, float)’:
/home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:57:
error: class ‘gr::blocks::message_strobe_random_impl’ does not have any
field named ‘d_rng’
/home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:
In member function ‘void
gr::blocks::message_strobe_random_impl::update_dist()’:
/home/savi_ne/tools/gnuradio-3.7.3/gr-blocks/lib/message_strobe_random_impl.cc:89:
error: ‘d_rng’ was not declared in this scope
make[2]: ***
[gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/message_strobe_random_impl.cc.o]
Error 1
make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2

Has anybody had this error before?

Best,

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

Re: [Discuss-gnuradio] broken gnuplot

[Nemanja Savic]

Hi all again,

actually yes, the problem was due to numpy. Namely, I uninstalled 1.4.1
which I have on my RHEL6 and installed 1.5 or something. During that opengl
was somehow deleted and when I installed using package manager, numpy 1.4.1
was installed again.

best


On Wed, Feb 26, 2014 at 6:27 PM, Tom Rondeau  wrote:

> On Wed, Feb 26, 2014 at 6:23 AM, Nemanja Savic  wrote:
> > When I use nongl option, then the gui looks like on the figure I posted,
> and
> > when I use gl option, the follosing error occures:
> > Traceback (most recent call last):
> >   File "/home/savi_ne/work/gnuradio/GRC/top_block.py", line 14, in
> 
> > from gnuradio.wxgui import fftsink2
> >   File
> > "/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/fftsink2.py",
> line
> > 34, in 
> > raise RuntimeError("Unable to import OpenGL.  Are Python wrappers for
> > OpenGL installed?")
> > RuntimeError: Unable to import OpenGL.  Are Python wrappers for OpenGL
> > installed?
>
> Ok, so definitely stick with the non-OpenGL version.
>
> As to why it's stopped working for you, I can't say. Can you roll back
> to an older version of GNU Radio that you know was working to see if
> it's something there? If not, it's something with your system, and we
> can't really be much help with that.
>
> Tom
>
>
>
> > On Tue, Feb 25, 2014 at 11:45 PM, Nemanja Savic 
> wrote:
> >>
> >> Thank you Tom. I try tomorrow.
> >>
> >>
> >> On Tue, Feb 25, 2014 at 4:20 PM, Tom Rondeau  wrote:
> >>>
> >>> On Tue, Feb 25, 2014 at 9:35 AM, Nemanja Savic 
> >>> wrote:
> >>> > Is there any way to repair this, because one or two months ago,
> >>> > everything
> >>> > was ok? Or, is there any log where I can figure what is the exact
> >>> > problem?
> >>>
> >>> Well, since we don't know what you changed on your side, it's hard to
> >>> help you fix it. Again, numpy, matplotlib, and gnuplot have nothing to
> >>> do with this.
> >>>
> >>> Have you tried my suggestion of turning opengl off? That tends to be
> >>> the main problem people have with using wxgui.
> >>>
> >>> Tom
> >>>
> >>>
> >>>
> >>> > On Tue, Feb 25, 2014 at 3:02 PM, Tom Rondeau 
> wrote:
> >>> >>
> >>> >> On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic 
> >>> >> wrote:
> >>> >>>
> >>> >>> So, it is default installation. I use RHEL6. Some time ago I
> >>> >>> uninstalled
> >>> >>> numpy due to installation of new version of matplotlib (I don't
> know
> >>> >>> if this
> >>> >>> is important).
> >>> >>> Now my gui looks like this
> >>> >>
> >>> >>
> >>> >> That's using wxPython, not gnuplot. It doesn't use matplotlib,
> either
> >>> >> (which depends on numpy, so if you installed matplotlib, you also
> >>> >> still have
> >>> >> numpy). That will have no effect on the wxgui plots.
> >>> >>
> >>> >> This is possibly related to opengl, though. You can turn that off by
> >>> >> editing $prefix/etc/gnuradio/conf.d/gr-wxgui.conf.
> >>> >>
> >>> >> Tom
> >>> >>
> >>> >>
> >>> >>
> >>> >>>
> >>> >>> On Tue, Feb 25, 2014 at 1:13 PM, Martin Braun
> >>> >>> 
> >>> >>> wrote:
> >>> >>>>
> >>> >>>> On 02/25/2014 12:49 PM, Nemanja Savic wrote:
> >>> >>>> > Hi all guys,
> >>> >>>> >
> >>> >>>> > lately I have experienced some problems with showing scope and
> fft
> >>> >>>> > plot.
> >>> >>>> > Namely, the plots looks raw and ugly. Once there was an report
> >>> >>>> > that
> >>> >>>> > gnuplot was killed.
> >>> >>>> >
> >>> >>>> > Any idea how to check and repair this?
> >>> >>>>
> >>> >>>> Are you using gnuplot?
> >>> >>>>
> >>> >>>> What exactly are doing and which tools are you using?
> >>> >>>>
> >>> >>>> M
> >>> >>>>
> >>> >>>> ___
> >>> >>>> Discuss-gnuradio mailing list
> >>> >>>> Discuss-gnuradio@gnu.org
> >>> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>> Nemanja Savić
> >>> >>>
> >>> >>> ___
> >>> >>> Discuss-gnuradio mailing list
> >>> >>> Discuss-gnuradio@gnu.org
> >>> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>> >>>
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Nemanja Savić
> >>
> >>
> >>
> >>
> >> --
> >> Nemanja Savić
> >
> >
> >
> >
> > --
> > Nemanja Savić
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>



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

Re: [Discuss-gnuradio] saving raw data after correct frame reception

[Nemanja Savic]

Ah, it has just came to my mind the following idea:
a block with history value of few miliseconds connected directly to usrp
source. The history can provide me previous data, but I would like to hear
if something like this has sense?

best


On Thu, May 8, 2014 at 5:21 PM, Nemanja Savic  wrote:

> Hi all again,
>
> regarding my previous email, I would like to ask you is there any more
> efficient way to buffer data in gnuradio except makind a block that just
> copies samples and waits for the signal to store them into file?
>
>
> On Tue, Apr 22, 2014 at 10:20 AM, Nemanja Savic wrote:
>
>> hi all guys,
>>
>> I would like to be able to store raw data into file after correct frame
>> reception. For this reason I suppose there should be a block that buffers
>> raw data and wait for the trigger to store into file.
>> The trigger can only be sent from packet deframer after checking
>> validity. So my questions are how could I synchronize those two blocks and
>> what should be the minimum length of the buffer, and what would be the
>> optimal way to do this, cause my processor is already under 90% of load.
>>
>> Best and thank you,
>>
>> --
>> Nemanja Savić
>>
>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] saving raw data after correct frame reception

[Nemanja Savic]

Hi all again,

regarding my previous email, I would like to ask you is there any more
efficient way to buffer data in gnuradio except makind a block that just
copies samples and waits for the signal to store them into file?


On Tue, Apr 22, 2014 at 10:20 AM, Nemanja Savic  wrote:

> hi all guys,
>
> I would like to be able to store raw data into file after correct frame
> reception. For this reason I suppose there should be a block that buffers
> raw data and wait for the trigger to store into file.
> The trigger can only be sent from packet deframer after checking validity.
> So my questions are how could I synchronize those two blocks and what
> should be the minimum length of the buffer, and what would be the optimal
> way to do this, cause my processor is already under 90% of load.
>
> Best and thank you,
>
> --
> Nemanja Savić
>



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

[Discuss-gnuradio] saving raw data after correct frame reception

[Nemanja Savic]

hi all guys,

I would like to be able to store raw data into file after correct frame
reception. For this reason I suppose there should be a block that buffers
raw data and wait for the trigger to store into file.
The trigger can only be sent from packet deframer after checking validity.
So my questions are how could I synchronize those two blocks and what
should be the minimum length of the buffer, and what would be the optimal
way to do this, cause my processor is already under 90% of load.

Best and thank you,

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

Re: [Discuss-gnuradio] catching unrecognized exception

[Nemanja Savic]

the last message was not clear.

So, I made sql syntax error and run the program, with my old syntax, and
exception was caught, so the error should be somewhere else.


On Wed, Apr 16, 2014 at 10:45 AM, Nemanja Savic  wrote:

> Hello again,
>
> Marcus, you are right, my syntax is not any more correct but there is
> backwards compatibility. I initiated error on my own and everything works
> fine, so I would say there should be rather something more serious.
>
>
> On Tue, Apr 15, 2014 at 4:31 PM, Marcus Müller  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi Nemanja,
>>
>> Simple explanation:
>> You haven't fixed your syntax for the first except clause.
>> Going back to my other post, it should read
>> "except mdb.Error as e:", not "except mdb.Error, e".
>>
>> Because you didn't do that, "e" is undefined in your except clause.
>> This raises a NameError in your except clause, which doesn't get
>> handled. Fix the except syntax.
>>
>> Also, don't do system.exit() in a multithreaded application, unless
>> you really know what you're doing. You'll end up with unfinished data,
>> broken database commits and so on.
>>
>> Greetings,
>> Marcus
>>
>> On 15.04.2014 15:40, Nemanja Savic wrote:
>> > Hi again,
>> >
>> > so, the exception appeared again. Just to remind:
>> > thread[thread-per-block[0]: ]: caught
>> > unrecognized exception
>> >
>> > I can't find what (65) means. This time complete block of code was
>> > encapsulated by try and except but nothing was caught.
>> >
>> > Here is my code:
>> >
>> > def handle_msg(self, msg): try: message =
>> > pmt.pmt_symbol_to_string(msg) msg_lines = message.split('\n')
>> > sensor_id = msg_lines[0] vendor = msg_lines[2] sensor_type =
>> > msg_lines[3] time = msg_lines[1] querry = "INSERT INTO `%s`.`%s`
>> > (`id` ,`sens_id` ,`vendor`, `sensor_type`, `det_id`) VALUES (NULL ,
>> > '%s', '%s', '%s','%s');" % (self._db_name, self._det_table,
>> > sensor_id, vendor, sensor_type, self._id) cur = self._con.cursor()
>> > cur.execute(querry) except mdb.Error, e: print "Unexpected error
>> > while trying to insert into table" print 50*'-' print 50*'-' print
>> > "Error %d: %s" % (e.args[0],e.args[1]) sys.exit(1)
>> >
>> > except: print 'msg handler exception' print 50*'-' print message
>> > print msg_lines print 50*'-'
>> >
>> > Except this function there is also constructor and additional
>> > function for setting the database up (it is called only in
>> > constructor). There is no work function as this block nly receives
>> > messages and writes to database. Is there any idea how can I catch
>> > this?
>> >
>> > Thanx
>> >
>> >
>> >
>> > On Thu, Mar 20, 2014 at 4:34 PM, Marcus Müller 
>> > wrote:
>> >
>> > Hi Nemanja,
>> >
>> > your except syntax is wrong, most probably you wanted to use
>> > "except ExceptionType as e" instead, refer to
>> > http://docs.python.org/2/tutorial/errors.html
>> >
>> > Anyway, have you tried surrounding all your handler code with a
>> > try and catch not only the database related errors?
>> >
>> > Greetings, Marcus
>> >
>> > On 20.03.2014 15:58, Nemanja Savic wrote:
>> >>>> Dear gnuradioers,
>> >>>>
>> >>>> I would like to ask againi if somebody can help me
>> >>>> understand this: thread[thread-per-block[0]: > >>>> db_logger2 (62)>]: caught unrecognized exception
>> >>>>
>> >>>> I have two blocks of db_logger type and it looks like only
>> >>>> one catch this unrecognized exception and another keeps
>> >>>> working fine.
>> >>>>
>> >>>> best and thank you
>> >>>>
>> >>>>
>> >>>> On Mon, Mar 3, 2014 at 12:55 PM, Nemanja Savic
>> >>>>  wrote:
>> >>>>
>> >>>>> Hi all guys,
>> >>>>>
>> >>>>> I have a block which is responsible to receive certain
>> >>>>> messages from other blocks and to write t

Re: [Discuss-gnuradio] catching unrecognized exception

[Nemanja Savic]

Hello again,

Marcus, you are right, my syntax is not any more correct but there is
backwards compatibility. I initiated error on my own and everything works
fine, so I would say there should be rather something more serious.


On Tue, Apr 15, 2014 at 4:31 PM, Marcus Müller  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Nemanja,
>
> Simple explanation:
> You haven't fixed your syntax for the first except clause.
> Going back to my other post, it should read
> "except mdb.Error as e:", not "except mdb.Error, e".
>
> Because you didn't do that, "e" is undefined in your except clause.
> This raises a NameError in your except clause, which doesn't get
> handled. Fix the except syntax.
>
> Also, don't do system.exit() in a multithreaded application, unless
> you really know what you're doing. You'll end up with unfinished data,
> broken database commits and so on.
>
> Greetings,
> Marcus
>
> On 15.04.2014 15:40, Nemanja Savic wrote:
> > Hi again,
> >
> > so, the exception appeared again. Just to remind:
> > thread[thread-per-block[0]: ]: caught
> > unrecognized exception
> >
> > I can't find what (65) means. This time complete block of code was
> > encapsulated by try and except but nothing was caught.
> >
> > Here is my code:
> >
> > def handle_msg(self, msg): try: message =
> > pmt.pmt_symbol_to_string(msg) msg_lines = message.split('\n')
> > sensor_id = msg_lines[0] vendor = msg_lines[2] sensor_type =
> > msg_lines[3] time = msg_lines[1] querry = "INSERT INTO `%s`.`%s`
> > (`id` ,`sens_id` ,`vendor`, `sensor_type`, `det_id`) VALUES (NULL ,
> > '%s', '%s', '%s','%s');" % (self._db_name, self._det_table,
> > sensor_id, vendor, sensor_type, self._id) cur = self._con.cursor()
> > cur.execute(querry) except mdb.Error, e: print "Unexpected error
> > while trying to insert into table" print 50*'-' print 50*'-' print
> > "Error %d: %s" % (e.args[0],e.args[1]) sys.exit(1)
> >
> > except: print 'msg handler exception' print 50*'-' print message
> > print msg_lines print 50*'-'
> >
> > Except this function there is also constructor and additional
> > function for setting the database up (it is called only in
> > constructor). There is no work function as this block nly receives
> > messages and writes to database. Is there any idea how can I catch
> > this?
> >
> > Thanx
> >
> >
> >
> > On Thu, Mar 20, 2014 at 4:34 PM, Marcus Müller 
> > wrote:
> >
> > Hi Nemanja,
> >
> > your except syntax is wrong, most probably you wanted to use
> > "except ExceptionType as e" instead, refer to
> > http://docs.python.org/2/tutorial/errors.html
> >
> > Anyway, have you tried surrounding all your handler code with a
> > try and catch not only the database related errors?
> >
> > Greetings, Marcus
> >
> > On 20.03.2014 15:58, Nemanja Savic wrote:
> >>>> Dear gnuradioers,
> >>>>
> >>>> I would like to ask againi if somebody can help me
> >>>> understand this: thread[thread-per-block[0]:  >>>> db_logger2 (62)>]: caught unrecognized exception
> >>>>
> >>>> I have two blocks of db_logger type and it looks like only
> >>>> one catch this unrecognized exception and another keeps
> >>>> working fine.
> >>>>
> >>>> best and thank you
> >>>>
> >>>>
> >>>> On Mon, Mar 3, 2014 at 12:55 PM, Nemanja Savic
> >>>>  wrote:
> >>>>
> >>>>> Hi all guys,
> >>>>>
> >>>>> I have a block which is responsible to receive certain
> >>>>> messages from other blocks and to write the data from the
> >>>>> message into database. Sometimes the following exception
> >>>>> occures and the block stops writing into database:
> >>>>>
> >>>>> thread[thread-per-block[0]: ]:
> >>>>> caught unrecognized exception
> >>>>>
> >>>>> The structure of the block is really simple:
> >>>>>
> >>>>> def handle_msg(self, msg): message =
> >>>>> pmt.pmt_symbol_to_string(msg) msg_lines =
> >>>>> message.split('\n') try: sensor_id = msg_lines[0] vendor =
> >>>>

Re: [Discuss-gnuradio] catching unrecognized exception

[Nemanja Savic]

It's commented line inside the function called only once inside
constructor, and never again :)


On Tue, Apr 15, 2014 at 4:21 PM, Mike Jameson  wrote:

> The '(65)' looks to be the line number where the error occured.  Notice
> that previously the line number was '(62)' which probably means that the
> error is coming from line 65 of one of the files you have been editing.
>
> Mike
>
> --
> Mike Jameson M0MIK BSc MIET
> Email: m...@scanoo.com
> Web: http://scanoo.com
>
>
> On Tue, Apr 15, 2014 at 2:40 PM, Nemanja Savic  wrote:
>
>> Hi again,
>>
>> so, the exception appeared again. Just to remind:
>> thread[thread-per-block[0]: ]: caught
>> unrecognized exception
>>
>> I can't find what (65) means.
>> This time complete block of code was encapsulated by try and except but
>> nothing was caught.
>>
>> Here is my code:
>>
>> def handle_msg(self, msg):
>> try:
>>
>> message = pmt.pmt_symbol_to_string(msg)
>> msg_lines = message.split('\n')
>> sensor_id = msg_lines[0]
>> vendor = msg_lines[2]
>> sensor_type = msg_lines[3]
>> time = msg_lines[1]
>> querry = "INSERT INTO `%s`.`%s` (`id` ,`sens_id` ,`vendor`,
>> `sensor_type`, `det_id`) VALUES (NULL , '%s', '%s', '%s','%s');" %
>> (self._db_name, self._det_table, sensor_id, vendor, sensor_type, self._id)
>>  cur = self._con.cursor()
>> cur.execute(querry)
>> except mdb.Error, e:
>> print "Unexpected error while trying to insert into table"
>> print 50*'-'
>>
>> print 50*'-'
>> print "Error %d: %s" % (e.args[0],e.args[1])
>> sys.exit(1)
>>
>> except:
>> print 'msg handler exception'
>> print 50*'-'
>> print message
>>
>> print msg_lines
>> print 50*'-'
>>
>>
>> Except this function there is also constructor and additional function
>> for setting the database up (it is called only in constructor). There is no
>> work function as this block nly receives messages and writes to database.
>> Is there any idea how can I catch this?
>>
>> Thanx
>>
>>
>>
>> On Thu, Mar 20, 2014 at 4:34 PM, Marcus Müller wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Hi Nemanja,
>>>
>>> your except syntax is wrong, most probably you wanted to use "except
>>> ExceptionType as e" instead, refer to
>>> http://docs.python.org/2/tutorial/errors.html
>>>
>>> Anyway, have you tried surrounding all your handler code with a try
>>> and catch not only the database related errors?
>>>
>>> Greetings,
>>> Marcus
>>>
>>> On 20.03.2014 15:58, Nemanja Savic wrote:
>>> > Dear gnuradioers,
>>> >
>>> > I would like to ask againi if somebody can help me understand
>>> > this: thread[thread-per-block[0]: ]:
>>> > caught unrecognized exception
>>> >
>>> > I have two blocks of db_logger type and it looks like only one
>>> > catch this unrecognized exception and another keeps working fine.
>>> >
>>> > best and thank you
>>> >
>>> >
>>> > On Mon, Mar 3, 2014 at 12:55 PM, Nemanja Savic 
>>> > wrote:
>>> >
>>> >> Hi all guys,
>>> >>
>>> >> I have a block which is responsible to receive certain messages
>>> >> from other blocks and to write the data from the message into
>>> >> database. Sometimes the following exception occures and the block
>>> >> stops writing into database:
>>> >>
>>> >> thread[thread-per-block[0]: ]: caught
>>> >> unrecognized exception
>>> >>
>>> >> The structure of the block is really simple:
>>> >>
>>> >> def handle_msg(self, msg): message =
>>> >> pmt.pmt_symbol_to_string(msg) msg_lines = message.split('\n')
>>> >> try: sensor_id = msg_lines[0] vendor = msg_lines[2] sensor_type =
>>> >> msg_lines[3] time = msg_lines[1] #try: querry = "INSERT INTO
>>> >> `%s`.`%s` (`id` ,`sens_id` ,`vendor`, `sensor_typ

Re: [Discuss-gnuradio] catching unrecognized exception

[Nemanja Savic]

Hi again,

so, the exception appeared again. Just to remind:
thread[thread-per-block[0]: ]: caught
unrecognized exception

I can't find what (65) means.
This time complete block of code was encapsulated by try and except but
nothing was caught.

Here is my code:

def handle_msg(self, msg):
try:
message = pmt.pmt_symbol_to_string(msg)
msg_lines = message.split('\n')
sensor_id = msg_lines[0]
vendor = msg_lines[2]
sensor_type = msg_lines[3]
time = msg_lines[1]
querry = "INSERT INTO `%s`.`%s` (`id` ,`sens_id` ,`vendor`,
`sensor_type`, `det_id`) VALUES (NULL , '%s', '%s', '%s','%s');" %
(self._db_name, self._det_table, sensor_id, vendor, sensor_type, self._id)
cur = self._con.cursor()
cur.execute(querry)
except mdb.Error, e:
print "Unexpected error while trying to insert into table"
print 50*'-'
print 50*'-'
print "Error %d: %s" % (e.args[0],e.args[1])
sys.exit(1)

except:
print 'msg handler exception'
print 50*'-'
print message
print msg_lines
print 50*'-'

Except this function there is also constructor and additional function for
setting the database up (it is called only in constructor). There is no
work function as this block nly receives messages and writes to database.
Is there any idea how can I catch this?

Thanx



On Thu, Mar 20, 2014 at 4:34 PM, Marcus Müller  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Nemanja,
>
> your except syntax is wrong, most probably you wanted to use "except
> ExceptionType as e" instead, refer to
> http://docs.python.org/2/tutorial/errors.html
>
> Anyway, have you tried surrounding all your handler code with a try
> and catch not only the database related errors?
>
> Greetings,
> Marcus
>
> On 20.03.2014 15:58, Nemanja Savic wrote:
> > Dear gnuradioers,
> >
> > I would like to ask againi if somebody can help me understand
> > this: thread[thread-per-block[0]: ]:
> > caught unrecognized exception
> >
> > I have two blocks of db_logger type and it looks like only one
> > catch this unrecognized exception and another keeps working fine.
> >
> > best and thank you
> >
> >
> > On Mon, Mar 3, 2014 at 12:55 PM, Nemanja Savic 
> > wrote:
> >
> >> Hi all guys,
> >>
> >> I have a block which is responsible to receive certain messages
> >> from other blocks and to write the data from the message into
> >> database. Sometimes the following exception occures and the block
> >> stops writing into database:
> >>
> >> thread[thread-per-block[0]: ]: caught
> >> unrecognized exception
> >>
> >> The structure of the block is really simple:
> >>
> >> def handle_msg(self, msg): message =
> >> pmt.pmt_symbol_to_string(msg) msg_lines = message.split('\n')
> >> try: sensor_id = msg_lines[0] vendor = msg_lines[2] sensor_type =
> >> msg_lines[3] time = msg_lines[1] #try: querry = "INSERT INTO
> >> `%s`.`%s` (`id` ,`sens_id` ,`vendor`, `sensor_type`, `det_id`)
> >> VALUES (NULL , '%s', '%s', '%s','%s');" % (self._db_name,
> >> self._det_table, sensor_id, vendor, sensor_type, self._id) #
> >> print querry cur = self._con.cursor() cur.execute(querry) except
> >> mdb.Error, e: print "Unexpected error while trying to insert into
> >> table" print msg_lines print 50*'-' print "Error %d: %s" %
> >> (e.args[0],e.args[1]) sys.exit(1)
> >>
> >> Is there any way to track this problem and find the cause?
> >>
> >> Best regards,
> >>
> >> -- Nemanja Savić
> >>
> >
> >
> >
> >
> >
> > ___ Discuss-gnuradio
> > mailing list Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTKwqdAAoJEBQ6EdjyzlHtxrcIALIUmmcUY3OJ8Bnr2g9tYhB1
> rQkOyCaES+4b8bocZIyoUTF7M/N5FA9TmITxvnhZgqcvl0Kb1BaFc9F0H9Tbb4w4
> EJtIV6HVLu1jSQAqwMT1jLT3ATbWzH108om/jDx7Wai3Jb64WrVaMxlDuJPJFlK/
> fjVSrGXwcEZRt/8SVbeRmItipo9Y551rNerULo8/4VSiFz30QVyh/zFwNWAGwavA
> xNQPA7OAq4SImyofUGU0E8IsyY9YMcgSlATZYSoKJDbcrFWtrfGJdnuOOV55bgKJ
> l/SouuiObel3WLdzk6861vITRbxyVrPOdsts9ins/G9+Z1wZMKKRz/dh6POevmA=
> =yTTM
> -END PGP SIGNATURE-
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



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

Re: [Discuss-gnuradio] catching unrecognized exception

[Nemanja Savic]

Dear gnuradioers,

I would like to ask againi if somebody can help me understand this:
thread[thread-per-block[0]: ]: caught
unrecognized exception

I have two blocks of db_logger type and it looks like only one catch this
unrecognized exception and another keeps working fine.

best and thank you


On Mon, Mar 3, 2014 at 12:55 PM, Nemanja Savic  wrote:

> Hi all guys,
>
> I have a block which is responsible to receive certain messages from other
> blocks and to write the data from the message into database. Sometimes the
> following exception occures and the block stops writing into database:
>
> thread[thread-per-block[0]: ]: caught
> unrecognized exception
>
> The structure of the block is really simple:
>
> def handle_msg(self, msg):
> message = pmt.pmt_symbol_to_string(msg)
> msg_lines = message.split('\n')
> try:
> sensor_id = msg_lines[0]
> vendor = msg_lines[2]
> sensor_type = msg_lines[3]
> time = msg_lines[1]
> #try:
> querry = "INSERT INTO `%s`.`%s` (`id` ,`sens_id` ,`vendor`,
> `sensor_type`, `det_id`) VALUES (NULL , '%s', '%s', '%s','%s');" %
> (self._db_name, self._det_table, sensor_id, vendor, sensor_type, self._id)
> #print querry
> cur = self._con.cursor()
> cur.execute(querry)
> except mdb.Error, e:
> print "Unexpected error while trying to insert into table"
> print msg_lines
> print 50*'-'
> print "Error %d: %s" % (e.args[0],e.args[1])
> sys.exit(1)
>
> Is there any way to track this problem and find the cause?
>
> Best regards,
>
> --
> Nemanja Savić
>



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

[Discuss-gnuradio] catching unrecognized exception

[Nemanja Savic]

Hi all guys,

I have a block which is responsible to receive certain messages from other
blocks and to write the data from the message into database. Sometimes the
following exception occures and the block stops writing into database:

thread[thread-per-block[0]: ]: caught
unrecognized exception

The structure of the block is really simple:

def handle_msg(self, msg):
message = pmt.pmt_symbol_to_string(msg)
msg_lines = message.split('\n')
try:
sensor_id = msg_lines[0]
vendor = msg_lines[2]
sensor_type = msg_lines[3]
time = msg_lines[1]
#try:
querry = "INSERT INTO `%s`.`%s` (`id` ,`sens_id` ,`vendor`,
`sensor_type`, `det_id`) VALUES (NULL , '%s', '%s', '%s','%s');" %
(self._db_name, self._det_table, sensor_id, vendor, sensor_type, self._id)
#print querry
cur = self._con.cursor()
cur.execute(querry)
except mdb.Error, e:
print "Unexpected error while trying to insert into table"
print msg_lines
print 50*'-'
print "Error %d: %s" % (e.args[0],e.args[1])
sys.exit(1)

Is there any way to track this problem and find the cause?

Best regards,

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

Re: [Discuss-gnuradio] broken gnuplot

[Nemanja Savic]

When I use nongl option, then the gui looks like on the figure I posted,
and when I use gl option, the follosing error occures:
Traceback (most recent call last):
  File "/home/savi_ne/work/gnuradio/GRC/top_block.py", line 14, in 
from gnuradio.wxgui import fftsink2
  File
"/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/fftsink2.py", line
34, in 
raise RuntimeError("Unable to import OpenGL.  Are Python wrappers for
OpenGL installed?")
RuntimeError: Unable to import OpenGL.  Are Python wrappers for OpenGL
installed?



On Tue, Feb 25, 2014 at 11:45 PM, Nemanja Savic  wrote:

> Thank you Tom. I try tomorrow.
>
>
> On Tue, Feb 25, 2014 at 4:20 PM, Tom Rondeau  wrote:
>
>> On Tue, Feb 25, 2014 at 9:35 AM, Nemanja Savic 
>> wrote:
>> > Is there any way to repair this, because one or two months ago,
>> everything
>> > was ok? Or, is there any log where I can figure what is the exact
>> problem?
>>
>> Well, since we don't know what you changed on your side, it's hard to
>> help you fix it. Again, numpy, matplotlib, and gnuplot have nothing to
>> do with this.
>>
>> Have you tried my suggestion of turning opengl off? That tends to be
>> the main problem people have with using wxgui.
>>
>> Tom
>>
>>
>>
>> > On Tue, Feb 25, 2014 at 3:02 PM, Tom Rondeau  wrote:
>> >>
>> >> On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic 
>> wrote:
>> >>>
>> >>> So, it is default installation. I use RHEL6. Some time ago I
>> uninstalled
>> >>> numpy due to installation of new version of matplotlib (I don't know
>> if this
>> >>> is important).
>> >>> Now my gui looks like this
>> >>
>> >>
>> >> That's using wxPython, not gnuplot. It doesn't use matplotlib, either
>> >> (which depends on numpy, so if you installed matplotlib, you also
>> still have
>> >> numpy). That will have no effect on the wxgui plots.
>> >>
>> >> This is possibly related to opengl, though. You can turn that off by
>> >> editing $prefix/etc/gnuradio/conf.d/gr-wxgui.conf.
>> >>
>> >> Tom
>> >>
>> >>
>> >>
>> >>>
>> >>> On Tue, Feb 25, 2014 at 1:13 PM, Martin Braun > >
>> >>> wrote:
>> >>>>
>> >>>> On 02/25/2014 12:49 PM, Nemanja Savic wrote:
>> >>>> > Hi all guys,
>> >>>> >
>> >>>> > lately I have experienced some problems with showing scope and fft
>> >>>> > plot.
>> >>>> > Namely, the plots looks raw and ugly. Once there was an report that
>> >>>> > gnuplot was killed.
>> >>>> >
>> >>>> > Any idea how to check and repair this?
>> >>>>
>> >>>> Are you using gnuplot?
>> >>>>
>> >>>> What exactly are doing and which tools are you using?
>> >>>>
>> >>>> M
>> >>>>
>> >>>> ___
>> >>>> Discuss-gnuradio mailing list
>> >>>> Discuss-gnuradio@gnu.org
>> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Nemanja Savić
>> >>>
>> >>> ___
>> >>> Discuss-gnuradio mailing list
>> >>> Discuss-gnuradio@gnu.org
>> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Nemanja Savić
>>
>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] broken gnuplot

[Nemanja Savic]

Thank you Tom. I try tomorrow.


On Tue, Feb 25, 2014 at 4:20 PM, Tom Rondeau  wrote:

> On Tue, Feb 25, 2014 at 9:35 AM, Nemanja Savic  wrote:
> > Is there any way to repair this, because one or two months ago,
> everything
> > was ok? Or, is there any log where I can figure what is the exact
> problem?
>
> Well, since we don't know what you changed on your side, it's hard to
> help you fix it. Again, numpy, matplotlib, and gnuplot have nothing to
> do with this.
>
> Have you tried my suggestion of turning opengl off? That tends to be
> the main problem people have with using wxgui.
>
> Tom
>
>
>
> > On Tue, Feb 25, 2014 at 3:02 PM, Tom Rondeau  wrote:
> >>
> >> On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic 
> wrote:
> >>>
> >>> So, it is default installation. I use RHEL6. Some time ago I
> uninstalled
> >>> numpy due to installation of new version of matplotlib (I don't know
> if this
> >>> is important).
> >>> Now my gui looks like this
> >>
> >>
> >> That's using wxPython, not gnuplot. It doesn't use matplotlib, either
> >> (which depends on numpy, so if you installed matplotlib, you also still
> have
> >> numpy). That will have no effect on the wxgui plots.
> >>
> >> This is possibly related to opengl, though. You can turn that off by
> >> editing $prefix/etc/gnuradio/conf.d/gr-wxgui.conf.
> >>
> >> Tom
> >>
> >>
> >>
> >>>
> >>> On Tue, Feb 25, 2014 at 1:13 PM, Martin Braun 
> >>> wrote:
> >>>>
> >>>> On 02/25/2014 12:49 PM, Nemanja Savic wrote:
> >>>> > Hi all guys,
> >>>> >
> >>>> > lately I have experienced some problems with showing scope and fft
> >>>> > plot.
> >>>> > Namely, the plots looks raw and ugly. Once there was an report that
> >>>> > gnuplot was killed.
> >>>> >
> >>>> > Any idea how to check and repair this?
> >>>>
> >>>> Are you using gnuplot?
> >>>>
> >>>> What exactly are doing and which tools are you using?
> >>>>
> >>>> M
> >>>>
> >>>> ___
> >>>> Discuss-gnuradio mailing list
> >>>> Discuss-gnuradio@gnu.org
> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Nemanja Savić
> >>>
> >>> ___
> >>> Discuss-gnuradio mailing list
> >>> Discuss-gnuradio@gnu.org
> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>
> >>
> >
> >
> >
> > --
> > Nemanja Savić
>



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

Re: [Discuss-gnuradio] broken gnuplot

[Nemanja Savic]

Is there any way to repair this, because one or two months ago, everything
was ok? Or, is there any log where I can figure what is the exact problem?


On Tue, Feb 25, 2014 at 3:02 PM, Tom Rondeau  wrote:

> On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic  wrote:
>
>> So, it is default installation. I use RHEL6. Some time ago I uninstalled
>> numpy due to installation of new version of matplotlib (I don't know if
>> this is important).
>> Now my gui looks like this
>>
>
> That's using wxPython, not gnuplot. It doesn't use matplotlib, either
> (which depends on numpy, so if you installed matplotlib, you also still
> have numpy). That will have no effect on the wxgui plots.
>
> This is possibly related to opengl, though. You can turn that off by
> editing $prefix/etc/gnuradio/conf.d/gr-wxgui.conf.
>
> Tom
>
>
>
>
>> On Tue, Feb 25, 2014 at 1:13 PM, Martin Braun wrote:
>>
>>> On 02/25/2014 12:49 PM, Nemanja Savic wrote:
>>> > Hi all guys,
>>> >
>>> > lately I have experienced some problems with showing scope and fft
>>> plot.
>>> > Namely, the plots looks raw and ugly. Once there was an report that
>>> > gnuplot was killed.
>>> >
>>> > Any idea how to check and repair this?
>>>
>>> Are you using gnuplot?
>>>
>>> What exactly are doing and which tools are you using?
>>>
>>> M
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> --
>> Nemanja Savić
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


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

[Discuss-gnuradio] broken gnuplot

[Nemanja Savic]

Hi all guys,

lately I have experienced some problems with showing scope and fft plot.
Namely, the plots looks raw and ugly. Once there was an report that gnuplot
was killed.

Any idea how to check and repair this?

Best,

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

Re: [Discuss-gnuradio] 回复： import error: no

[Nemanja Savic]

You are right.
Thank you


On Tue, Feb 18, 2014 at 4:18 PM, Tiankun Hu  wrote:

> seems need do ldconfig
> -- 原始邮件 --
> *发件人:* "Nemanja Savic"
> *发送时间:* 2014年2月18日(星期二) 晚上10:02
> *收件人:* "GNURadio Discussion List";
> *主题:* [Discuss-gnuradio] import error: no
> Hi all guys,
>
> I am facin a problem when trying to import out of tree module. Namely, I
> developed the module one one machine, and copied source files to another
> machind and it doesn't work. I have done this several times and every time
> it worked without problems. Here is the error message:
>
> Traceback (most recent call last):
> ? File "/home/tpms_east/work/gnuradio/GRC/top_block.py", line 15, in
> 
> ??? import NMS
> ? File "/usr/local/lib/python2.7/dist-packages/NMS/__init__.py", line 45,
> in 
> ??? from NMS_swig import *
> ? File "/usr/local/lib/python2.7/dist-packages/NMS/NMS_swig.py", line 26,
> in 
> ??? _NMS_swig = swig_import_helper()
> ? File "/usr/local/lib/python2.7/dist-packages/NMS/NMS_swig.py", line 22,
> in swig_import_helper
> ??? _mod = imp.load_module('_NMS_swig', fp, pathname, description)
>
> ImportError: libgnuradio-NMS.so: cannot open shared object file: No such
> file or directory
>
> I am really surprised that it wn't work. Hope that somebody could suggest
> some solution.
>
> best,
>
> --
> Nemanja Savi?
>



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

[Discuss-gnuradio] import error: no

[Nemanja Savic]

Hi all guys,

I am facin a problem when trying to import out of tree module. Namely, I
developed the module one one machine, and copied source files to another
machind and it doesn't work. I have done this several times and every time
it worked without problems. Here is the error message:

Traceback (most recent call last):
  File "/home/tpms_east/work/gnuradio/GRC/top_block.py", line 15, in

import NMS
  File "/usr/local/lib/python2.7/dist-packages/NMS/__init__.py", line 45,
in 
from NMS_swig import *
  File "/usr/local/lib/python2.7/dist-packages/NMS/NMS_swig.py", line 26,
in 
_NMS_swig = swig_import_helper()
  File "/usr/local/lib/python2.7/dist-packages/NMS/NMS_swig.py", line 22,
in swig_import_helper
_mod = imp.load_module('_NMS_swig', fp, pathname, description)
ImportError: libgnuradio-NMS.so: cannot open shared object file: No such
file or directory

I am really surprised that it wn't work. Hope that somebody could suggest
some solution.

best,

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

Re: [Discuss-gnuradio] funcube pro +

[Nemanja Savic]

I have intel 6 series / c200.
could rhel 6 be the prolem here as usually?


On Wed, Feb 12, 2014 at 4:13 PM, Volker Schroer  wrote:

> If you run linux on your laptop try
>
> lspci -k
>
> and look for USB. Then you can find the controller type.
>
> USB 3 supports higher speed than USB 2 and should offer more bandwidth.
> But on my desktop system the dongle only runs on the USB 2 port not on the
> USB 3 port. The same happens with the funcube pro that requires lower
> bandwidth than the pro +. On my notebook there exists only an USB3
> controller Intel 8 Series/C2200 and it works flawless.
>
> --Volker
>
>
> Am 12.02.2014 14:22, schrieb Nemanja Savic:
>
>> Well, I have dell laptop but have no clue which usb controller it has.
>> Now I am not sure whether I should by one or not. Anyway, should newer
>> versions of usb have higher speed and thus bandwidth.
>>
>>
>> On Wed, Feb 12, 2014 at 1:49 PM, Volker Schroer > <mailto:dl1...@gmx.de>> wrote:
>>
>> The funcube pro+ works flawless on my usb 2.0 port. It seems that
>> the bandwidth problem arises from the usb controller hardware.
>>
>> I use an ASROCK motherboard with SB7x0/SB8x0/SB9x0 controller in use
>> with the ohci /ehci kernel drivers. This controller works very well
>> for me.
>>
>> The Inc. EJ168 USB 3.0 Host Controller instead does not work. It
>> claims to have not enough bandwith but for both Funcube devices the
>> ( pro and the pro+).
>>
>> -- Volker
>>
>>
>>
>> Am 12.02.2014 11:09, schrieb Alexandru Csete:
>>
>> On Wed, Feb 12, 2014 at 10:51 AM, Nemanja Savic
>> mailto:vlasi...@gmail.com>> wrote:
>>
>> Hi all guys,
>>
>> I am about to buy funcube dongle pro +, and wanted to ask if
>> somebody of u
>> use it without any problems?
>>
>>
>> Very few people use it on linux without problems. If you have a
>> USB 1
>> port it will probably work, otherwise you will likely get the
>> "insufficient bandwidth" bug.
>>
>> https://github.com/csete/gqrx/__issues/91
>>
>> <https://github.com/csete/gqrx/issues/91>
>>
>> There are however no problems with the original Funcube Dongle Pro
>> (the one without shortwaves and only 96 kHz bandwidth).
>>
>> Alex
>>
>> _
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>> https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>
>>
>>
>> _
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>> https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
>>
>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>
>>
>>
>>
>> --
>> Nemanja Savić
>>
>
>


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

Re: [Discuss-gnuradio] funcube pro +

[Nemanja Savic]

Well, I have dell laptop but have no clue which usb controller it has. Now
I am not sure whether I should by one or not. Anyway, should newer versions
of usb have higher speed and thus bandwidth.


On Wed, Feb 12, 2014 at 1:49 PM, Volker Schroer  wrote:

> The funcube pro+ works flawless on my usb 2.0 port. It seems that the
> bandwidth problem arises from the usb controller hardware.
>
> I use an ASROCK motherboard with SB7x0/SB8x0/SB9x0 controller in use with
> the ohci /ehci kernel drivers. This controller works very well for me.
>
> The Inc. EJ168 USB 3.0 Host Controller instead does not work. It claims to
> have not enough bandwith but for both Funcube devices the ( pro and the
> pro+).
>
> -- Volker
>
>
>
> Am 12.02.2014 11:09, schrieb Alexandru Csete:
>
>> On Wed, Feb 12, 2014 at 10:51 AM, Nemanja Savic 
>> wrote:
>>
>>> Hi all guys,
>>>
>>> I am about to buy funcube dongle pro +, and wanted to ask if somebody of
>>> u
>>> use it without any problems?
>>>
>>
>> Very few people use it on linux without problems. If you have a USB 1
>> port it will probably work, otherwise you will likely get the
>> "insufficient bandwidth" bug.
>>
>> https://github.com/csete/gqrx/issues/91
>>
>> There are however no problems with the original Funcube Dongle Pro
>> (the one without shortwaves and only 96 kHz bandwidth).
>>
>> Alex
>>
>> ___
>> 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
>



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

Re: [Discuss-gnuradio] funcube pro +

[Nemanja Savic]

I have only usb 2.0 ports on my computer. How likely is that this bug will
be fixed in the near future?


On Wed, Feb 12, 2014 at 11:09 AM, Alexandru Csete  wrote:

> On Wed, Feb 12, 2014 at 10:51 AM, Nemanja Savic 
> wrote:
> > Hi all guys,
> >
> > I am about to buy funcube dongle pro +, and wanted to ask if somebody of
> u
> > use it without any problems?
>
> Very few people use it on linux without problems. If you have a USB 1
> port it will probably work, otherwise you will likely get the
> "insufficient bandwidth" bug.
>
> https://github.com/csete/gqrx/issues/91
>
> There are however no problems with the original Funcube Dongle Pro
> (the one without shortwaves and only 96 kHz bandwidth).
>
> Alex
>



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

[Discuss-gnuradio] funcube pro +

[Nemanja Savic]

Hi all guys,

I am about to buy funcube dongle pro +, and wanted to ask if somebody of u
use it without any problems?

Best,

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

[Discuss-gnuradio] Fwd: synchronization between blocks

[Nemanja Savic]

Hi all,

Thank you Michael for you generous answer.
The point is that my clk sync block is probably the source of troubles, but
don't know yet why.
Namely it starts ok, the rssi is correct, but then it stops working
correctly, and I can see in some log file that correct rssi value was
sampled earlier. However, I am continuing with the hunt.

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

Re: [Discuss-gnuradio] Documentation for out-of-tree module

[Nemanja Savic]

Hell yeah, my first corect answer!

Cheers


On Tue, Feb 4, 2014 at 9:16 PM, Zhe Feng  wrote:

> Hi Tom,
>
> I found my mistake.
> OK, maybe I don't have to worry about the public header file now.
>
> Thanks!
> Best,
> Zhe
>
>
>
> On Tue, Feb 4, 2014 at 2:06 PM, Tom Rondeau  wrote:
>
>> On Tue, Feb 4, 2014 at 6:26 PM, Zhe Feng  wrote:
>> > Hi Nemanja,
>> >
>> > Yes, that's what I want to do.
>> >
>> > I'm using the latest version 3.7.2. When I add the  tag in the xml
>> of a
>> > block, I found the block disappeared after reinstallation.  Is it
>> because of
>> > different version?
>> >
>> > Thanks!
>> > Zhe
>>
>> If the block disappears, it's usually due to a malformed line of XML.
>> Make sure you have closed all tags properly ().
>>
>> We have to work on the scrapping of doc information from the public
>> header file for out-of-tree projects. In the meantime, the  tag
>> should work for you.
>>
>> Tom
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Zhe Feng
>
> Electrical Engineering: System
>
> University of Michigan Ann Arbor
>
> Tel: 734-834-3188
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] Fwd: Documentation for out-of-tree module

[Nemanja Savic]

Under tag .


On Tue, Feb 4, 2014 at 5:15 PM, Zhe Feng  wrote:

>
> Hi all,
>
> I'm working on an out-of-tree module and I want to make the documentations
> which can be shown in the windows when people double click the blocks.
>
> I guess the documentations are written in the header file in
> /gr-xx/include/xx. So I tried to modify the header files of blocks which
> already exist in gnuradio, for example, the channel_model block in
> gr-channel. The documentation was updated after reinstallation. It confirms
> my guess. But when I modify the header file of my own block
> in /gr-xx/include/xx, the documentation wasn't updated after
> reinstallation. The documentations are still something like:
>
> make(xx, xx) -> sptr
> Return a shared_ptr to a new instance of xx::xx.
> To avoid accidental use of raw pointers, xx::xx constructor is in a
> private implementation class. xx::xx::make is the public interface for
> creating new instances.
> Params: (xx, xx)
>
>
> I searched some previous questions related to documentation on
> discussion-gnuradio, someone said documentations should be done by doxygen
> for C++ blocks and by sphinx for python blocks. But I found these are more
> related to these html documentations(maybe I'm wrong).
>
> Did I miss something or do something wrong? Could anyone give me any
> suggestions to resolve problem?
>
> Thanks a lot!
> Best,
> Zhe
> --
> Zhe Feng
> University of Michigan Ann Arbor
> Tel: 734-834-3188
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] Documentation for out-of-tree module

[Nemanja Savic]

well, maybe, i don't know. Still haven't used 3.7.
But I remember when I wanted to do the same I looked for the documentation
of standard gnuradio blocks and just copied that.

Best,
Nemanja


On Tue, Feb 4, 2014 at 7:26 PM, Zhe Feng  wrote:

> Hi Nemanja,
>
> Yes, that's what I want to do.
>
> I'm using the latest version 3.7.2. When I add the  tag in the xml of
> a
> block, I found the block disappeared after reinstallation.  Is it because
> of
> different version?
>
> Thanks!
> Zhe
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Documentation-for-out-of-tree-module-tp46127p46132.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
>



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

Re: [Discuss-gnuradio] Documentation for out-of-tree module

[Nemanja Savic]

If i understood you well, you wanna see the description of ur block in GRC.
In version 3.6.5.1 and previous ones I did that by writting block
description under tag  in xml GRC file of ur block. For example:

  
Doceder consists of two sub blocks:
blah blah
  

as for the missing tag , just add it.

best,
Nemanja


On Tue, Feb 4, 2014 at 7:07 PM, Zhe Feng  wrote:

> Hi Nemanja,
>
> I checked the xml files and I didn't find the "documentations". By the way,
> I don't see a  tag in xml file.
>
> Did I miss anything?
>
> Thanks!
> Zhe
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Documentation-for-out-of-tree-module-tp46127p46130.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
>



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

Re: [Discuss-gnuradio] Documentation for out-of-tree module

[Nemanja Savic]

I think "that" documentation is written in your xml file from grc folder.


On Tue, Feb 4, 2014 at 6:37 PM, Zhe Feng  wrote:

> Hi all,
>
> I'm working on an out-of-tree module and I want to make the documentations
> which can be shown in the windows when people double click the blocks.
>
> I guess the documentations are written in the header files in
> /gr-xx/include/xx. So I tried to modify the header files of blocks which
> already exist in gnuradio, for example, the channel_model block in
> gr-channel. The documentation was updated after reinstallation. It confirms
> my guess. But when I modify the header file of my own block in
> /gr-xx/include/xx, the documentation wasn't updated after reinstallation.
> The documentations are still something like:
>
> make(xx, xx) -> sptr
> Return a shared_ptr to a new instance of xx::xx.
> To avoid accidental use of raw pointers, xx::xx constructor is in a private
> implementation class. xx::xx::make is the public interface for creating new
> instances.
> Params: (xx, xx)
>
>
> I searched some previous questions related to documentation on
> discussion-gnuradio, someone said documentations should be done by doxygen
> for C++ blocks and by sphinx for python blocks. But I found these are more
> related to these html documentations(maybe I'm wrong).
>
> Did I miss something or do something wrong? Could anyone give me any
> suggestions to solve this problem?
>
> Thanks a lot!
> Best,
> Zhe
>
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Documentation-for-out-of-tree-module-tp46127.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
>



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

Re: [Discuss-gnuradio] synchronization between blocks

[Nemanja Savic]

Thank you Michael.
Well, I think the problem comes from the block which is not of sync type.
INputs to this block are demodulated signal and the very input signal, and
the output are sybol values and signal value at the point of sampling.
However I will try with logging and see what can I find. But just for
clarification, can the problem come from forecast function where I ask for
the same amount of input samples as the number of output samples (which is
like with sync block), but I produce like 20 times less?

Best regards


On Mon, Feb 3, 2014 at 8:30 PM, Michael Dickens  wrote:

> On Feb 3, 2014, at 10:14 AM, Nemanja Savic  wrote:
> > at the moment I thought that the problem was solved, but actually
> something strange is going on. I would only like to ask whether delay
> between two paths can roll out somehow (i don't know if this verb exists).
> The point is that at the beginig of the execution, it looks like the script
> is doing fine, but then I realize signs of unalligned signals which I can't
> in some other way.
>
>
> IIRC: Because of the way GNU Radio internally handles data processing (it
> waits for data upstream to become available before -starting- processing
> for a given block), and since -your specific graph- contains only sync
> blocks (yes?), then the sample delay difference between the 2 branches of
> -your specific graph- should be constant.  Further, it should be the same
> constant for every graph execution.
>
> If any blocks within a specific path are not sync blocks, e.g., a packet
> decoder, then the sample delay difference is not guaranteed (constant or
> otherwise).
>
> The wall-clock delay difference will not be constant; it can be any
> non-negative (and, generally > 0) time.
>
> All of the above said: If you're into compiling GNU Radio, you can go into
> gnuradio-runtime/lib/block_executor.cc and set "ENABLE_LOGGING" to 1.
>  Recompile/reinstall GNU Radio, then when you execute your graph you'll get
> a printout dump of what each block is doing.  That printout might help you
> debug this issue; or, not.  You might also add LOG messages in that file
> which could help ... maybe; or, not.
>
> Hope this helps! - MLD
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



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

Re: [Discuss-gnuradio] synchronization between blocks

[Nemanja Savic]

Hi all again,

at the moment I thought that the problem was solved, but actually something
strange is going on. I would only like to ask whether delay between two
paths can roll out somehow (i don't know if this verb exists). The point is
that at the beginig of the execution, it looks like the script is doing
fine, but then I realize signs of unalligned signals which I can't in some
other way.

Best
Nemanja


On Wed, Jan 29, 2014 at 6:52 PM, Nemanja Savic  wrote:

> Thank you Tom. The problem is that in the configuration that is attached
> delay must be arround 600 in order to allign two paths. Next I put a
> complex delay block in the second path just after the theottle (and removed
> the existing one) and it works fine with 330 (not perfectly alligned but
> ok). Is there any other sources of delay that should be accounted.
>
>
> On Wed, Jan 29, 2014 at 4:02 PM, Tom Rondeau  wrote:
>
>> On Wed, Jan 29, 2014 at 4:04 AM, Nemanja Savic wrote:
>>
>>> Hi all gnuradioers,
>>>
>>> I have a problem to adjust delay between two paths in my flowgraph, and
>>> thus I have a question. The flowgraph is attached. As can be seen, there
>>> are two paths from the input. I would call one signal path and the other
>>> would be RSSI path. In signal path, signal is first filtered, demodulated
>>> and finally in clk_sync_... block the symbols are sliced. The second path
>>> is used only for rssi value. At the moment I have problem to adjust delay
>>> in rssi path so that correct rssi value is sampled at the moment of
>>> sampling symbol values. The only block that introduces delay is filter and
>>> it has 331 taps. So when I set delay to 331, the signal are not aligned. Is
>>> delay between this two paths constant during execution or not?
>>>
>>> Best,
>>>
>>>
>>> --
>>> Nemanja Savić
>>>
>>
>> Yes, the delay is constant. But you've set the wrong value. For a
>> symmetric FIR filter like you are using, the delay is (N-1)/2.
>>
>> Tom
>>
>>
>>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] can't read fir taps

[Nemanja Savic]

Thank you Tom. It works when using fir from filter module.


On Thu, Jan 30, 2014 at 2:10 PM, Tom Rondeau  wrote:

> On Thu, Jan 30, 2014 at 4:47 AM, Nemanja Savic  wrote:
> > After a few more tries to figure out how this works I realized that
> method
> > taps() can return list of coefficients only if set_taps was called before
> > for setting taps. In the constructor of filter set_taps is not called,
> so my
> > question is which taps does filter use?
>
> It uses those taps, but it looks like it doesn't set a variable inside
> to hold them until you call set_taps on it. The fir filter blocks
> encapsulate another fir kernel, which is where the real taps are
> actually stored. When you create your FIR filter, the taps are being
> set correctly.
>
> You should switch to using filter.fir_filter, which exists in 3.6.5.1.
> It will help future-proof you when moving up GNU Radio versions.
> Getting the taps here right after creating the filter will work fine
> in this implementation.
>
> Tom
>
>
> > On Wed, Jan 29, 2014 at 6:54 PM, Nemanja Savic 
> wrote:
> >>
> >> Hi all guys,
> >>
> >> this two lines of code sort of doesn't work as I expect.
> >>
> >> self.channel_filter = gr.fir_filter_ccf(1, firdes.low_pass(10,
> samp_rate,
> >> 8, 5000, firdes.WIN_HAMMING, 6.76))
> >>
> >> print self.channel_filter.taps(), self.channel_filter
> >>
> >> I use 3.6.5.1 version and the only thing I get is empty tuple.
> >>
> >> What might be the problem?
> >>
> >> Best and thank you,
> >>
> >> --
> >> Nemanja Savić
> >
> >
> >
> >
> > --
> > Nemanja Savić
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>



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

Re: [Discuss-gnuradio] can't read fir taps

[Nemanja Savic]

After a few more tries to figure out how this works I realized that method
taps() can return list of coefficients only if set_taps was called before
for setting taps. In the constructor of filter set_taps is not called, so
my question is which taps does filter use?


On Wed, Jan 29, 2014 at 6:54 PM, Nemanja Savic  wrote:

> Hi all guys,
>
> this two lines of code sort of doesn't work as I expect.
>
> self.channel_filter = gr.fir_filter_ccf(1, firdes.low_pass(10, samp_rate,
> 8, 5000, firdes.WIN_HAMMING, 6.76))
>
> print self.channel_filter.taps(), self.channel_filter
>
> I use 3.6.5.1 version and the only thing I get is empty tuple.
>
> What might be the problem?
>
> Best and thank you,
>
> --
> Nemanja Savić
>



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

[Discuss-gnuradio] can't read fir taps

[Nemanja Savic]

Hi all guys,

this two lines of code sort of doesn't work as I expect.

self.channel_filter = gr.fir_filter_ccf(1, firdes.low_pass(10, samp_rate,
8, 5000, firdes.WIN_HAMMING, 6.76))

print self.channel_filter.taps(), self.channel_filter

I use 3.6.5.1 version and the only thing I get is empty tuple.

What might be the problem?

Best and thank you,

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