Re: [Discuss-gnuradio] ImportError: No module named _osmosdr_swig

[Bastian Bloessl]

Maybe it’s a problem with loading the shared library, similar to this issue:

https://github.com/bastibl/gr-ieee802-11/issues/74

Best,
Bastian


> On 10. May 2017, at 23:19, Fernando  wrote:
> 
> On 10/05/17 22:43, Cinaed Simson wrote:
>> The odd thing is gnuradio-companion should have complained if the
>> PYTHONPATH wasn't being set.
>> 
>> So it's being set somewhere else.
>> 
>> How do you know you only have one installation of gnuradio installed?
> Opensuse has a packet manager similar to debian, I have installed
> gnuradio from the packet manager
> 
>> 
>> And where did you get the gnuradio you installed?
>> 
>> In any case type
>> 
>> which gnuradio-config-info
>> 
>> and
>> 
>>   gnuradio-config-info --prefix --sysconfdir --enabled-components
>> --builddate --prefsdir --version
> 
> fernando@andromeda:~> which gnuradio-config-info
> /usr/bin/gnuradio-config-info
> fernando@andromeda:~> gnuradio-config-info --prefix --sysconfdir
> --enabled-components --builddate --prefsdir --version
> /usr
> /etc
> /etc/gnuradio/conf.d
> 
> python-support;testing-support;volk;doxygen;sphinx;gnuradio-runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;*
> alsa;* oss;* jack;*
> portaudio;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui
> 3.7.11
> fernando@andromeda:~>
> 
> 
>> 
>> Then you need to find your grc.conf file and delete it
>> 
>>  find $HOME -name grc.conf
>> 
>> Then try to start gnuradio-companion - don't add anything to the flow
>> graph. Just see if it starts up properly.
>> 
> 
> It starts properly, but when I try to add both osmocom blocks it crashes
> again
> 
> I have made a clean install of the same version of Opensuse (42.2) in a
> different partition, sharing the same /home partition, installed
> gnuradio and gr-osmosdr and it does not crash
> 
> thanks
> 
> 
> 
> 
> 
> 
> 
>> 
>> 
>>> 
>>> and running gnuradio-companion it crashes again with osmocom
>>> 
>>> 
>>> no luck  :-(
>>> 
>>> thanks
>>> 
>>> 
>>> 
>>> On 10/05/17 03:46, Cinaed Simson wrote:
 On 05/09/2017 12:23 AM, Fernando wrote:
> 
> On 09/05/17 07:02, Cinaed Simson wrote:
>> On 05/08/2017 03:44 PM, Fernando wrote:
>>> My GRC crashes when I place a osmocom source and osmocon sink.
>>> 
>>> Doing some research I have found that is a python problem with 
>>> _osmosdr_swig
>>> 
>>> fernando@andromeda:~> python -c 'import osmosdr' Traceback (most recent
>>> call last):   File "", line 1, inFile
>>> "/usr/lib64/python2.7/site-packages/osmosdr/__init__.py", line 26, in
>>>  from osmosdr_swig import *   File
>>> "/usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py", line 21,
>>> in  _osmosdr_swig = swig_import_helper()   File
>>> "/usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py", line 20,
>>> in swig_import_helper return
>>> importlib.import_module('_osmosdr_swig')   File
>>> "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
>>>__import__(name) ImportError: No module named _osmosdr_swig
>>> fernando@andromeda:~>
>>> 
>>> I am using Opensuse 42.2, and it have been reported taht it works fine
>>> for other people with the same OS.
>>> 
>>> there is a package called python-gr-osmosdr wich contains
>>> /usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py
>> Remove the directory
>> 
>>  /home/fernando/.grc_gnuradio
>> 
>> Check to ensure there's a shared library
>> 
>>   _osmosdr_swig.so
>> 
>> in the same directory.
>> 
>> Check to ensure the installation of gnuradio was added to your python 
>> path
>> 
>>  python -c "import os; print(os.environ.get('PYTHONPATH', ''))"
>> 
>> Check to ensure there's only one installation of gnuradio.
>> 
>> -- Cinaed
>> 
> _osmosdr_swig.so  is here
> 
> andromeda:/home/fernando # find / |grep _osmosdr_swig.so
> /usr/lib64/python2.7/site-packages/osmosdr/_osmosdr_swig.so
> 
> 
> 
> fernando@andromeda:~> python -c "import os;
> print(os.environ.get('PYTHONPATH', ''))"
> it reports no error
 Actually, not reporting a PYTHONPATH is an error.
 
 In order for the gnuradio-companion to find osmosdr/_osmosdr_swig.so it
 needs a PYTHONPATH defined - there's more than version of python
 installed on most Linux systems.
 
 Try it again but type
 
  python2.7 -c "import os; print(os.environ.get('PYTHONPATH', ''))"
 
 It's possible that python is linked to a different version of python2.7
 on your system.
 
 If it's empty again, make sure python2.7 is the version of python you're
 using in your shell by typing
 
   python --version
 
 If the version is not python2.7 (or a minor version of 2.7) then add
 
   alias python="/us

Re: [Discuss-gnuradio] Help needed to obtain AM Depth of Modulation

[Matt Cooper]

You are totally right. I need it to be RF input independent, so I'll try
following your advice.
Thanks a lot!



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Help-needed-to-obtain-AM-Depth-of-Modulation-tp63826p63838.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

Re: [Discuss-gnuradio] Help needed to obtain AM Depth of Modulation

[Matt Cooper]

Wow! Thanks for taking the time to put this together.
I'll try following those steps and let you know how it goes.

Thanks again!



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Help-needed-to-obtain-AM-Depth-of-Modulation-tp63826p63839.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] How to solve command timeout error

[Haile Berhe]

Dear all,
I have been working on my X310 USRP with gnuradio just fine. But after I have
installed rfnoc modules and reload fpga images , the behavior of the
device becomes unpredictable. It sometimes throws the following error
message even if I run legacy gnuradio applications (or non rfnoc application):

“RuntimeError: EnvironmentError: IOError: Block ctrl (CE_00_Port_30)
no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl::wait_for_ack(bool)
  at /home/haile/prefix/default/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197”

I have observed that the above error is not thrown in the first run
after I power cycle the device. [1] seems to discuss the issue but the
proposed solution is not clear. It says, check ce_clk/ce_rst are
connected in the rfnoc_ce_auto_inst_.v., etc .. How am I
supposed to check?

Thanks,

[1] https://kb.ettus.com/RFNoC
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OOT: Output does not update fast. Buffer size?

[Ali]

Hi to all,

I created my own OOT block. It has 6 inputs and 2 outputs and all are type
of float. I am using Signal Source block and sending constant signals with
different amplitudes at each input port.

When I run, the the GRC file and change the one of the inputs, outputs
changes after some time(~5 seconds). To examine the problem, I am printing
the following variables on the screen:

noutput_items, input1[1], input1[noutput_items], output1[1],
output1[noutput_items]

...
8192, 44, 44, 1, 1   >>> Input1 is 44 and outputs are 1
8192, 44, 44, 1, 1   >>> Input 1 is still 44

8192, 44, 26, 1, 1   >>> I changed the input1 to 26. Note that input[1] is
still 44. input[noutput_items] is 26 but output[noutput_items] is also 1!

8192, 26, 26, 1, 1   >>> The content of input1 is all 26, but the output is
still 1!
8192, 26, 26, 1, 1   >>> The output is still 1!
8192, 26, 26, 2, 2   >>> Now the correct output is found!


First of all, why the dimension of input and output is 8192(sometimes
8191)?

samp_rate defined for Signal Source block is smaller than 8192. I am using
1, 100 or 1000. But as you can see noutput_items is 8192. How there can be
8192 inputs if the sample rate is for example 10?

My module content is like the following:


int myfunction_impl::*general_work*(...)
{
const float *input1 = ..
..

for (int i=; i___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help needed to obtain AM Depth of Modulation

[Matt Cooper]

I've been doing some tests, and something strange is happening:

- If I set the generator at 50% modulation depth and I simply plot the
source input, I get  this result   , which
is different from the  graph from Wikipedia

 
; in my graph the peaks and valleys of the envelope at the top are not
"synced" with the ones of the bottom envelope. Any ideas of why can this be
happening?

- Also, if I convert the source from complex to magnitude, I get a  strange
waveform   , but the peaks at the bottom
envelope correspond inversely to the modulation depth set in the generator.
For instance, if I set the depth to 30%, the peaks reach 0.7 in amplitude.
If I set the depth to 80%, the peaks reach 0.2 in amplitude. This might be
useful for me! Is there a way I can use this information as a number output
to get the modulation depth ratio in real time?

Thanks for your help!



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Help-needed-to-obtain-AM-Depth-of-Modulation-tp63826p63842.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

Re: [Discuss-gnuradio] Help needed to obtain AM Depth of Modulation

[Marcus Müller]

Dear Matt,

> - If I set the generator at 50% modulation depth and I simply plot the
> source input, I get  this result   , which
> is different from the  graph from Wikipedia
Looks like clipping on either the TX or RX side. Reduce the output
amplitude of the signal generator.

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

Re: [Discuss-gnuradio] OOT: Output does not update fast. Buffer size?

[West, Nathan]

Sample rate in software is just a number used in some equations to get
meaningful signals. It is *not* the rate that things are going through the
flowgraph. There are 8192 items because 8192 items happens to make a nicely
aligned buffer size.


You're not working on a real-time system or with real-time software, so you
can't expect things like "1 input per second".

On Thu, May 11, 2017 at 6:12 AM, Ali <03do...@gmail.com> wrote:

> Hi to all,
>
> I created my own OOT block. It has 6 inputs and 2 outputs and all are type
> of float. I am using Signal Source block and sending constant signals with
> different amplitudes at each input port.
>
> When I run, the the GRC file and change the one of the inputs, outputs
> changes after some time(~5 seconds). To examine the problem, I am printing
> the following variables on the screen:
>
> noutput_items, input1[1], input1[noutput_items], output1[1],
> output1[noutput_items]
>
> ...
> 8192, 44, 44, 1, 1   >>> Input1 is 44 and outputs are 1
> 8192, 44, 44, 1, 1   >>> Input 1 is still 44
>
> 8192, 44, 26, 1, 1   >>> I changed the input1 to 26. Note that input[1] is
> still 44. input[noutput_items] is 26 but output[noutput_items] is also 1!
>
> 8192, 26, 26, 1, 1   >>> The content of input1 is all 26, but the output
> is still 1!
> 8192, 26, 26, 1, 1   >>> The output is still 1!
> 8192, 26, 26, 2, 2   >>> Now the correct output is found!
> 
>
> First of all, why the dimension of input and output is 8192(sometimes
> 8191)?
>
> samp_rate defined for Signal Source block is smaller than 8192. I am using
> 1, 100 or 1000. But as you can see noutput_items is 8192. How there can be
> 8192 inputs if the sample rate is for example 10?
>
> My module content is like the following:
>
> 
> int myfunction_impl::*general_work*(...)
> {
> const float *input1 = ..
> ..
>
> for (int i=; i {
> *my_function*(input1[i],...,&output1[i],&output2[i])
> }
>
> consume_each(noutput_items);
> return noutput_items;
> }
> --
>
> In short, I want that one input comes per second(sampling rate 1) and one
> output is out and displayed.
>
> Regards,
> Ali
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Loop bandwidth problem of FLL Band Edge block

[Hector Wang]

constellation_soft_decoder1.grc
  
Hello,
   I am learning the example constellation_soft_decoder.grc in
gr_digital/examples directory，I add a FLL Band Edge block before the clock
sync block. Howerver it doesn't work. The loop bandwidth of FLL Band Edge
has to be set to 0,  or the result constellation graph goes wrong. Therefore
I can't handle the situation frequence offset is not 0. It's too weird.
Someone can help me? Thanks.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Loop-bandwidth-problem-of-FLL-Band-Edge-block-tp63845.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] [GSoC 2017] gr-bokehgui: Updates on Week 0

[Kartik Patel]

Hello all,

I am Kartik Patel. I will be working on web-based display mechanism for GNU
Radio during summer 2017.

The module is available on Github at this link
. My primary mode of providing
updates will be a public blog . A brief
email will be sent to this forum for the reference.

The details of the week 0 are available here
[1]. I have
added the git workflow of the module, and tasks of week 0 on the blog.

Kindly reply to this mail for any query or feedback.

Thank you.

Regards,
Kartik Patel


[1] http://kartikpatel.in/GSoC2017/2017/05/11/introduction.html
ᐧ
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Custom C++ blocks on E310

[Jessica Iwamoto]

Hi again,

Attached is the code that I'm using if anyone would like to try to replicate my 
issue. The test_msg_py.py file contains the custom python block code for a 
simple message sink. The test_msg_impl.cc, test_msg_impl.h, and test_msg.h 
files contain the custom C++ code for a message sink. The test.py file contains 
a simple flowgraph that connects a message strobe to my custom message sink 
blocks. When I run test.py with either of the blocks on my desktop, it works 
correctly. However, when I run test.py after cross compiling on the E310, it 
works correctly with the test_msg_py block and produces the following error 
with the test_msg block:
Could not find port: in in:
system
Bus error

Thanks,
Jessica

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+jessica.iwamoto=aero@gnu.org] On Behalf Of 
Jessica Iwamoto
Sent: Wednesday, May 10, 2017 9:53 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Custom C++ blocks on E310

Hi all,

I have built custom C++ blocks that work on my PC, but don't work when cross 
compiled for the E310. Specifically, I am trying to build a custom C++ block 
with a message port and cross compile it for the E310. I am using version 
3.7.12 of GNU radio and the latest version of the SDK/toolchain for the E310. I 
have built a simple message sink block with just a message input port and put 
it in a flowgraph with a message strobe. My code runs correctly on my PC but 
when I run it on the E310, I get the error:
Could not find port: msg in:
system
Bus error

I am able to create custom python blocks with message ports and run them on the 
E310 and my PC with no issues. Additionally, I am unable to create custom C++ 
blocks with normal input and output streams on the E310 (the program seg faults 
when I try to connect the custom block to another block), but they run 
correctly on my PC. Any suggestions on what could be causing this?

Thanks,
Jessica

#ifndef INCLUDED_CUSTOMMOD_TEST_MSG_H
#define INCLUDED_CUSTOMMOD_TEST_MSG_H

#include 
#include 

namespace gr {
  namespace custommod {

/*!
 * \brief <+description of block+>
 * \ingroup custommod
 *
 */
class CUSTOMMOD_API test_msg : virtual public gr::block
{
 public:
  typedef boost::shared_ptr sptr;

  /*!
   * \brief Return a shared_ptr to a new instance of custommod::test_msg.
   *
   * To avoid accidental use of raw pointers, custommod::test_msg's
   * constructor is in a private implementation
   * class. custommod::test_msg::make is the public interface for
   * creating new instances.
   */
  static sptr make();
};

  } // namespace custommod
} // namespace gr

#endif /* INCLUDED_CUSTOMMOD_TEST_MSG_H */#ifndef INCLUDED_CUSTOMMOD_TEST_MSG_IMPL_H
#define INCLUDED_CUSTOMMOD_TEST_MSG_IMPL_H
#include 
#include 

namespace gr {
  namespace custommod {

class test_msg_impl : public test_msg
{
 private:
  // Nothing to declare in this block.

 public:
  test_msg_impl();
  ~test_msg_impl();

  void msg_handler_method(pmt::pmt_t msg);

};

  } // namespace custommod
} // namespace gr

#endif /* INCLUDED_CUSTOMMOD_TEST_MSG_IMPL_H */

test.py
Description: test.py


test_msg_impl.cc
Description: test_msg_impl.cc


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