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 found
>> -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_INCL

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_INCLUDE_DIR)
> CMake Warning (dev) at
> /usr/share/cmake-3.17/Mod

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 <david.ha...@toshiba-trel.com>
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 <marcus.muel...@ettus.com>
> *Cc:* GNURadio Discussion List <discuss-gnuradio@gnu.org>
> *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 <marcus.muel...@ettus.com>
> 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 <marcus.muel...@ettus.com>
> 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 <marcus.muel...@ettus.com>
> 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 loo

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 <vlasi...@gmail.com> 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 <vlasi...@gmail.com>
> 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 <marcus.muel...@ettus.com
> >
> >> 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 (0x

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 <vlasi...@gmail.com> 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 <marcus.muel...@ettus.com>
> 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

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 <marcus.muel...@ettus.com>
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 <marcus.muel...@ettus.com>
> 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 <marcus.muel...@ettus.com>
>> 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 <marcus.muel...@ettus.com>
>>> 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

[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] 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 <marcus.muel...@ettus.com>
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
>> 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

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 <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
> 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]

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 <marcus.muel...@ettus.com>
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 => 

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 <marcus.muel...@ettus.com>
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 <vlasi...@gmail.com>
> 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 <marcus.muel...@ettus.com
> >
> >> 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 <vlasi...@gmail.com> 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 <marcus.muel...@ettus.com>
> 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
>>> 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]

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 <marcus.muel...@ettus.com>
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 <marcus.muel...@ettus.com>
> wrote:
>
>> Hm, that really was my hope. Sorry, I'm out of ideas.
>>
>> On 11/05/2015 05:39 PM, Nemanja Savic wrote:
>> > everything

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 <marcus.muel...@ettus.com>
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] 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 <marcus.muel...@ettus.com>
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 <marcus.muel...@ettus.com>
> 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 <marcus.muel...@ettus.com>
>> 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 

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 <marcus.muel...@ettus.com>
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 <marcus.muel...@ettus.com>
> 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] 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 <marcus.muel...@ettus.com>
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 <marcus.muel...@ettus.com>
> 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 <marcus.muel...@ettus.com
>> > 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 <marcus.muel...@ettus.com>
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 <marcus.muel...@ettus.com>
> 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>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>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>vlasi...@gmail.com>:
>>>>
>>>>> Hi all guys,
>>>>>
>>>>> i built yesterday 3.7

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 <marcus.muel...@ettus.com>
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 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_TM

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 <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 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]

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 <vlasi...@gmail.com> 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 <marcus.muel...@ettus.com>
> 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] 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 <vlasi...@gmail.com> 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 <vlasi...@gmail.com> 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 <marcus.muel...@ettus.com>
>> 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] 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 t...@trondeau.com wrote:

 On Thu, Jun 4, 2015 at 12:58 PM, Martin Braun martin.br...@ettus.com
 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 martin.br...@ettus.com
  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

[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

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 marcus.muel...@ettus.com
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] 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]

@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 marcus.muel...@ettus.com
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

[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] 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 mle...@ripnet.com 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

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 martin.br...@ettus.com 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 file_sink_lim_b (2)]:
  gr_block_detail::n_output_items
  1: thread[thread-per-block[1]: gr_block file_sink_lim_b (5)]:
  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

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 marcus.muel...@ettus.com
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] 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 file_sink_lim_b (2)]:
gr_block_detail::n_output_items
1: thread[thread-per-block[1]: gr_block file_sink_lim_b (5)]:
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] 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 vlasi...@gmail.com 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] 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 vlasi...@gmail.com 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 vlasi...@gmail.com
 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

[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

[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] 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 marcus.muel...@ettus.com
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

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 mle...@ripnet.com 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 mle...@ripnet.com 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 vlasi...@gmail.com
 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, mle...@ripnet.com 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]

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, mle...@ripnet.com 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

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 vlasi...@gmail.com 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, mle...@ripnet.com 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]

is there any way to synchronize those two clocks sources?

On Tue, Dec 9, 2014 at 4:51 PM, Marcus D. Leech mle...@ripnet.com 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 vlasi...@gmail.com 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, mle...@ripnet.com 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

[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 t...@trondeau.com wrote:

 On Mon, May 26, 2014 at 4:49 AM, Nemanja Savic vlasi...@gmail.com 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] 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 user0...@gmail.com 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

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 vlasi...@gmail.com wrote:

 It is written:
 Using Volk machine: avx_64_mmx

 Best


 On Tue, May 13, 2014 at 10:49 AM, Martin Braun martin.br...@ettus.comwrote:

 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

[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 martin.br...@ettus.comwrote:

 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] 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 vlasi...@gmail.com 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 t...@trondeau.com wrote:

 On Wed, Feb 26, 2014 at 6:23 AM, Nemanja Savic vlasi...@gmail.com
 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
 module
  from gnuradio.wxgui import fftsink2
File
  /usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/fftsink2.py,
 line
  34, in module
  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 vlasi...@gmail.com
 wrote:
 
  Thank you Tom. I try tomorrow.
 
 
  On Tue, Feb 25, 2014 at 4:20 PM, Tom Rondeau t...@trondeau.com wrote:
 
  On Tue, Feb 25, 2014 at 9:35 AM, Nemanja Savic vlasi...@gmail.com
  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 t...@trondeau.com
 wrote:
  
   On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic vlasi...@gmail.com
 
   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
   martin.br...@ettus.com
   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]

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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 10:00 AM, Nemanja Savic vlasi...@gmail.com 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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 9:43 AM, Nemanja Savic vlasi...@gmail.comwrote:

 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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 9:29 AM, Nemanja Savic vlasi...@gmail.comwrote:

 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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 9:14 AM, Nemanja Savic vlasi...@gmail.comwrote:

 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 t...@trondeau.comwrote:

 On Fri, May 9, 2014 at 8:01 AM, Nemanja Savic 
 vlasi...@gmail.comwrote:

 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 
 vlasi...@gmail.com wrote:

 You are right regarding search

[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] 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 marcus.muel...@ettus.comwrote:

 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

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 vlasi...@gmail.com 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.comwrote:

 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]

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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 8:01 AM, Nemanja Savic vlasi...@gmail.com 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 vlasi...@gmail.comwrote:

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





-- 
Nemanja Savić

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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 9:14 AM, Nemanja Savic vlasi...@gmail.com 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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 8:01 AM, Nemanja Savic vlasi...@gmail.comwrote:

 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 vlasi...@gmail.comwrote:

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

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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 9:29 AM, Nemanja Savic vlasi...@gmail.com 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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 9:14 AM, Nemanja Savic vlasi...@gmail.comwrote:

 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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 8:01 AM, Nemanja Savic vlasi...@gmail.comwrote:

 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 
 vlasi...@gmail.comwrote:

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

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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 9:43 AM, Nemanja Savic vlasi...@gmail.com 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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 9:29 AM, Nemanja Savic vlasi...@gmail.comwrote:

 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 t...@trondeau.com wrote:

 On Fri, May 9, 2014 at 9:14 AM, Nemanja Savic vlasi...@gmail.comwrote:

 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 t...@trondeau.comwrote:

 On Fri, May 9, 2014 at 8:01 AM, Nemanja Savic vlasi...@gmail.comwrote:

 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 vlasi...@gmail.com
  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:
 
  [ 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

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 vlasi...@gmail.com 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

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 vlasi...@gmail.com 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 vlasi...@gmail.comwrote:

 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] 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 t...@trondeau.com wrote:

 On Wed, Feb 26, 2014 at 6:23 AM, Nemanja Savic vlasi...@gmail.com 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
 module
  from gnuradio.wxgui import fftsink2
File
  /usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/fftsink2.py,
 line
  34, in module
  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 vlasi...@gmail.com
 wrote:
 
  Thank you Tom. I try tomorrow.
 
 
  On Tue, Feb 25, 2014 at 4:20 PM, Tom Rondeau t...@trondeau.com wrote:
 
  On Tue, Feb 25, 2014 at 9:35 AM, Nemanja Savic vlasi...@gmail.com
  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 t...@trondeau.com
 wrote:
  
   On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic vlasi...@gmail.com
   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
   martin.br...@ettus.com
   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

[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]

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 mar...@hostalia.de 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]: gr_block db_logger2 (65)]: 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 mar...@hostalia.de
  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]: gr_block
  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
  vlasi...@gmail.com 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]: gr_block db_logger2 (62)]:
  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
 
 
  ___ 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/

 iQEcBAEBAgAGBQJTTULeAAoJEBQ6EdjyzlHtRIcH/2kpne7BIFs7hb0YyYAEGh00
 Z4oDFaekEmL5j3GSmPojmREqjVvbHCaHohgBDPQh45SleBQ/I88t8GvcNEqZa2VB
 djH9a34uDu/IY5kZTaH2yNisEJq2QNMo6BNjelQTE52u6/53vrBzxgbPgTT1u8Ci

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 vlasi...@gmail.com 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 mar...@hostalia.de 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]: gr_block db_logger2 (65)]: 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 mar...@hostalia.de
  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]: gr_block
  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
  vlasi...@gmail.com 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]: gr_block db_logger2 (62)]:
  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
 
 
  ___ 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

Re: [Discuss-gnuradio] catching unrecognized exception

[Nemanja Savic]

Hi again,

so, the exception appeared again. Just to remind:
thread[thread-per-block[0]: gr_block db_logger2 (65)]: 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 mar...@hostalia.de 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]: gr_block 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 vlasi...@gmail.com
  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]: gr_block db_logger2 (62)]: 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]

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 m...@scanoo.com 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 vlasi...@gmail.com wrote:

 Hi again,

 so, the exception appeared again. Just to remind:
 thread[thread-per-block[0]: gr_block db_logger2 (65)]: 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 mar...@hostalia.dewrote:

 -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]: gr_block 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 vlasi...@gmail.com
  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]: gr_block db_logger2 (62)]: 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

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]: gr_block 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 vlasi...@gmail.com 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]: gr_block db_logger2 (62)]: 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]: gr_block db_logger2 (62)]: 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 module
from gnuradio.wxgui import fftsink2
  File
/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/fftsink2.py, line
34, in module
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 vlasi...@gmail.com wrote:

 Thank you Tom. I try tomorrow.


 On Tue, Feb 25, 2014 at 4:20 PM, Tom Rondeau t...@trondeau.com wrote:

 On Tue, Feb 25, 2014 at 9:35 AM, Nemanja Savic vlasi...@gmail.com
 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 t...@trondeau.com wrote:
 
  On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic vlasi...@gmail.com
 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 martin.br...@ettus.com
 
  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

[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] 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 t...@trondeau.com wrote:

 On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic vlasi...@gmail.com 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 martin.br...@ettus.comwrote:

 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

Re: [Discuss-gnuradio] broken gnuplot

[Nemanja Savic]

Thank you Tom. I try tomorrow.


On Tue, Feb 25, 2014 at 4:20 PM, Tom Rondeau t...@trondeau.com wrote:

 On Tue, Feb 25, 2014 at 9:35 AM, Nemanja Savic vlasi...@gmail.com 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 t...@trondeau.com wrote:
 
  On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic vlasi...@gmail.com
 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 martin.br...@ettus.com
  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] 回复： import error: no

[Nemanja Savic]

You are right.
Thank you


On Tue, Feb 18, 2014 at 4:18 PM, Tiankun Hu hutiantia...@qq.com wrote:

 seems need do ldconfig
 -- 原始邮件 --
 *发件人:* Nemanja Savicvlasi...@gmail.com
 *发送时间:* 2014年2月18日(星期二) 晚上10:02
 *收件人:* GNURadio Discussion Listdiscuss-gnuradio@gnu.org;
 *主题:* [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
 module
 ??? import NMS
 ? File /usr/local/lib/python2.7/dist-packages/NMS/__init__.py, line 45,
 in module
 ??? from NMS_swig import *
 ? File /usr/local/lib/python2.7/dist-packages/NMS/NMS_swig.py, line 26,
 in module
 ??? _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

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 oz9...@gmail.com wrote:

 On Wed, Feb 12, 2014 at 10:51 AM, Nemanja Savic 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

 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

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 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 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

 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 intel 6 series / c200.
could rhel 6 be the prolem here as usually?


On Wed, Feb 12, 2014 at 4:13 PM, Volker Schroer dl1...@gmx.de 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 dl1...@gmx.de
 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
 vlasi...@gmail.com 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] 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 m...@alum.mit.edu wrote:

 On Feb 3, 2014, at 10:14 AM, Nemanja Savic vlasi...@gmail.com 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] 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 feng...@umich.edu 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] 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 doc in xml GRC file of ur block. For example:

  doc
Doceder consists of two sub blocks:
blah blah
  /doc

as for the missing tag doc, just add it.

best,
Nemanja


On Tue, Feb 4, 2014 at 7:07 PM, Zhe Feng feng...@umich.edu wrote:

 Hi Nemanja,

 I checked the xml files and I didn't find the documentations. By the way,
 I don't see a doc 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] Fwd: Documentation for out-of-tree module

[Nemanja Savic]

Under tag doc.


On Tue, Feb 4, 2014 at 5:15 PM, Zhe Feng feng...@umich.edu 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

[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] 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 vlasi...@gmail.com 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 t...@trondeau.com wrote:

 On Wed, Jan 29, 2014 at 4:04 AM, Nemanja Savic vlasi...@gmail.comwrote:

 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]

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 vlasi...@gmail.com 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

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 t...@trondeau.com wrote:

 On Thu, Jan 30, 2014 at 4:47 AM, Nemanja Savic vlasi...@gmail.com 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 vlasi...@gmail.com
 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] synchronization between blocks

[Nemanja Savic]

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 t...@trondeau.com wrote:

 On Wed, Jan 29, 2014 at 4:04 AM, Nemanja Savic vlasi...@gmail.com 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ć
___
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

Re: [Discuss-gnuradio] WBX Lo leakage to LFRX

[Nemanja Savic]

I have a following doubt here: there are two cables, one that brings 10.7
MHz if signal from external rf frontend to the usrp, and utp cable that
provides power and control signals for rf frontend. My first doubt was that
WBX LO signal is directly induced in the lines on LFRX board, but as soon
as I disconnected signal cable from rf frontend to usrp the spike
dissapeared, so it comes for sure from rf frontend. The problem is how.
Should i put rc filters at the endof every controll signal? The other
question is how to connect shields of both cables in proper way? I don't
want to make ground loop.

thanx


On Tue, Dec 10, 2013 at 5:32 PM, Marcus D. Leech mle...@ripnet.com wrote:

  On 12/10/2013 11:24 AM, Nemanja Savic wrote:

 But I think that I have problem with RX LO of WBX, because I don't use TX
 in my application, I have two receivers. External RF frontend brings HF to
 IF and is connected using coax with usrp (LFRX). The other cable, UTP,
 connects io pins as well as power of LFRX to external frontend. Interesting
 thing is that when I unplug my frontend the spike doesn exist any more in
 the spectrum of LFRX signal, which means that maybe noise comes via UTP
 cable, because it's shield is not bonded to ground.


  Well, again, you can offset the RX LO.



  On Tue, Dec 10, 2013 at 5:12 PM, Marcus D. Leech mle...@ripnet.comwrote:

  On 12/10/2013 10:41 AM, Nemanja Savic wrote:

 hi,
 thank you Ralph.
 It looks like I should have known about not packing two receivers in the
 same band in the sme box, but anyway, rf parts are not in the same box, and
 I intended to keep them at the distance of arround 5 to 10 meters. Antenna
 of 434MHz in is more or less conected directly do the pin, there just
 matching cuircuit between. The 10.7 MHz out will be with 5 - 10 meters long
 cable connected with USRP. Power supply of external frontend runs through
 twisted pair of a UTP CAT 2 cable, which is kind of shielded, and I have a
 few capacitors on the other end for filtering supply line. As for the LP
 filter on the 10.7 MHz, i think that LFRX itself has cuoff frequency of
 arround 50 MHz or so. Will it help a bit if I put some alu plates over WBX
 board?

 --
 Nemanja Savić

  The problem is that even with 50dB LO suppression in the TX mixer,
 there will still be some LO energy leaking out the antenna port.

 But something you *can* do is use offset-tuning on the TX side to move
 the LO off to the side.  It'll still be there, but outside of your RX
 passband.

 In built for a specific purpose radios, it's often the case that the
 last conversion stage uses a fixed LO that is offset from the final
 frequency, and
   there's a deep notch filter on the output of the final mixer.  That
 strategy isn't possible in designs like these that aren't for a specific
 purpose, since
   there's only a single conversion stage, with variable LO--you'd have to
 put in a notch yourself.




 --
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortium
 http://www.sbrac.org



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




 --
 Nemanja Savić


 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 --
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org


 ___
 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] [USRP-users] WBX Lo leakage to LFRX

[Nemanja Savic]

Hi,

i don't understand what can I do in this way with balun. Antenna is matched
very well I think, since I copied reference design from TI.
I am sure that spike comes from WBX LO because when I change center
frequency the spike also shifts. I'll remind about the configuration again:
USRP1 with WBX and LFRX. I want two 434 MHz receivers. One receiver is
made  with WBX as RF frontend, while the second receiver uses TI CC1000
transciever as RF frontend. CC1000 provides 10.7 M IF signal. From USRP to
CC1000 there are two cables, one is coax for IF signal and another is UTP
for power and controlling. I am pretty sure that leakage signal comes
through utp cable and disturbs ground or i don't know what. Power supply is
decoupled many times with caps. This now the point where experience of the
engineer comes into the came, but unfortunately I am not that experienced.
I would like to know what would you do with the shield of coax cable and
UTP cable? How probable is that I will make a ground loop in that way?

Thanx


On Mon, Dec 16, 2013 at 4:09 PM, Patrik Tast pat...@poes-weather.comwrote:

 Hi,

 Try finding ferrites for your frequency (11 MHz) and google on BalUn
 (balanced to unbalanced), http://en.wikipedia.org/wiki/Balun

 You could also do it with COAX, impedance match using the Smith Chart,
 if your antenna impedance is known eg
 http://en.wikipedia.org/wiki/Smith_chart

 Very usual interference at low freqs are AC power sources...and are
 harmless (you wont see the *spike* when you see a proper signal)

 Patrik



 On Mon, 2013-12-16 at 14:38 +0100, Nemanja Savic wrote:
  I have a following doubt here: there are two cables, one that brings
  10.7 MHz if signal from external rf frontend to the usrp, and utp
  cable that provides power and control signals for rf frontend. My
  first doubt was that WBX LO signal is directly induced in the lines on
  LFRX board, but as soon as I disconnected signal cable from rf
  frontend to usrp the spike dissapeared, so it comes for sure from rf
  frontend. The problem is how. Should i put rc filters at the endof
  every controll signal? The other question is how to connect shields of
  both cables in proper way? I don't want to make ground loop.
 
 
  thanx
 
 
 
  On Tue, Dec 10, 2013 at 5:32 PM, Marcus D. Leech mle...@ripnet.com
  wrote:
  On 12/10/2013 11:24 AM, Nemanja Savic wrote:
   But I think that I have problem with RX LO of WBX, because I
   don't use TX in my application, I have two receivers.
   External RF frontend brings HF to IF and is connected using
   coax with usrp (LFRX). The other cable, UTP, connects io
   pins as well as power of LFRX to external frontend.
   Interesting thing is that when I unplug my frontend the
   spike doesn exist any more in the spectrum of LFRX signal,
   which means that maybe noise comes via UTP cable, because
   it's shield is not bonded to ground.
  
  
  
  
  Well, again, you can offset the RX LO.
 
 
 
   On Tue, Dec 10, 2013 at 5:12 PM, Marcus D. Leech
   mle...@ripnet.com wrote:
   On 12/10/2013 10:41 AM, Nemanja Savic wrote:
   hi,
   thank you Ralph.
   It looks like I should have known about not
   packing two receivers in the same band in
   the sme box, but anyway, rf parts are not in
   the same box, and I intended to keep them at
   the distance of arround 5 to 10 meters.
   Antenna of 434MHz in is more or less
   conected directly do the pin, there just
   matching cuircuit between. The 10.7 MHz out
   will be with 5 - 10 meters long cable
   connected with USRP. Power supply of
   external frontend runs through twisted pair
   of a UTP CAT 2 cable, which is kind of
   shielded, and I have a few capacitors on the
   other end for filtering supply line. As for
   the LP filter on the 10.7 MHz, i think that
   LFRX itself has cuoff frequency of arround
   50 MHz or so. Will it help a bit if I put
   some alu plates over WBX board?
  
   --
   Nemanja Savić
   The problem is that even with 50dB LO suppression in
   the TX mixer, there will still be some LO energy
   leaking out the antenna port.
  
   But something you *can* do is use offset-tuning on
   the TX side to move the LO off to the side.  It'll
   still be there, but outside

Re: [Discuss-gnuradio] [USRP-users] WBX Lo leakage to LFRX

[Nemanja Savic]

Well, maybe I can use spectrum analyser with proper antenna, but what can I
achieve with that. If I see peak, I still have a problem to attenuate it.


On Mon, Dec 16, 2013 at 4:36 PM, Ralph A. Schmid, dk5ras
ra...@schmid.xxxwrote:

 Take a handheld scanner or a UHF walkie talkie, tune it to the LO
 frequency, use a paperclip or some similar 2cm piece of wire as antenna,
 and start sniffing with this improvised probe for the leakage.


 Ralph.





 *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf
 Of *Nemanja Savic
 *Sent:* Monday, December 16, 2013 4:26 PM
 *To:* Patrik Tast
 *Cc:* usrp-us...@lists.ettus.com; GNURadio Discussion List
 *Subject:* Re: [USRP-users] [Discuss-gnuradio] WBX Lo leakage to LFRX



 Hi,

 i don't understand what can I do in this way with balun. Antenna is
 matched very well I think, since I copied reference design from TI.

 I am sure that spike comes from WBX LO because when I change center
 frequency the spike also shifts. I'll remind about the configuration again:

 USRP1 with WBX and LFRX. I want two 434 MHz receivers. One receiver is
 made  with WBX as RF frontend, while the second receiver uses TI CC1000
 transciever as RF frontend. CC1000 provides 10.7 M IF signal. From USRP to
 CC1000 there are two cables, one is coax for IF signal and another is UTP
 for power and controlling. I am pretty sure that leakage signal comes
 through utp cable and disturbs ground or i don't know what. Power supply is
 decoupled many times with caps. This now the point where experience of the
 engineer comes into the came, but unfortunately I am not that experienced.
 I would like to know what would you do with the shield of coax cable and
 UTP cable? How probable is that I will make a ground loop in that way?

 Thanx



 On Mon, Dec 16, 2013 at 4:09 PM, Patrik Tast pat...@poes-weather.com
 wrote:

 Hi,

 Try finding ferrites for your frequency (11 MHz) and google on BalUn
 (balanced to unbalanced), http://en.wikipedia.org/wiki/Balun

 You could also do it with COAX, impedance match using the Smith Chart,
 if your antenna impedance is known eg
 http://en.wikipedia.org/wiki/Smith_chart

 Very usual interference at low freqs are AC power sources...and are
 harmless (you wont see the *spike* when you see a proper signal)

 Patrik




 On Mon, 2013-12-16 at 14:38 +0100, Nemanja Savic wrote:
  I have a following doubt here: there are two cables, one that brings
  10.7 MHz if signal from external rf frontend to the usrp, and utp
  cable that provides power and control signals for rf frontend. My
  first doubt was that WBX LO signal is directly induced in the lines on
  LFRX board, but as soon as I disconnected signal cable from rf
  frontend to usrp the spike dissapeared, so it comes for sure from rf
  frontend. The problem is how. Should i put rc filters at the endof
  every controll signal? The other question is how to connect shields of
  both cables in proper way? I don't want to make ground loop.
 
 
  thanx
 
 
 
  On Tue, Dec 10, 2013 at 5:32 PM, Marcus D. Leech mle...@ripnet.com
  wrote:
  On 12/10/2013 11:24 AM, Nemanja Savic wrote:
   But I think that I have problem with RX LO of WBX, because I
   don't use TX in my application, I have two receivers.
   External RF frontend brings HF to IF and is connected using
   coax with usrp (LFRX). The other cable, UTP, connects io
   pins as well as power of LFRX to external frontend.
   Interesting thing is that when I unplug my frontend the
   spike doesn exist any more in the spectrum of LFRX signal,
   which means that maybe noise comes via UTP cable, because
   it's shield is not bonded to ground.
  
  
  
  
  Well, again, you can offset the RX LO.
 
 
 
   On Tue, Dec 10, 2013 at 5:12 PM, Marcus D. Leech
   mle...@ripnet.com wrote:
   On 12/10/2013 10:41 AM, Nemanja Savic wrote:
   hi,
   thank you Ralph.
   It looks like I should have known about not
   packing two receivers in the same band in
   the sme box, but anyway, rf parts are not in
   the same box, and I intended to keep them at
   the distance of arround 5 to 10 meters.
   Antenna of 434MHz in is more or less
   conected directly do the pin, there just
   matching cuircuit between. The 10.7 MHz out
   will be with 5 - 10 meters long cable
   connected with USRP. Power supply of
   external frontend runs through twisted pair
   of a UTP CAT 2 cable, which is kind of
   shielded, and I have a few capacitors on the
   other end

Re: [Discuss-gnuradio] [USRP-users] WBX Lo leakage to LFRX

[Nemanja Savic]

Yes I would really like to know not to guess, in that case I could probably
be able to solve it. It is pretty like this: by disconnecting 10.7 MHz
cable the spike disappeared so I said ok it doesn't come from inside USRP,
but rather through coax cable. Since cable is shielded I assume it even
goes somehow into complete receiving chain. Two possibilities to come into
the chain: usrp and external box are close enough and thus coupling occurs.
If not, signal probably travels over control signals through UTP cable.
What I will probably try is to put rc filters on controll lines.


On Mon, Dec 16, 2013 at 5:54 PM, Ralph A. Schmid, dk5ras
ra...@schmid.xxxwrote:

 First of all you need to _*know*_ (not _*guess*_), where it comes from,
 where it goes to…



 Ralph.



 *From:* Nemanja Savic [mailto:vlasi...@gmail.com]
 *Sent:* Monday, 16 December, 2013 16:48
 *To:* Ralph A. Schmid, dk5ras
 *Cc:* Patrik Tast; usrp-us...@lists.ettus.com; GNURadio Discussion List

 *Subject:* Re: [USRP-users] [Discuss-gnuradio] WBX Lo leakage to LFRX



 Well, maybe I can use spectrum analyser with proper antenna, but what can
 I achieve with that. If I see peak, I still have a problem to attenuate it.



 On Mon, Dec 16, 2013 at 4:36 PM, Ralph A. Schmid, dk5ras ra...@schmid.xxx
 wrote:

 Take a handheld scanner or a UHF walkie talkie, tune it to the LO
 frequency, use a paperclip or some similar 2cm piece of wire as antenna,
 and start sniffing with this improvised probe for the leakage.


 Ralph.





 *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf
 Of *Nemanja Savic
 *Sent:* Monday, December 16, 2013 4:26 PM
 *To:* Patrik Tast
 *Cc:* usrp-us...@lists.ettus.com; GNURadio Discussion List
 *Subject:* Re: [USRP-users] [Discuss-gnuradio] WBX Lo leakage to LFRX



 Hi,

 i don't understand what can I do in this way with balun. Antenna is
 matched very well I think, since I copied reference design from TI.

 I am sure that spike comes from WBX LO because when I change center
 frequency the spike also shifts. I'll remind about the configuration again:

 USRP1 with WBX and LFRX. I want two 434 MHz receivers. One receiver is
 made  with WBX as RF frontend, while the second receiver uses TI CC1000
 transciever as RF frontend. CC1000 provides 10.7 M IF signal. From USRP to
 CC1000 there are two cables, one is coax for IF signal and another is UTP
 for power and controlling. I am pretty sure that leakage signal comes
 through utp cable and disturbs ground or i don't know what. Power supply is
 decoupled many times with caps. This now the point where experience of the
 engineer comes into the came, but unfortunately I am not that experienced.
 I would like to know what would you do with the shield of coax cable and
 UTP cable? How probable is that I will make a ground loop in that way?

 Thanx



 On Mon, Dec 16, 2013 at 4:09 PM, Patrik Tast pat...@poes-weather.com
 wrote:

 Hi,

 Try finding ferrites for your frequency (11 MHz) and google on BalUn
 (balanced to unbalanced), http://en.wikipedia.org/wiki/Balun

 You could also do it with COAX, impedance match using the Smith Chart,
 if your antenna impedance is known eg
 http://en.wikipedia.org/wiki/Smith_chart

 Very usual interference at low freqs are AC power sources...and are
 harmless (you wont see the *spike* when you see a proper signal)

 Patrik




 On Mon, 2013-12-16 at 14:38 +0100, Nemanja Savic wrote:
  I have a following doubt here: there are two cables, one that brings
  10.7 MHz if signal from external rf frontend to the usrp, and utp
  cable that provides power and control signals for rf frontend. My
  first doubt was that WBX LO signal is directly induced in the lines on
  LFRX board, but as soon as I disconnected signal cable from rf
  frontend to usrp the spike dissapeared, so it comes for sure from rf
  frontend. The problem is how. Should i put rc filters at the endof
  every controll signal? The other question is how to connect shields of
  both cables in proper way? I don't want to make ground loop.
 
 
  thanx
 
 
 
  On Tue, Dec 10, 2013 at 5:32 PM, Marcus D. Leech mle...@ripnet.com
  wrote:
  On 12/10/2013 11:24 AM, Nemanja Savic wrote:
   But I think that I have problem with RX LO of WBX, because I
   don't use TX in my application, I have two receivers.
   External RF frontend brings HF to IF and is connected using
   coax with usrp (LFRX). The other cable, UTP, connects io
   pins as well as power of LFRX to external frontend.
   Interesting thing is that when I unplug my frontend the
   spike doesn exist any more in the spectrum of LFRX signal,
   which means that maybe noise comes via UTP cable, because
   it's shield is not bonded to ground.
  
  
  
  
  Well, again, you can offset the RX LO.
 
 
 
   On Tue, Dec 10, 2013 at 5:12 PM, Marcus D. Leech
   mle...@ripnet.com wrote:
   On 12

[Discuss-gnuradio] WBX Lo leakage to LFRX

[Nemanja Savic]

Hi all,

As I described in one of my previousposts, I wanted to have several
receiving paths for 434 MHz, and my USRP is equipped owith WBX and LFTX. So
WBX is one, and for the other, I designed small RF frontend using TI's
CC1000 that donwnconverts the signal to 10.7 MHz which can be used with
LFRX. Now the problem is that i have like 30 - 40 dB spike in the spectrum
of received signal at LFRX thata comes from the LO of the WBX. Is there any
suggestion how to supress this signal, but first from phisycal point of
few, and later if not possible trying to use some DSP manipulations.
Namely, I packed new frontend in the alu box, so it's kind of shielded, but
it didn't help that much.

Thanx,

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