GNU Radio, One Step at a Time: July 2018

Tuesday, July 31, 2018

[Discuss-gnuradio] Regarding USRP_ECHOTIMER in gr-radar

Hello to all,

I have been facing problem regarding the values to be filled in
USRP_ECHOTIMER in gr-radar block such as clock source, time source

return _radar_swig.usrp_echotimer_cc_make(*args, **kwargs)
RuntimeError: RuntimeError: Invalid option chosen for: clock source

Anyone help me by sending Some documents or suggesting link where I
can learn about this.

Regards,
Prabhat

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

Re: [Discuss-gnuradio] Issue with swig in packet_headerparser block

Hi Michael,

Thank you very much for your help. The top-level CMakelists.txt was okay. I found that the CMakelists.txt in the include directory was missing "packet_header_default.h" definition. Now, I am able to debug with now error.

Regards

Jebreel

Jebreel Salem

On Tue, Jul 31, 2018 at 2:02 PM, Michael Dickens <michael.dickens@ettus.com> wrote:

Hi Jebreel - From the import error, it looks like either you're not linking against gr-digital library, or you're referencing some function or method or variables that doesn't exist in (isn't being exported from) the gr-digital library. Did you verify in your OOT's top-level CMakeLists.txt that when you're finding GR, you're specifying "digital" (as well as probably: runtime, blocks)? The line will be something like:

{{{

set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS DIGITAL)

}}}

To get the SWIG part working, you do need a little special SWIG sauce ... and, as you are hopefully finding, sometimes it's best to just copy from the SWIG file that does this in gr-digital & tweak it to your specific class. I'm not sure the SWIG is 100% correct, but it looks good at first reading to me.

If you continue to have errors, I'd suggest you push your GR OOT into a public repo (e.g., on GitHub) & post a link to it so that those of us who have done this before can work with actual code & thus provide real feedback instead of best guesses based on incomplete code.

Hope this is useful. - MLD

On Tue, Jul 31, 2018, at 1:15 PM, Jebreel Salem wrote:

Hello Marcus,

Thank you very much for your reply. The flag is there. However, I think the problem is with SWIG file because it does not have the correct definitions for packet_header_default. I copied the packet_header_default.cc from the ofdm gnuradio and put it in my lib directory and copied packet_header_default.h and put it in my include directory. So I did not create using gr_modtool add. I add manually all definition and paths but I am not sure if missed something. Here is my swig file with definitions I added (I changed the name of the class digitalc) but I am still getting errors.

/* -*- c++ -*- */

#define DIGITALC_API

%include "gnuradio.i" // the common stuff

//load generated python docstrings

%include "digitalc_swig_doc.i"

%{

#include "digitalc/packet_headerparser_b.h"

#include "digitalc/packet_header_default.h"

%}

%include "digitalc/packet_headerparser_b.h"

%include "digitalc/packet_header_default.h"

GR_SWIG_BLOCK_MAGIC2(digitalc, packet_headerparser_b);

%template(packet_header_default_sptr) boost::shared_ptr<gr::digitalc::packet_header_default>;

%pythoncode %{

packet_header_default_sptr.__repr__ = lambda self: "<packet_header_default>"

packet_header_default = packet_header_default .make;

%}

Here is the error I am getting:

Traceback (most recent call last):

File "/home/dev/Gnuradio_Prjs/parser/gr-digitalc/python/qa_packet_headerparser_b.py", line 32, in <module>

import digitalc.digitalc_swig as digitalc

File "/usr/local/lib/python2.7/dist-packages/digitalc/digitalc_swig.py", line 28, in <module>

_digitalc_swig = swig_import_helper()

File "/usr/local/lib/python2.7/dist-packages/digitalc/digitalc_swig.py", line 24, in swig_import_helper

_mod = imp.load_module('_digitalc_swig', fp, pathname, description)

ImportError: /home/dev/Gnuradio_Prjs/parser/gr-digitalc-debug/lib/libgnuradio-digitalc-1.0.0git.so.0.0.0: undefined symbol: _ZN2gr8digitalc21packet_header_defaultC1ElRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_i

Thanks for the help!

Regards,

Jebreel

Jebreel Salem

On Tue, Jul 31, 2018 at 4:54 AM, Müller, Marcus (CEL) <mueller@kit.edu> wrote:

Looks like your library doesn't export that symbol (in this case, the

constructor of the packet_header_default class). Did you make sure that

the class bears the SPERRY_API flag?

Best regards,

Marcus

On Mon, 2018-07-30 at 16:35 -0500, Jebreel Salem wrote:

> Hi,

> I am trying to create packet_headerparser block. The purpose is to first duplicate the block and then modify it (mostly I would like to modify the dict part). I followed the the instruction in howto tutorial but I got the error below when I tried to run the qa_packet_headerparser_b.py. I am not sure what I did wrong but I was able to duplicate demux block and make it work fine. Any hint on this is grealty appreciated.

>

>

> Traceback (most recent call last):

> File "/home/dev/Gnuradio_Prjs/parser/gr-sperry/python/qa_packet_headerparser_b.py", line 28, in <module>

> import sperry.sperry_swig as sperry

> File "/usr/local/lib/python2.7/dist-packages/sperry/sperry_swig.py", line 28, in <module>

> _sperry_swig = swig_import_helper()

> File "/usr/local/lib/python2.7/dist-packages/sperry/sperry_swig.py", line 24, in swig_import_helper

> _mod = imp.load_module('_sperry_swig', fp, pathname, description)

> ImportError: /home/dev/Gnuradio_Prjs/parser/gr-sperry-debug/lib/libgnuradio-sperry-1.0.0git.so.0.0.0: undefined symbol: _ZN2gr6sperry21packet_header_defaultC1ElRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_i

>

> Thanks!

>

> Jebreel Salem

>

> _______________________________________________

> Discuss-gnuradio mailing list

> Discuss-gnuradio@gnu.org

> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________

Discuss-gnuradio mailing list

Discuss-gnuradio@gnu.org

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installation error for USRP N200

On 07/31/2018 02:38 PM, Ayaz Mahmud wrote:

Hi,

I have already been using two USRP B210 over Gnuradio 3.7.10.1 which works perfect.

Now I am trying to bring in a N200 USRP, and installing it.

I can ping the IP 192.168.10.2/24 from my PC 192.168.10.1/24

I can also detect all the 3 devices with "uhd_find_devices"

When I run "uhd_usrp_probe" it gives error:

Please update the firmware and FPGA images for your device. See the….

Please run:

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

"/usr/local/bin/uhd_image_loader –args="type=usrp2,addr=192.168.10.2"

I have run both the above command, 1^st command says that all the targets are up to date and the 2^nd command erases and re-wrights the firmware. But then returns the same error for "uhd_usrp_probe".

Can you please let me know if I am doing anything wrong here and how should I fix it?

Thanks,

Ayaz

Did you power-cycle the N210 after you updated the firmware image? The firmware is loaded at boot time into the SRAM of the FPGA.

[Discuss-gnuradio] Calling public C++ function in OOT module using Python

/* -*- c++ -*- */
/*
* Copyright 2018 <+YOU OR YOUR COMPANY+>.
*
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3, or (at your option)
* any later version.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this software; see the file COPYING. If not, write to
* the Free Software Foundation, Inc., 51 Franklin Street,
* Boston, MA 02110-1301, USA.
*/

#ifndef INCLUDED_CHAOS_CHAOTIC_PREFIX_BC_IMPL_H
#define INCLUDED_CHAOS_CHAOTIC_PREFIX_BC_IMPL_H

#include <chaos/chaotic_prefix_bc.h>

namespace gr {
namespace chaos {

class chaotic_prefix_bc_impl : public chaotic_prefix_bc
{
private:
float d_init;
float d_parameter;
unsigned int d_header_len;

// Nothing to declare in this block.

protected:
int calculate_output_stream_length(const gr_vector_int &ninput_items);

public:
chaotic_prefix_bc_impl(float init, float parameter, unsigned int header_len, const std::string &len_tag_key);
~chaotic_prefix_bc_impl();
std::vector<float> Logistic_map(float init, float parameter, unsigned int seq_len);
// Where all the action really happens
int work(int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items);
};

} // namespace chaos
} // namespace gr

#endif /* INCLUDED_CHAOS_CHAOTIC_PREFIX_BC_IMPL_H */

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include <gnuradio/io_signature.h>
#include "chaotic_prefix_bc_impl.h"

namespace gr {
namespace chaos {

chaotic_prefix_bc::sptr
chaotic_prefix_bc::make(float init, float parameter, unsigned int header_len, const std::string &len_tag_key)
{
return gnuradio::get_initial_sptr
(new chaotic_prefix_bc_impl(init, parameter, header_len, len_tag_key));
}

/*
* The private constructor
*/
chaotic_prefix_bc_impl::chaotic_prefix_bc_impl(float init, float parameter, unsigned int header_len, const std::string &len_tag_key)
: gr::tagged_stream_block("chaotic_prefix_bc",
gr::io_signature::make(1, 1, sizeof(char)),
gr::io_signature::make(1, 1, sizeof(gr_complex)), len_tag_key),
d_init(init),
d_parameter(parameter),
d_header_len(header_len)
{
set_tag_propagation_policy(TPP_DONT);// dont propagate tags
}

/*
* Our virtual destructor.
*/
chaotic_prefix_bc_impl::~chaotic_prefix_bc_impl()
{
}

std::vector<float> chaotic_prefix_bc_impl::Logistic_map(float init, float parameter, unsigned int seq_len)
{
//float parameter=3.62;
std::vector<float> chaotic_seq;
chaotic_seq.push_back(init);
float x_nn;
float sum=d_init;
for (int i=1;i<seq_len;i++)
{
x_nn=parameter*chaotic_seq[i-1]*(1-chaotic_seq[i-1]);

// x_nn=0;
sum+=x_nn;
chaotic_seq.push_back(x_nn);
}
//normalize chaotic_seq
sum=sum/seq_len;

float maxabs=0;
for (int i=0;i<seq_len;i++)
{
chaotic_seq[i]=chaotic_seq[i]-sum;
if (std::abs(chaotic_seq[i])>maxabs)
{
maxabs=std::abs(chaotic_seq[i]);
}

}

for (int i=0;i<seq_len;i++)
{
chaotic_seq[i]=chaotic_seq[i]/maxabs;

}
return chaotic_seq;

}

int
chaotic_prefix_bc_impl::calculate_output_stream_length(const gr_vector_int &ninput_items)
{
int noutput_items = d_header_len;
return noutput_items ;
}

int
chaotic_prefix_bc_impl::work (int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const char *in = (const char *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];

std::vector<float> chaotic_float=Logistic_map(d_init, d_parameter, d_header_len);
std::vector<gr_complex> chaotic_complex;
for (int i=0;i<d_header_len;i++)
{

chaotic_complex.push_back(gr_complex(chaotic_float[i],0));

}
//std::vector<gr_complex> *p=&chaotic_complex;
memcpy((void *)out,&chaotic_complex[0],d_header_len*sizeof(gr_complex));
out+=d_header_len;
// Do <+signal processing+>
noutput_items=d_header_len;
// Tell runtime system how many output items we produced.
return noutput_items;
}

} /* namespace chaos */
} /* namespace gr */

#ifndef INCLUDED_CHAOS_CHAOTIC_PREFIX_BC_H
#define INCLUDED_CHAOS_CHAOTIC_PREFIX_BC_H

#include <chaos/api.h>
#include <gnuradio/tagged_stream_block.h>

namespace gr {
namespace chaos {

/*!
* \brief <+description of block+>
* \ingroup chaos
*
*/
class CHAOS_API chaotic_prefix_bc : virtual public gr::tagged_stream_block
{
public:
typedef boost::shared_ptr<chaotic_prefix_bc> sptr;

/*!
* \brief Return a shared_ptr to a new instance of chaos::chaotic_prefix_bc.
*
* To avoid accidental use of raw pointers, chaos::chaotic_prefix_bc's
* constructor is in a private implementation
* class. chaos::chaotic_prefix_bc::make is the public interface for
* creating new instances.
*/
virtual std::vector<float> Logistic_map(float init, float parameter, unsigned int seq_len)=0;
static sptr make(float init, float parameter, unsigned int header_len, const std::string &len_tag_key);
};

} // namespace chaos
} // namespace gr

#endif /* INCLUDED_CHAOS_CHAOTIC_PREFIX_BC_H */

Hi,

I've been trying to make a function in my OOT module public. The module is called chaotic_prefix_bc.

I declare a pure virtual function called Logistic_map() in chaotic_prefix_bc.h, and overload it in chaotic_prefix_bc_impl.h and chaotic_prefix_bc_impl.cc.

When I call this function in a vector source(in GNURadio) using: chaos.chaotic_prefix_bc(0.8,3.98,50,'len_tag_key').Logistic_map(0.8,3.98,50), it says 'chaotic_prefix_bc_sptr' object has no attribute 'Logistic_map'.

I tried the make clean trick mentioned in the mailing list, but to no avail.

I attached my code below. Please help me~

Regards,

Edwin

Re: [Discuss-gnuradio] Installation error for USRP N200

Hi,

This issue is resolved after restarting the USRP device.

Thanks

Ayaz

From: Ayaz Mahmud
Sent: Tuesday, July 31, 2018 12:38 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Installation error for USRP N200

Hi,

I have already been using two USRP B210 over Gnuradio 3.7.10.1 which works perfect.

Now I am trying to bring in a N200 USRP, and installing it.

I can ping the IP 192.168.10.2/24 from my PC 192.168.10.1/24
I can also detect all the 3 devices with "uhd_find_devices"
When I run "uhd_usrp_probe" it gives error:

Please update the firmware and FPGA images for your device. See the….

Please run:

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

"/usr/local/bin/uhd_image_loader –args="type=usrp2,addr=192.168.10.2"

I have run both the above command, 1^st command says that all the targets are up to date and the 2^nd command erases and re-wrights the firmware. But then returns the same error for "uhd_usrp_probe".

Can you please let me know if I am doing anything wrong here and how should I fix it?

Thanks,

Ayaz

Re: [Discuss-gnuradio] Issue with swig in packet_headerparser block

Hi Jebreel - From the import error, it looks like either you're not linking against gr-digital library, or you're referencing some function or method or variables that doesn't exist in (isn't being exported from) the gr-digital library. Did you verify in your OOT's top-level CMakeLists.txt that when you're finding GR, you're specifying "digital" (as well as probably: runtime, blocks)? The line will be something like:

{{{

set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS DIGITAL)

}}}

To get the SWIG part working, you do need a little special SWIG sauce ... and, as you are hopefully finding, sometimes it's best to just copy from the SWIG file that does this in gr-digital & tweak it to your specific class. I'm not sure the SWIG is 100% correct, but it looks good at first reading to me.

If you continue to have errors, I'd suggest you push your GR OOT into a public repo (e.g., on GitHub) & post a link to it so that those of us who have done this before can work with actual code & thus provide real feedback instead of best guesses based on incomplete code.

Hope this is useful. - MLD

On Tue, Jul 31, 2018, at 1:15 PM, Jebreel Salem wrote:

Hello Marcus,

Thank you very much for your reply. The flag is there. However, I think the problem is with SWIG file because it does not have the correct definitions for packet_header_default. I copied the packet_header_default.cc from the ofdm gnuradio and put it in my lib directory and copied packet_header_default.h and put it in my include directory. So I did not create using gr_modtool add. I add manually all definition and paths but I am not sure if missed something. Here is my swig file with definitions I added (I changed the name of the class digitalc) but I am still getting errors.

/* -*- c++ -*- */

#define DIGITALC_API

%include "gnuradio.i" // the common stuff

//load generated python docstrings

%include "digitalc_swig_doc.i"

%{

#include "digitalc/packet_headerparser_b.h"

#include "digitalc/packet_header_default.h"

%}

%include "digitalc/packet_headerparser_b.h"

%include "digitalc/packet_header_default.h"

GR_SWIG_BLOCK_MAGIC2(digitalc, packet_headerparser_b);

%template(packet_header_default_sptr) boost::shared_ptr<gr::digitalc::packet_header_default>;

%pythoncode %{

packet_header_default_sptr.__repr__ = lambda self: "<packet_header_default>"

packet_header_default = packet_header_default .make;

%}

Here is the error I am getting:

Traceback (most recent call last):

File "/home/dev/Gnuradio_Prjs/parser/gr-digitalc/python/qa_packet_headerparser_b.py", line 32, in <module>

import digitalc.digitalc_swig as digitalc

File "/usr/local/lib/python2.7/dist-packages/digitalc/digitalc_swig.py", line 28, in <module>

_digitalc_swig = swig_import_helper()

File "/usr/local/lib/python2.7/dist-packages/digitalc/digitalc_swig.py", line 24, in swig_import_helper

_mod = imp.load_module('_digitalc_swig', fp, pathname, description)

ImportError: /home/dev/Gnuradio_Prjs/parser/gr-digitalc-debug/lib/libgnuradio-digitalc-1.0.0git.so.0.0.0: undefined symbol: _ZN2gr8digitalc21packet_header_defaultC1ElRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_i

Thanks for the help!

Regards,

Jebreel

Jebreel Salem

On Tue, Jul 31, 2018 at 4:54 AM, Müller, Marcus (CEL) <mueller@kit.edu> wrote:

Looks like your library doesn't export that symbol (in this case, the

constructor of the packet_header_default class). Did you make sure that

the class bears the SPERRY_API flag?

Best regards,

Marcus

On Mon, 2018-07-30 at 16:35 -0500, Jebreel Salem wrote:

> Hi,

> I am trying to create packet_headerparser block. The purpose is to first duplicate the block and then modify it (mostly I would like to modify the dict part). I followed the the instruction in howto tutorial but I got the error below when I tried to run the qa_packet_headerparser_b.py. I am not sure what I did wrong but I was able to duplicate demux block and make it work fine. Any hint on this is grealty appreciated.

>

>

> Traceback (most recent call last):

> File "/home/dev/Gnuradio_Prjs/parser/gr-sperry/python/qa_packet_headerparser_b.py", line 28, in <module>

> import sperry.sperry_swig as sperry

> File "/usr/local/lib/python2.7/dist-packages/sperry/sperry_swig.py", line 28, in <module>

> _sperry_swig = swig_import_helper()

> File "/usr/local/lib/python2.7/dist-packages/sperry/sperry_swig.py", line 24, in swig_import_helper

> _mod = imp.load_module('_sperry_swig', fp, pathname, description)

> ImportError: /home/dev/Gnuradio_Prjs/parser/gr-sperry-debug/lib/libgnuradio-sperry-1.0.0git.so.0.0.0: undefined symbol: _ZN2gr6sperry21packet_header_defaultC1ElRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_i

>

> Thanks!

>

> Jebreel Salem

>

> _______________________________________________

> 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] Installation error for USRP N200

Hi,

I have already been using two USRP B210 over Gnuradio 3.7.10.1 which works perfect.

Now I am trying to bring in a N200 USRP, and installing it.

I can ping the IP 192.168.10.2/24 from my PC 192.168.10.1/24
I can also detect all the 3 devices with "uhd_find_devices"
When I run "uhd_usrp_probe" it gives error:

Please update the firmware and FPGA images for your device. See the….

Please run:

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

"/usr/local/bin/uhd_image_loader –args="type=usrp2,addr=192.168.10.2"

I have run both the above command, 1^st command says that all the targets are up to date and the 2^nd command erases and re-wrights the firmware. But then returns the same error for "uhd_usrp_probe".

Can you please let me know if I am doing anything wrong here and how should I fix it?

Thanks,

Ayaz

[Discuss-gnuradio] Tagged stream block template for python?

Dear subscribers,

I just found out that you can only create general block, sync block, decimator block and interpolator block in python.

See the official manual for reference https://www.gnuradio.org/doc/doxygen/page_python_blocks.html

Is there no a tagged stream block template for python? There is a counterpart in c++.

Regards,

Edwin

Re: [Discuss-gnuradio] how to read .dat file saved via the file sink

I keep getting the error: 'read_complex_binary' not found

Where could I find this command? I started Octave from Ubuntu command window.

On Tue, Jul 31, 2018 at 1:24 PM, sumit kumar <sumitstop@gmail.com> wrote:

There is an octave script in gnuradio utilities. read_complex_binary.m
It will show you the IQ data

On Tue, 31 Jul 2018, 19:22 Linda20071, <linda20071@gmail.com> wrote:
I saved the transmitted complex signal (I/Q data) in a .dat file using the file sink. How could I read the I/Q data in this saved .dat file?

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

Re: [Discuss-gnuradio] how to read .dat file saved via the file sink

There is an octave script in gnuradio utilities. read_complex_binary.m

It will show you the IQ data

On Tue, 31 Jul 2018, 19:22 Linda20071, <linda20071@gmail.com> wrote:

I saved the transmitted complex signal (I/Q data) in a .dat file using the file sink. How could I read the I/Q data in this saved .dat file?

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

[Discuss-gnuradio] how to read .dat file saved via the file sink

I saved the transmitted complex signal (I/Q data) in a .dat file using the file sink. How could I read the I/Q data in this saved .dat file?

Thanks in advance!

Re: [Discuss-gnuradio] Issue with swig in packet_headerparser block

Hello Marcus,

Thank you very much for your reply. The flag is there. However, I think the problem is with SWIG file because it does not have the correct definitions for packet_header_default. I copied the packet_header_default.cc from the ofdm gnuradio and put it in my lib directory and copied packet_header_default.h and put it in my include directory. So I did not create using gr_modtool add. I add manually all definition and paths but I am not sure if missed something. Here is my swig file with definitions I added (I changed the name of the class digitalc) but I am still getting errors.

/* -*- c++ -*- */

#define DIGITALC_API

%include "gnuradio.i" // the common stuff

//load generated python docstrings

%include "digitalc_swig_doc.i"

#include "digitalc/packet_headerparser_b.h"

#include "digitalc/packet_header_default.h"

%include "digitalc/packet_headerparser_b.h"

%include "digitalc/packet_header_default.h"

GR_SWIG_BLOCK_MAGIC2(digitalc, packet_headerparser_b);

%template(packet_header_default_sptr) boost::shared_ptr<gr::digitalc::packet_header_default>;

%pythoncode %{

packet_header_default_sptr.__repr__ = lambda self: "<packet_header_default>"

packet_header_default = packet_header_default .make;

Here is the error I am getting:

Traceback (most recent call last):

File "/home/dev/Gnuradio_Prjs/parser/gr-digitalc/python/qa_packet_headerparser_b.py", line 32, in <module>

import digitalc.digitalc_swig as digitalc

File "/usr/local/lib/python2.7/dist-packages/digitalc/digitalc_swig.py", line 28, in <module>

_digitalc_swig = swig_import_helper()

File "/usr/local/lib/python2.7/dist-packages/digitalc/digitalc_swig.py", line 24, in swig_import_helper

_mod = imp.load_module('_digitalc_swig', fp, pathname, description)

ImportError: /home/dev/Gnuradio_Prjs/parser/gr-digitalc-debug/lib/libgnuradio-digitalc-1.0.0git.so.0.0.0: undefined symbol: _ZN2gr8digitalc21packet_header_defaultC1ElRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_i

Thanks for the help!

Regards,

Jebreel

Jebreel Salem

On Tue, Jul 31, 2018 at 4:54 AM, Müller, Marcus (CEL) <mueller@kit.edu> wrote:

Looks like your library doesn't export that symbol (in this case, the
constructor of the packet_header_default class). Did you make sure that
the class bears the SPERRY_API flag?

Best regards,
Marcus

On Mon, 2018-07-30 at 16:35 -0500, Jebreel Salem wrote:
> Hi,
> I am trying to create packet_headerparser block. The purpose is to first duplicate the block and then modify it (mostly I would like to modify the dict part). I followed the the instruction in howto tutorial but I got the error below when I tried to run the qa_packet_headerparser_b.py. I am not sure what I did wrong but I was able to duplicate demux block and make it work fine. Any hint on this is grealty appreciated.
>
>
> Traceback (most recent call last):
> File "/home/dev/Gnuradio_Prjs/parser/gr-sperry/python/qa_packet_headerparser_b.py", line 28, in <module>
> import sperry.sperry_swig as sperry
> File "/usr/local/lib/python2.7/dist-packages/sperry/sperry_swig.py", line 28, in <module>
> _sperry_swig = swig_import_helper()
> File "/usr/local/lib/python2.7/dist-packages/sperry/sperry_swig.py", line 24, in swig_import_helper
> _mod = imp.load_module('_sperry_swig', fp, pathname, description)
> ImportError: /home/dev/Gnuradio_Prjs/parser/gr-sperry-debug/lib/libgnuradio-sperry-1.0.0git.so.0.0.0: undefined symbol: _ZN2gr6sperry21packet_header_defaultC1ElRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_i
>
> Thanks!
>
> Jebreel Salem
>

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

Re: [Discuss-gnuradio] _uhd_swig.so: undefined symbol

Most likely problem is that you've built GNU Radio against a different
version of UHD than you've got installed.

best regards,
Marcus

On Tue, 2018-07-31 at 14:36 +0200, Savino Piccolomo wrote:
> Hi members of the GNURadio Discussion List,
>
> I am using an USRP x310 and installed gnuradio/uhd using the script by Marcus Leech but then faced a problem (already reported by my college Nicolas Ballard) by which the only subdev specifications working are AB and BA but not A and B separately.
>
> I follow the instructions already reported in Nicolas thread and installed the script with option -ut release_003_009_007
> Even though this solution seemed to work for him it did not on my computer as I receive the following error when I do 'from gnuradio import uhd'
>
> ImportError: /usr/local/lib/python2.7/dist-packages/gnuradio/uhd/_uhd_swig.so: undefined symbol: _ZN3uhd4usrp10multi_usrp7ALL_LOSB5cxx11E
>
> Any help?
>
> Thanks in advance for your time.
> Regards,
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] _uhd_swig.so: undefined symbol

Hi members of the GNURadio Discussion List,

I am using an USRP x310 and installed gnuradio/uhd using the script by Marcus Leech but then faced a problem (already reported by my college Nicolas Ballard) by which the only subdev specifications working are AB and BA but not A and B separately.

I follow the instructions already reported in Nicolas thread and installed the script with option -ut release_003_009_007

Even though this solution seemed to work for him it did not on my computer as I receive the following error when I do 'from gnuradio import uhd'

ImportError: /usr/local/lib/python2.7/dist-packages/gnuradio/uhd/_uhd_swig.so: undefined symbol: _ZN3uhd4usrp10multi_usrp7ALL_LOSB5cxx11E

Any help?

Thanks in advance for your time.

Regards,

- Savino

Re: [Discuss-gnuradio] Dynamically changing bandwidth of QT GUI Frequency Sink

Hi Jason,

I'd recommend adding a command to the message port to update the sample rate or alternatively add support for the rate tag to the Frequency Sink and have your OOT block emit a rate tag. I'll help get that change merged if you can put up a pull request.
https://github.com/gnuradio/gnuradio/blob/219eae9a9c2ef7644450e71d19f8f54c12e1f9cc/gr-uhd/lib/usrp_source_impl.cc#L673
https://github.com/gnuradio/gnuradio/blob/a0adcd3347c7ffd6ef3c42ce7705a23978774d3b/gr-uhd/lib/usrp_source_impl.h#L29

Derek

On Tue, Jul 31, 2018 at 12:24 PM, Jason Hein <jason.hein@marconiedison.com> wrote:

Marcus,

To clarify, assume I set the sample rate at build time with the samp_rate variable within the QT GUI Frequency Sink. At run time, the bandwidth (x axis) is reflective of this samp_rate. However, if I have a source block upstream that changes the sample rate via out of band means, I would like that source block to change the samp_rate of the QT GUI Frequency Sink programmatically. I am able to change the frequency of the QT GUI Frequency Sink programmatically through the message port, but I haven't seen a way to change the samp_rate/bandwidth.

Jason

On Tue, Jul 31, 2018 at 5:56 AM, Müller, Marcus (CEL) <mueller@kit.edu> wrote:
Hi Jason,
just to be sure to understand what you need:
Do you mean "zoom in x-axis"?
(because technically, the bandwidth of that display is always Nyquist,
i.e. defined by the sampling rate)

Best regards,
Marcus

On Mon, 2018-07-30 at 16:57 -0400, Jason Hein wrote:
> I have a GNU radio flow graph with a custom data source and I'd like to be able to change the bandwidth displayed on the QT GUI Frequency Sink block dynamically. Is there a way to do this programmatically? The QT GUI Frequency Sink block has a message port for programmatic changes to frequency, but I don't see an equivalent means for changing bandwidth. Is there a way for an OOT block to get a reference to another block to call a public member function?

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

Re: [Discuss-gnuradio] Dynamically changing bandwidth of QT GUI Frequency Sink

Marcus,

To clarify, assume I set the sample rate at build time with the samp_rate variable within the QT GUI Frequency Sink. At run time, the bandwidth (x axis) is reflective of this samp_rate. However, if I have a source block upstream that changes the sample rate via out of band means, I would like that source block to change the samp_rate of the QT GUI Frequency Sink programmatically. I am able to change the frequency of the QT GUI Frequency Sink programmatically through the message port, but I haven't seen a way to change the samp_rate/bandwidth.

Jason

On Tue, Jul 31, 2018 at 5:56 AM, Müller, Marcus (CEL) <mueller@kit.edu> wrote:

Hi Jason,
just to be sure to understand what you need:
Do you mean "zoom in x-axis"?
(because technically, the bandwidth of that display is always Nyquist,
i.e. defined by the sampling rate)

Best regards,
Marcus

On Mon, 2018-07-30 at 16:57 -0400, Jason Hein wrote:
> I have a GNU radio flow graph with a custom data source and I'd like to be able to change the bandwidth displayed on the QT GUI Frequency Sink block dynamically. Is there a way to do this programmatically? The QT GUI Frequency Sink block has a message port for programmatic changes to frequency, but I don't see an equivalent means for changing bandwidth. Is there a way for an OOT block to get a reference to another block to call a public member function?

Re: [Discuss-gnuradio] Dynamically changing bandwidth of QT GUI Frequency Sink

You could put a resampling block in front of the QT GUI source or add on to the message handling to support setting the X and Y axis limits. I think that would be a useful addition, the Y axis limits already have callbacks exposed to GRC but not via messages.

Regards,

Derek

On Tue, Jul 31, 2018 at 10:56 AM, Müller, Marcus (CEL) <mueller@kit.edu> wrote:

Hi Jason,
just to be sure to understand what you need:
Do you mean "zoom in x-axis"?
(because technically, the bandwidth of that display is always Nyquist,
i.e. defined by the sampling rate)

Best regards,
Marcus

On Mon, 2018-07-30 at 16:57 -0400, Jason Hein wrote:
> I have a GNU radio flow graph with a custom data source and I'd like to be able to change the bandwidth displayed on the QT GUI Frequency Sink block dynamically. Is there a way to do this programmatically? The QT GUI Frequency Sink block has a message port for programmatic changes to frequency, but I don't see an equivalent means for changing bandwidth. Is there a way for an OOT block to get a reference to another block to call a public member function?

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

Re: [Discuss-gnuradio] Dynamically changing bandwidth of QT GUI Frequency Sink

Hi Jason,
just to be sure to understand what you need:
Do you mean "zoom in x-axis"?
(because technically, the bandwidth of that display is always Nyquist,
i.e. defined by the sampling rate)

Best regards,
Marcus

On Mon, 2018-07-30 at 16:57 -0400, Jason Hein wrote:
> I have a GNU radio flow graph with a custom data source and I'd like to be able to change the bandwidth displayed on the QT GUI Frequency Sink block dynamically. Is there a way to do this programmatically? The QT GUI Frequency Sink block has a message port for programmatic changes to frequency, but I don't see an equivalent means for changing bandwidth. Is there a way for an OOT block to get a reference to another block to call a public member function?

Re: [Discuss-gnuradio] Issue with swig in packet_headerparser block

Looks like your library doesn't export that symbol (in this case, the
constructor of the packet_header_default class). Did you make sure that
the class bears the SPERRY_API flag?

Best regards,
Marcus

On Mon, 2018-07-30 at 16:35 -0500, Jebreel Salem wrote:
> Hi,
> I am trying to create packet_headerparser block. The purpose is to first duplicate the block and then modify it (mostly I would like to modify the dict part). I followed the the instruction in howto tutorial but I got the error below when I tried to run the qa_packet_headerparser_b.py. I am not sure what I did wrong but I was able to duplicate demux block and make it work fine. Any hint on this is grealty appreciated.
>
>
> Traceback (most recent call last):
> File "/home/dev/Gnuradio_Prjs/parser/gr-sperry/python/qa_packet_headerparser_b.py", line 28, in <module>
> import sperry.sperry_swig as sperry
> File "/usr/local/lib/python2.7/dist-packages/sperry/sperry_swig.py", line 28, in <module>
> _sperry_swig = swig_import_helper()
> File "/usr/local/lib/python2.7/dist-packages/sperry/sperry_swig.py", line 24, in swig_import_helper
> _mod = imp.load_module('_sperry_swig', fp, pathname, description)
> ImportError: /home/dev/Gnuradio_Prjs/parser/gr-sperry-debug/lib/libgnuradio-sperry-1.0.0git.so.0.0.0: undefined symbol: _ZN2gr6sperry21packet_header_defaultC1ElRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_i
>
> Thanks!
>
> Jebreel Salem
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Monday, July 30, 2018

Re: [Discuss-gnuradio] OOT sourcec block in python error

Hello Ayaz,

If you are getting 'Template error' messages, you will have to check the XML file of your block (in grc directory).

Also, 'input' is not a valid variable name in Python, as it is used for other purposes. You will have to re-name that variable to something else.

Finally, "out[0][:] = self.input" should become "out[:] = self.input" as you already selected output port and you are not outputting vectors.

Regards,

Kyeong Su Shin

보낸 사람: Ayaz Mahmud <ayazmahmud@hotmail.com> 대신 Discuss-gnuradio <discuss-gnuradio-bounces+ksshin=postech.ac.kr@gnu.org>
보낸 날짜: 2018년 7월 31일 화요일 오전 2:22:35
받는 사람: discuss-gnuradio@gnu.org
제목: [Discuss-gnuradio] OOT sourcec block in python error

Hi,

I am trying to build a source block in python. Below is my code. After using the block I am getting a syntax error: self.Span_SourceBlock_0 = Template error: Span.SourceBlock($input)

My block should take input from user(int/float), and output the same. Though these are available blocks in GnuRadio but I am trying to learn on building it. Can you please check if my way of writing the code is correct?

import numpy

from gnuradio import gr

class SourceBlock(gr.sync_block):

"""

docstring for block SourceBlock

"""

def __init__(self, input):

self.input = input

gr.sync_block.__init__(self,

name="SourceBlock",

in_sig=None,

out_sig=[numpy.float32])

def work(self, input_items, output_items):

out = output_items[0]

out[0][:] = self.input

return len(output_items[0])

Thanks,

Ayaz

[Discuss-gnuradio] Issue with swig in packet_headerparser block

Hi,

I am trying to create packet_headerparser block. The purpose is to first duplicate the block and then modify it (mostly I would like to modify the dict part). I followed the the instruction in howto tutorial but I got the error below when I tried to run the qa_packet_headerparser_b.py. I am not sure what I did wrong but I was able to duplicate demux block and make it work fine. Any hint on this is grealty appreciated.

Traceback (most recent call last):

File "/home/dev/Gnuradio_Prjs/parser/gr-sperry/python/qa_packet_headerparser_b.py", line 28, in <module>

import sperry.sperry_swig as sperry

File "/usr/local/lib/python2.7/dist-packages/sperry/sperry_swig.py", line 28, in <module>

_sperry_swig = swig_import_helper()

File "/usr/local/lib/python2.7/dist-packages/sperry/sperry_swig.py", line 24, in swig_import_helper

_mod = imp.load_module('_sperry_swig', fp, pathname, description)

ImportError: /home/dev/Gnuradio_Prjs/parser/gr-sperry-debug/lib/libgnuradio-sperry-1.0.0git.so.0.0.0: undefined symbol: _ZN2gr6sperry21packet_header_defaultC1ElRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_i

Thanks!

Jebreel Salem

[Discuss-gnuradio] Dynamically changing bandwidth of QT GUI Frequency Sink

I have a GNU radio flow graph with a custom data source and I'd like to be able to change the bandwidth displayed on the QT GUI Frequency Sink block dynamically. Is there a way to do this programmatically? The QT GUI Frequency Sink block has a message port for programmatic changes to frequency, but I don't see an equivalent means for changing bandwidth. Is there a way for an OOT block to get a reference to another block to call a public member function?

Jason

[Discuss-gnuradio] OOT sourcec block in python error

Hi,

I am trying to build a source block in python. Below is my code. After using the block I am getting a syntax error: self.Span_SourceBlock_0 = Template error: Span.SourceBlock($input)

import numpy

from gnuradio import gr

class SourceBlock(gr.sync_block):

"""

docstring for block SourceBlock

"""

def __init__(self, input):

self.input = input

gr.sync_block.__init__(self,

name="SourceBlock",

in_sig=None,

out_sig=[numpy.float32])

def work(self, input_items, output_items):

out = output_items[0]

out[0][:] = self.input

return len(output_items[0])

Thanks,

Ayaz

Re: [Discuss-gnuradio] Ettus X310 FPGA Compatibility Number

Hello YJ,

Each version of UHD knows where to download the correct matching FPGA image. What has most likely happened is that when you installed the new UHD you did not also rebuild GNU Radio. Is it possible that you did not install the newer UHD? normally it would overwrite the older UHD and you would actually see a different error where GNU Radio recognizes that UHD has been updated and that GNU Radio needs to be rebuilt.

After you have GNU Radio using the version of UHD that you want, then follow the instructions from the error message to download the matching FPGA image and load it onto the X310.

"Please run:

"/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"

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

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

On Mon, Jul 30, 2018 at 10:35 AM, Zhan Yanjun <ZYanjun@dso.org.sg> wrote:

Hello,

I am relatively new to the SDR scene, and I have set up the UHD and X310 drivers in my computer. I used gnuradio-companion to create a simple flowchart to test the receiving and recording of signals, and I came across this error:

-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
Traceback (most recent call last):
File "/home/user/Desktop/ZYJ X310 files/top_block.py", line 340, in <module>
    main()
File "/home/user/Desktop/ZYJ X310 files/top_block.py", line 328, in main
    tb = top_block_cls()
File "/home/user/Desktop/ZYJ X310 files/top_block.py", line 106, in __init__
    channels=range(4),
File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 122, in constructor_interceptor
    return old_constructor(*args)
File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 2683, in make
    return _uhd_swig.usrp_source_make(*args)
RuntimeError: RuntimeError: Expected FPGA compatibility number 33, but got 35:
The FPGA image on your device is not compatible with this host code build.
Download the appropriate FPGA images for this version of UHD.
Please run:

"/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"

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

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

For more information, refer to the UHD manual:

http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_flash

According to this line:

RuntimeError: RuntimeError: Expected FPGA compatibility number 33, but got 35:

This means that the UHD version, which I installed to be 3.10.3.0, is expecting an FPGA version lower than that flashed in the X310. As a result, I installed the latest UHD version 3.13.0.0, and tried it again. However, the same error was shown. This seems very strange, as now the newest UHD version expects an older FPGA image version.

Please correct me if I misinterpret the error message.

Please advise me on this matter, what should I do in this scenario? The X310 is not mine, and I cannot just flash another FPGA version into the hardware.

Is there a list of corresponding FPGA compatibility numbers with the matching UHD versions? This may help me to troubleshoot and match the FPGA image with the correct UHD version.

Thanks in advance,

YJ

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

Re: [Discuss-gnuradio] Ettus X310 FPGA Compatibility Number

On 07/30/2018 05:35 AM, Zhan Yanjun wrote:

Hello,

I am relatively new to the SDR scene, and I have set up the UHD and X310 drivers in my computer. I used gnuradio-companion to create a simple flowchart to test the receiving and recording of signals, and I came across this error:

-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
Traceback (most recent call last):
File "/home/user/Desktop/ZYJ X310 files/top_block.py", line 340, in <module>
    main()
File "/home/user/Desktop/ZYJ X310 files/top_block.py", line 328, in main
    tb = top_block_cls()
File "/home/user/Desktop/ZYJ X310 files/top_block.py", line 106, in __init__
    channels=range(4),
File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 122, in constructor_interceptor
    return old_constructor(*args)
File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 2683, in make
    return _uhd_swig.usrp_source_make(*args)
RuntimeError: RuntimeError: Expected FPGA compatibility number 33, but got 35:
The FPGA image on your device is not compatible with this host code build.
Download the appropriate FPGA images for this version of UHD.
Please run:

"/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"

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

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

For more information, refer to the UHD manual:

http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_flash

According to this line:

RuntimeError: RuntimeError: Expected FPGA compatibility number 33, but got 35:

This means that the UHD version, which I installed to be 3.10.3.0, is expecting an FPGA version lower than that flashed in the X310. As a result, I installed the latest UHD version 3.13.0.0, and tried it again. However, the same error was shown. This seems very strange, as now the newest UHD version expects an older FPGA image version.

Please correct me if I misinterpret the error message.

Please advise me on this matter, what should I do in this scenario? The X310 is not mine, and I cannot just flash another FPGA version into the hardware.

Is there a list of corresponding FPGA compatibility numbers with the matching UHD versions? This may help me to troubleshoot and match the FPGA image with the correct UHD version.

Thanks in advance,

YJ

I would confirm that you're actually running 3.13 and not the older 3.10.

What does the output look like when you run uhd_usrp_probe -- is it showing 3.13?