Re: [Discuss-gnuradio] Problem with "TCP Source" module in the client mode

[Martin Braun]

On 03.03.2014 17:57, Igor Volodin wrote:

Hi all!

I am trying to build following simple scheme:

Signal source --> TCP Sink (server mode)  < TCP Source (client mode)
--> GUI Scope Sink

It's strange but this simple scheme isn't working.


Are you running both sub-flowgraphs in the same GRC canvas? I just tried 
this in 2 canvases and it works. It *should* work from one, but I'm not 
sure GRC is setting things up right.


In any case, try 2 canvases.

M



sockstat shows me:

USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS
igor python2.7  56206 11 tcp4   10.21.32.6:21950 10.21.32.6:12000

Looks like communication between tcp sink and tcp source blocks has been
established, but tcpdump doesn't show any packets

I decided to check first part of my scheme (Signal source + TCP Sink),
and connected using netcat utility to the tcp sink port. All looks OK,
the values come as expected.

Can anybody explain, why this simple scheme doesn't work?


Best regards,
Igor




___
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] Using both antennas of USRP as Receivers

[Sumedha Goyal]

Is it possible to use both the antennas of USRP as receive antennas? For
example TX/RX should work on frequency f1 as a receive antenna and RX2
should work on frequency f2 as another receive antenna. Also, USRP should
be able to collect data from both the antennas simultaneously. How can I
approach this problem

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

Re: [Discuss-gnuradio] FFTW3 runtime error

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Activecat,

your sourcecode should be fine - what you see is an error that tells
you that at runtime, a symbol could not be found. This means that the
fftw library has not been linked against.
On 2014-02-26 there was a thread on discuss-gnuradio with the subject
"Link FFTW3 in OOT module" featuring Sabathy Mischa and me, could you
please look into the mailing list archive; the solution to your
problem should be there :)

Happy hacking,
Marcus

On 04.03.2014 07:27, Activecat wrote:
> The implementation header file is as below:
> 
> 
> #ifndef INCLUDED_ACTIVECAT_FFT1_IMPL_H #define
> INCLUDED_ACTIVECAT_FFT1_IMPL_H
> 
> #include  #include 
> 
> namespace gr { namespace activecat {
> 
> class fft1_impl : public fft1 { private: int d_N; int d_direction; 
> int d_shift;
> 
> fftw_complex *d_input; fftw_plan d_plan;
> 
> public: fft1_impl(int fft_size, int direction, bool fft_shift); 
> ~fft1_impl();
> 
> int work( int noutput_items, gr_vector_const_void_star
> &input_items, gr_vector_void_star &output_items); };
> 
> } // namespace activecat } // namespace gr
> 
> #endif /* INCLUDED_ACTIVECAT_FFT1_IMPL_H */
> 
> 
> 
> On Tue, Mar 4, 2014 at 1:55 PM, Activecat 
> wrote:
> 
>> Dear Sir,
>> 
>> I am trying to build a custom block with FFT capability. I use
>> FFTW3, the FFT stuff runs well as a standalone program before 
>> integrating into gnuradio.
>> 
>> Then I integrate the FFT function into the block, it compiles
>> without any error. But when I run the flow graph in GRC, it
>> produces following error message.
>> 
>> Generating: "/home/sgku/gnuradio/flow_graphs/top_block.py" 
>> Executing: "/home/sgku/gnuradio/flow_graphs/top_block.py" 
>> Traceback (most recent call last): File
>> "/home/sgku/gnuradio/flow_graphs/top_block.py", line 18, in 
>>  import activecat File 
>> "/usr/local/lib/python2.7/dist-packages/activecat/__init__.py",
>> line 45, in  from activecat_swig import * File 
>> "/usr/local/lib/python2.7/dist-packages/activecat/activecat_swig.py",
>> line 26, in  _activecat_swig = swig_import_helper() File 
>> "/usr/local/lib/python2.7/dist-packages/activecat/activecat_swig.py",
>> line 22, in swig_import_helper _mod =
>> imp.load_module('_activecat_swig', fp, pathname, description) 
>> ImportError: /usr/local/lib/libgnuradio-activecat.so: undefined 
>> symbol: fftw_plan_dft_1d
> Done
>> 
>> 
>> Below is the implmentation source file:
>> 
>> 
>> namespace gr { namespace activecat {
>> 
>> fft1::sptr fft1::make(int fft_size, int direction, bool
>> fft_shift) { return gnuradio::get_initial_sptr (new
>> fft1_impl(fft_size, direction, fft_shift)); }
>> 
>> // constructor fft1_impl::fft1_impl(int fft_size, int direction,
>> bool fft_shift) : gr::sync_block("fft1", gr::io_signature::make(
>> 1, 1, sizeof(gr_complex)), gr::io_signature::make( 1, 1, 
>> sizeof(gr_complex))), d_N(fft_size), d_direction(direction), 
>> d_shift(fft_shift) { d_input = (fftw_complex*) fftw_malloc( 
>> sizeof(fftw_complex) * d_N ); d_plan  = fftw_plan_dft_1d( d_N,
>> d_input, d_input, FFTW_BACKWARD, FFTW_ESTIMATE );  // later
>> change FFTW_BACKWARD to d_direction
>> 
>> set_output_multiple( d_N ); set_min_noutput_items( d_N ); }
>> 
>> // destructor fft1_impl::~fft1_impl() { }
>> 
>> int fft1_impl::work( int noutput_items, gr_vector_const_void_star
>> &input_items, gr_vector_void_star &output_items) { const
>> gr_complex  *in  =  (const gr_complex *) input_items[0]; 
>> gr_complex*out =  (gr_complex *) output_items[0];
>> 
>> for (int i=0; i < noutput_items; i++) { d_input[i][0] =
>> in[i].real(); d_input[i][1] = in[i].imag(); }
>> 
>> fftw_execute( d_plan );
>> 
>> for (int i=0; i < noutput_items; i++) { out[i].real(
>> d_input[i][0] ); out[i].imag( d_input[i][1] ); }
>> 
>> 
>> return noutput_items; } } /* namespace activecat */ } /*
>> namespace gr */
>> 
>> 
>> 
>> Question: How to solve this error ?
>> 
>> Regards, Activecat active...@gmail.com
>> 
> 
> 
> 
> ___ 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/

iQEcBAEBAgAGBQJTFaQQAAoJEBQ6EdjyzlHtjCcH/1cqqf9PSSAc5FmNIH45I6Uy
0A7/Rhqb5nwjBjVlRe0UXrVk7EAAK/PwDQgliMw8oZ+5KuqhqVfFtx3Vch9Rs75a
Hmprl8fEDanKyfVa0cKyhmJCyuRFE29R8XxdAt07HalJqh1clhXOo6vkoZTQeDmh
gm2NOflIdEtWk2kggo92Ii23El8xbQeWhaM1/OXTyqOR7d+V6U4aF6BwirJ4oPos
uOXfKxteqjetMhIm50FClQyKpS/gRLIvhhVz3P2Yc2tJM8GlLvH0gP+5M1MeKh5j
yJTbYzbHByFsAIT39zyFDrmz5FU1+pbwSKe0dLM1/HrclZHSkiW2dWREx7UYEHg=
=clWo
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] FFTW3 runtime error

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry, forgot to mention: additionally to the solution in my answer to
Sabathy,
add ${FFTW3(F)_LIBRARIES} to your lib/CMakeLists.txt
target_link_libraries, also add: link_directories(${FFTW3F_LIBRARY_DIRS})

Greetings,
Marcus

On 04.03.2014 10:59, Marcus Müller wrote:
> Hi Activecat,
> 
> your sourcecode should be fine - what you see is an error that
> tells you that at runtime, a symbol could not be found. This means
> that the fftw library has not been linked against. On 2014-02-26
> there was a thread on discuss-gnuradio with the subject "Link FFTW3
> in OOT module" featuring Sabathy Mischa and me, could you please
> look into the mailing list archive; the solution to your problem
> should be there :)
> 
> Happy hacking, Marcus
> 
> On 04.03.2014 07:27, Activecat wrote:
>> The implementation header file is as below:
> 
> 
>> #ifndef INCLUDED_ACTIVECAT_FFT1_IMPL_H #define 
>> INCLUDED_ACTIVECAT_FFT1_IMPL_H
> 
>> #include  #include 
> 
>> namespace gr { namespace activecat {
> 
>> class fft1_impl : public fft1 { private: int d_N; int
>> d_direction; int d_shift;
> 
>> fftw_complex *d_input; fftw_plan d_plan;
> 
>> public: fft1_impl(int fft_size, int direction, bool fft_shift); 
>> ~fft1_impl();
> 
>> int work( int noutput_items, gr_vector_const_void_star 
>> &input_items, gr_vector_void_star &output_items); };
> 
>> } // namespace activecat } // namespace gr
> 
>> #endif /* INCLUDED_ACTIVECAT_FFT1_IMPL_H */
> 
> 
> 
>> On Tue, Mar 4, 2014 at 1:55 PM, Activecat  
>> wrote:
> 
>>> Dear Sir,
>>> 
>>> I am trying to build a custom block with FFT capability. I use 
>>> FFTW3, the FFT stuff runs well as a standalone program before 
>>> integrating into gnuradio.
>>> 
>>> Then I integrate the FFT function into the block, it compiles 
>>> without any error. But when I run the flow graph in GRC, it 
>>> produces following error message.
>>> 
>>> Generating: "/home/sgku/gnuradio/flow_graphs/top_block.py" 
>>> Executing: "/home/sgku/gnuradio/flow_graphs/top_block.py" 
>>> Traceback (most recent call last): File 
>>> "/home/sgku/gnuradio/flow_graphs/top_block.py", line 18, in 
>>>  import activecat File 
>>> "/usr/local/lib/python2.7/dist-packages/activecat/__init__.py",
>>>
>>> 
line 45, in  from activecat_swig import * File
>>> "/usr/local/lib/python2.7/dist-packages/activecat/activecat_swig.py",
>>>
>>> 
line 26, in  _activecat_swig = swig_import_helper() File
>>> "/usr/local/lib/python2.7/dist-packages/activecat/activecat_swig.py",
>>>
>>> 
line 22, in swig_import_helper _mod =
>>> imp.load_module('_activecat_swig', fp, pathname, description) 
>>> ImportError: /usr/local/lib/libgnuradio-activecat.so: undefined
>>>  symbol: fftw_plan_dft_1d
>> Done
>>> 
>>> 
>>> Below is the implmentation source file:
>>> 
>>> 
>>> namespace gr { namespace activecat {
>>> 
>>> fft1::sptr fft1::make(int fft_size, int direction, bool 
>>> fft_shift) { return gnuradio::get_initial_sptr (new 
>>> fft1_impl(fft_size, direction, fft_shift)); }
>>> 
>>> // constructor fft1_impl::fft1_impl(int fft_size, int
>>> direction, bool fft_shift) : gr::sync_block("fft1",
>>> gr::io_signature::make( 1, 1, sizeof(gr_complex)),
>>> gr::io_signature::make( 1, 1, sizeof(gr_complex))),
>>> d_N(fft_size), d_direction(direction), d_shift(fft_shift) {
>>> d_input = (fftw_complex*) fftw_malloc( sizeof(fftw_complex) *
>>> d_N ); d_plan  = fftw_plan_dft_1d( d_N, d_input, d_input,
>>> FFTW_BACKWARD, FFTW_ESTIMATE );  // later change FFTW_BACKWARD
>>> to d_direction
>>> 
>>> set_output_multiple( d_N ); set_min_noutput_items( d_N ); }
>>> 
>>> // destructor fft1_impl::~fft1_impl() { }
>>> 
>>> int fft1_impl::work( int noutput_items,
>>> gr_vector_const_void_star &input_items, gr_vector_void_star
>>> &output_items) { const gr_complex  *in  =  (const gr_complex *)
>>> input_items[0]; gr_complex*out =  (gr_complex *)
>>> output_items[0];
>>> 
>>> for (int i=0; i < noutput_items; i++) { d_input[i][0] = 
>>> in[i].real(); d_input[i][1] = in[i].imag(); }
>>> 
>>> fftw_execute( d_plan );
>>> 
>>> for (int i=0; i < noutput_items; i++) { out[i].real( 
>>> d_input[i][0] ); out[i].imag( d_input[i][1] ); }
>>> 
>>> 
>>> return noutput_items; } } /* namespace activecat */ } /* 
>>> namespace gr */
>>> 
>>> 
>>> 
>>> Question: How to solve this error ?
>>> 
>>> Regards, Activecat active...@gmail.com
>>> 
> 
> 
> 
>> ___ Discuss-gnuradio 
>> mailing list Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTFaSgAAoJEBQ6EdjyzlHtj2gIAIIt8PS8OpbpatPGFr6yAWob
IDYN3HfhJ23juTkTW75U8oKCW+TPCFSCjUx/0tWdamBELEJUAm48mx8ZqP/ZQUbS
ry6MvIFOhAIJbBgFY7RewLG

Re: [Discuss-gnuradio] Fwd: New Defects reported by Coverity Scan for GNURadio

[Philip Balister]

On 03/03/2014 05:00 PM, Tom Rondeau wrote:
> On Mon, Mar 3, 2014 at 4:58 PM, Philip Balister  wrote:
>> The latest Coverity scan showed these new items. We should probably
>> double check them. The Null dereference is likely related to the order
>> in which some class methods get called.
>>
>> The compare against zero of an unsigned number should be checked to make
>> sure that is what was really meant.
>>
>> Philip
> 
> Too late. I already pushed fixes for these and updated Coverity.
> 
> I noticed the defect emails and it's related to code I just pushed
> this weekend, so it was easy enough for me to get them while they were
> fresh in my mind.
> 
> Thanks for keeping on top of this, though.

Thanks. I figured some visibility would encourage more people to pay
attention to Coverity.

You can sign up for Soverity at https://scan.coverity.com/ and then
request access to the GNU Radio reports. It's a great way to learn about
some interesting coding errors.

While things like comparing unsigned ints with 0 may seem trivial, they
can be pointers to actual bugs.

Philip

> 
> Tom
> 
> 
> 
>> ** CID 1189412:  Explicit null dereferenced  (FORWARD_NULL)
>> /var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/fft_filter.cc:
>> 355 in gr::filter::kernel::fft_filter_ccf::fft_filter_ccf(int, const
>> std::vector> &, int)()
>>
>> ** CID 1189413:  Unsigned compared against 0  (NO_EFFECT)
>> /var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/pfb_synthesizer_ccf_impl.cc:
>> 225 in gr::filter::pfb_synthesizer_ccf_impl::set_channel_map(const
>> std::vector> &)()
>>
>>
>> 
>> *** CID 1189412:  Explicit null dereferenced  (FORWARD_NULL)
>> /var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/fft_filter.cc:
>> 355 in gr::filter::kernel::fft_filter_ccf::fft_filter_ccf(int, const
>> std::vector> &, int)()
>> 349
>> /**/
>> 350
>> 351
>> 352   fft_filter_ccf::fft_filter_ccf(int decimation,
>> 353  const std::vector &taps,
>> 354  int nthreads)
> CID 1189412:  Explicit null dereferenced  (FORWARD_NULL)
> Assigning: "this->d_fwdfft" = "NULL".
>> 355 : d_fftsize(-1), d_decimation(decimation), d_fwdfft(0),
>> 356   d_invfft(0), d_nthreads(nthreads), d_xformed_taps(NULL)
>> 357   {
>> 358 set_taps(taps);
>> 359   }
>> 360
>>
>> 
>> *** CID 1189413:  Unsigned compared against 0  (NO_EFFECT)
>> /var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/pfb_synthesizer_ccf_impl.cc:
>> 225 in gr::filter::pfb_synthesizer_ccf_impl::set_channel_map(const
>> std::vector> &)()
>> 219 {
>> 220   gr::thread::scoped_lock guard(d_mutex);
>> 221
>> 222   if(map.size() > 0) {
>> 223 unsigned int max = (unsigned
>> int)*std::max_element(map.begin(), map.end());
>> 224 unsigned int min = (unsigned
>> int)*std::min_element(map.begin(), map.end());
> CID 1189413:  Unsigned compared against 0  (NO_EFFECT)
> This less-than-zero comparison of an unsigned value is never true. 
> "min < 0U".
>> 225 if((max >= d_twox*d_numchans) || (min < 0)) {
>> 226   throw
>> std::invalid_argument("pfb_synthesizer_ccf_impl::set_channel_map: map
>> range out of bounds.\n");
>> 227 }
>> 228 d_channel_map = map;
>> 229
>> 230 // Zero out fft buffer so that unused channels are always 0
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

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

Re: [Discuss-gnuradio] Using both antennas of USRP as Receivers

[Marcus D. Leech]

On 03/04/2014 02:31 AM, Sumedha Goyal wrote:
Is it possible to use both the antennas of USRP as receive antennas? 
For example TX/RX should work on frequency f1 as a receive antenna and 
RX2 should work on frequency f2 as another receive antenna. Also, USRP 
should be able to collect data from both the antennas simultaneously. 
How can I approach this problem


Thanks and Regards,
Sumedha


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
There's only a single receive chain.  The receive chain is *switched* 
between antennas, that's all.



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

Re: [Discuss-gnuradio] The GMSK demodulation

[Perper]

> Hi Perper,
>
> I took a look at your code, and I found this
>
> //set_frequency(d_freq_offset);  
>
> It seems you have turned off the the frequency offset correction as
> you said.
> Do you know the reason of the introduced instability by this part? 
>
> Best,
> Zhenhua
Hi Zhenhua,

The reason of instability is in the method of correction of the
frequency offset.

The offset is computed inside of gsm-receiver gnuradio block and it is
fed to a frequency shifting fir filter.

The connection of the blocks look like this:

 __freq. offset_
||
v   |
xlating_fir_filter -> gsm-receiver

There is lact of synchronization between computation of frequency offset
and its correction inside of xlating_fir_filter. Synchronisation in this
case is needed because the moment of computation of the estimate affects it.
When new estimate of frequency correction is computed before previous is
applied the connection with frequency offset becomes additive feedback loop.

This problem can be corrected by integration frequency correction inside
of the gsm-receiver or with use of stream tags.

Generally I would like to split gr-gsm into smaller blocks that are
easier to test but it will happen only if I find enough time for this.

P.S. for some reason I didn't get your reply through my mailing list
subscription (together with many more missing messages)...
I've found it through the webpage
lists.gnu.org/archive/html/discuss-gnuradio/ .

--
Best Regards,
Piotr Krysik

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

Re: [Discuss-gnuradio] FFTW3 runtime error

[Activecat]

Dear Marcus,

Thank you very much.
As according to your guideline, the runtime error has been solved.
With some minor modification to the work() function, now the flow graph
executes without any error.

Cheers,
Activecat




On Tue, Mar 4, 2014 at 6:02 PM, Marcus Müller  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Sorry, forgot to mention: additionally to the solution in my answer to
> Sabathy,
> add ${FFTW3(F)_LIBRARIES} to your lib/CMakeLists.txt
> target_link_libraries, also add: link_directories(${FFTW3F_LIBRARY_DIRS})
>
> Greetings,
> Marcus
>
> On 04.03.2014 10:59, Marcus Müller wrote:
> > Hi Activecat,
> >
> > your sourcecode should be fine - what you see is an error that
> > tells you that at runtime, a symbol could not be found. This means
> > that the fftw library has not been linked against. On 2014-02-26
> > there was a thread on discuss-gnuradio with the subject "Link FFTW3
> > in OOT module" featuring Sabathy Mischa and me, could you please
> > look into the mailing list archive; the solution to your problem
> > should be there :)
> >
> > Happy hacking, Marcus
> >
> > On 04.03.2014 07:27, Activecat wrote:
> >> The implementation header file is as below:
> >
> >
> >> #ifndef INCLUDED_ACTIVECAT_FFT1_IMPL_H #define
> >> INCLUDED_ACTIVECAT_FFT1_IMPL_H
> >
> >> #include  #include 
> >
> >> namespace gr { namespace activecat {
> >
> >> class fft1_impl : public fft1 { private: int d_N; int
> >> d_direction; int d_shift;
> >
> >> fftw_complex *d_input; fftw_plan d_plan;
> >
> >> public: fft1_impl(int fft_size, int direction, bool fft_shift);
> >> ~fft1_impl();
> >
> >> int work( int noutput_items, gr_vector_const_void_star
> >> &input_items, gr_vector_void_star &output_items); };
> >
> >> } // namespace activecat } // namespace gr
> >
> >> #endif /* INCLUDED_ACTIVECAT_FFT1_IMPL_H */
> >
> >
> >
> >> On Tue, Mar 4, 2014 at 1:55 PM, Activecat 
> >> wrote:
> >
> >>> Dear Sir,
> >>>
> >>> I am trying to build a custom block with FFT capability. I use
> >>> FFTW3, the FFT stuff runs well as a standalone program before
> >>> integrating into gnuradio.
> >>>
> >>> Then I integrate the FFT function into the block, it compiles
> >>> without any error. But when I run the flow graph in GRC, it
> >>> produces following error message.
> >>>
> >>> Generating: "/home/sgku/gnuradio/flow_graphs/top_block.py"
> >>> Executing: "/home/sgku/gnuradio/flow_graphs/top_block.py"
> >>> Traceback (most recent call last): File
> >>> "/home/sgku/gnuradio/flow_graphs/top_block.py", line 18, in
> >>>  import activecat File
> >>> "/usr/local/lib/python2.7/dist-packages/activecat/__init__.py",
> >>>
> >>>
> line 45, in  from activecat_swig import * File
> >>> "/usr/local/lib/python2.7/dist-packages/activecat/activecat_swig.py",
> >>>
> >>>
> line 26, in  _activecat_swig = swig_import_helper() File
> >>> "/usr/local/lib/python2.7/dist-packages/activecat/activecat_swig.py",
> >>>
> >>>
> line 22, in swig_import_helper _mod =
> >>> imp.load_module('_activecat_swig', fp, pathname, description)
> >>> ImportError: /usr/local/lib/libgnuradio-activecat.so: undefined
> >>>  symbol: fftw_plan_dft_1d
> >> Done
> >>>
> >>>
> >>> Below is the implmentation source file:
> >>>
> >>>
> >>> namespace gr { namespace activecat {
> >>>
> >>> fft1::sptr fft1::make(int fft_size, int direction, bool
> >>> fft_shift) { return gnuradio::get_initial_sptr (new
> >>> fft1_impl(fft_size, direction, fft_shift)); }
> >>>
> >>> // constructor fft1_impl::fft1_impl(int fft_size, int
> >>> direction, bool fft_shift) : gr::sync_block("fft1",
> >>> gr::io_signature::make( 1, 1, sizeof(gr_complex)),
> >>> gr::io_signature::make( 1, 1, sizeof(gr_complex))),
> >>> d_N(fft_size), d_direction(direction), d_shift(fft_shift) {
> >>> d_input = (fftw_complex*) fftw_malloc( sizeof(fftw_complex) *
> >>> d_N ); d_plan  = fftw_plan_dft_1d( d_N, d_input, d_input,
> >>> FFTW_BACKWARD, FFTW_ESTIMATE );  // later change FFTW_BACKWARD
> >>> to d_direction
> >>>
> >>> set_output_multiple( d_N ); set_min_noutput_items( d_N ); }
> >>>
> >>> // destructor fft1_impl::~fft1_impl() { }
> >>>
> >>> int fft1_impl::work( int noutput_items,
> >>> gr_vector_const_void_star &input_items, gr_vector_void_star
> >>> &output_items) { const gr_complex  *in  =  (const gr_complex *)
> >>> input_items[0]; gr_complex*out =  (gr_complex *)
> >>> output_items[0];
> >>>
> >>> for (int i=0; i < noutput_items; i++) { d_input[i][0] =
> >>> in[i].real(); d_input[i][1] = in[i].imag(); }
> >>>
> >>> fftw_execute( d_plan );
> >>>
> >>> for (int i=0; i < noutput_items; i++) { out[i].real(
> >>> d_input[i][0] ); out[i].imag( d_input[i][1] ); }
> >>>
> >>>
> >>> return noutput_items; } } /* namespace activecat */ } /*
> >>> namespace gr */
> >>>
> >>>
> >>>
> >>> Question: How to solve this error ?
> >>>
> >>> Regards, Activecat active...@gmail.com
> >>>
> >
> >
> >
> >> ___ Discuss-gnuradio
> >> mailing list Discuss-gnuradio@gnu.org
> >> https

[Discuss-gnuradio] IEEE DySPAN conference

[Tom Rondeau]

I try not to use this list to promote many conferences, but DySPAN is
one that I go to (almost) every year and is very relevant to our
project. There are definitely many GNU Radio users that go, but I
wouldn't mind seeing an increased presence.

Specifically, though, I wanted to let everyone know that Matt Ettus
and I will be giving a tutorial on the first day, "Using GNU Radio to
Explore the Consequences, Limits, and Behavior of DSA Systems". This
is /not/ a hands-on tutorial about how to use GNU Radio, but instead a
look by us on tools, techniques, and methods we have in GNU Radio to
explore issues involved in dynamic spectrum access.

More here:
http://dyspan2014.ieee-dyspan.org/program/tutorials

And more information about DySPAN here:
http://dyspan2014.ieee-dyspan.org/

Thanks,
Tom

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

Re: [Discuss-gnuradio] (GSoC) MIMO system

[Michael Dickens]

Just out of curiosity ... do you still have your MIMO code around for us to 
look at?  It might be a complete mess and fragile, but it also might be 
instructive in some ways.  If not, that's OK too; just thought it worth asking. 
 Thanks! - MLD

On Feb 24, 2014, at 10:22 AM, Tom Rondeau  wrote:
> Yes, and Matt Ettus and I proved that we could to 2x2 MIMO OFDM with
> GNU Radio on USRPs a number of years ago (there was not reason to
> think that we couldn't; just had to be done). Our code, though, was a
> complete mess and fragile at the time. It's even more obsolete now
> that we've replaced the OFDM layer. Which is why it's time to get this
> done properly in GNU Radio.

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

[Discuss-gnuradio] GSOC 14 project "Vector Network Analyzer"

[MITUL VEKARIYA]

Hi
I am Mitul Vekariya  - final year student of
Electronics and Communication (ECE) branch at Nirma University, India.
I am very interested in mentioned
project
.
I like digital signal processing, Embedded Linux, Digital Communication and
RF designing.
I didn't work on any USRP devices, but I have experience of FPGA
programming using VHDL and LabVIEW. I am familiar with SDR fundamentals and
GNURadio.

--

Regarding Project, I've found one good document
from
agilent.

Summary of what I understood from that document:
1) Using usrp b210 I can generate pure tone sine wave as test signal
2) I will connect DUT ( device under test ) with external components to the
usrp  and measure transmitted and reflected signal
3) The amplitude and phase of the received signal will lead to different
parameters

How can we measure phase between two sine waves using FPGA? The method of
zero crossing is advised or not?
Please give you inputs on this project.

Thanks
Mitul Vekariya
Institute of Technology
Nirma University
India
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [VOLK] Working Group reminder and invitation

[West, Nathan]

All,

Based on the G+ responses there should be a pretty good turn out for
the VOLK working group call tomorrow. This is partially a reminder (in
case those G+ reminders aren't enough) and an invitation for GSoC
students interested in projects related to VOLK in any way.

On the agenda I've got time at the very *end* of the call to discuss
GSoC related things.

After the call I'll post a link to meeting notes.

Nathan

Event link: https://plus.google.com/u/0/events/ch3jrjcvp7mdiqelpismfieg3n0

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

[Discuss-gnuradio] Error in "Constellation Decoder" block

[Azza Ben Mosbah]

Hi All,

I am manipulating GNU Radio Companion.
While using the "Constellation Decoder" block, I have put
*digital.constellation_qpsk* as a "Constellation Object" argument. But, I
have found an error when I have executed the flow graph:

*Traceback (most recent call last):*
*  File "/users/anb10/metrics/error_rate.py", line 342, in *
*tb = error_rate()*
*  File "/users/anb10/metrics/error_rate.py", line 225, in __init__*
*self.digital_constellation_decoder_cb_0 =
digital.constellation_decoder_cb(digital.constellation_qpsk)*
*  File
"/usr/lib64/python2.6/site-packages/gnuradio/digital/digital_swig.py", line
3096, in constellation_decoder_cb*
*return _digital_swig.constellation_decoder_cb(*args, **kwargs)*
*TypeError: in method 'constellation_decoder_cb', argument 1 of type
'digital_constellation_sptr'*

I don't know what went wrong. I have even tried
*digital.psk.psk_constellation(m=4,mod_code='gray')*,
*digital.constellation_8psk *and
*digital.psk.psk_constellation(m=8,mod_code='gray')* as a "Constellation
Object" argument.

So, what is the proper way to define the argument (Constellation Object) in
the "Constellation Decoder" block?

I hope you can give me some ideas. Any help is appreciated. Thank you.
Regards,
Azza
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error in "Constellation Decoder" block

[Tom Rondeau]

On Tue, Mar 4, 2014 at 4:17 PM, Azza Ben Mosbah
 wrote:
> Hi All,
>
> I am manipulating GNU Radio Companion.
> While using the "Constellation Decoder" block, I have put
> digital.constellation_qpsk as a "Constellation Object" argument. But, I have
> found an error when I have executed the flow graph:
>
> Traceback (most recent call last):
>   File "/users/anb10/metrics/error_rate.py", line 342, in 
> tb = error_rate()
>   File "/users/anb10/metrics/error_rate.py", line 225, in __init__
> self.digital_constellation_decoder_cb_0 =
> digital.constellation_decoder_cb(digital.constellation_qpsk)
>   File
> "/usr/lib64/python2.6/site-packages/gnuradio/digital/digital_swig.py", line
> 3096, in constellation_decoder_cb
> return _digital_swig.constellation_decoder_cb(*args, **kwargs)
> TypeError: in method 'constellation_decoder_cb', argument 1 of type
> 'digital_constellation_sptr'
>
> I don't know what went wrong. I have even tried
> digital.psk.psk_constellation(m=4,mod_code='gray'),
> digital.constellation_8psk and
> digital.psk.psk_constellation(m=8,mod_code='gray') as a "Constellation
> Object" argument.
>
> So, what is the proper way to define the argument (Constellation Object) in
> the "Constellation Decoder" block?
>
> I hope you can give me some ideas. Any help is appreciated. Thank you.
>
> Regards,
> Azza

Azza,

Check out the documentation page:
http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1constellation__decoder__cb.html

It's not entirely clear (unless you know to look for it). You want to
pass the constellation object using the base() parameter to get to the
parent class.  Basically, you'd call it:

digital.constellation_decoder_cb(digital.constellation_qpsk.base())

Tom

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

Re: [Discuss-gnuradio] gr-audio OSX fixes test branch (take 2)

[Alexandru Csete]

Hi Michael,

Following your step by step guide, I could successfully test your
changes with the Funcube Dongle Pro+ and a few USB audio devices. I
tested using audio_fft.py and dial_tone.py. It really works great;
it's amazing when one can use almost random sample rates and the audio
system will take care of everything :)

I hope your patch can be committed very soon. Even if there are some
bugs left, it works far better than the current code.

Alex


On Sat, Mar 1, 2014 at 11:05 PM, Michael Dickens
 wrote:
> I just pushed the latest changes to my gr-audio OSX test branch:
> < https://github.com/michaelld/gnuradio/tree/fix_gr_audio_osx >
>
> fix gr-audio osx:
> + use GNU Radio preferences file to set default input and output audio 
> device, if provided;
> + use gr::logger for all non-debug messages;
> + case-insensitive string find with desired audio device name;
> + fixes buffer allocation bug with low sample rates;
> + allows using a specific (named) audio device, or the default;
> + handles the case when the selected audio device becomes unavailable (e.g., 
> a USB stick is removed while in use);
> + if no audio device name is provided, uses the default audio device as found 
> in System Preferences::Sound;
> + handles the case when the default audio device is in use, and the user 
> changes that audio device in System Preferences::Sound, by internally 
> resetting to use the newly selected audio device;
> + all non-Apple names are now lower_case, not CamelCase.
>
> I believe the behavior is now as discussed by Kevin, Tom, myself, and others. 
>  And, at least for me, everything works as desired on OSX 10.8.  These 
> changes should work back to at least OSX 10.4, maybe even earlier.
>
> If you want do use MacPorts to test out these changes, here's what I 
> recommend you do:
>
> 1) make sure the gnuradio-devel port is installed and up to date
> {{{
> sudo port -f deactivate installed and "gnuradio*"
> sudo port install gnuradio-devel
> sudo port selfupdate
> sudo port upgrade gnuradio-devel
> }}}
>
> 2) Download the patch for these fixes; you can get them via my github branch 
> above (commit 55eaa7da48), and I've also put them into my public DropBox 
> folder:
> < 
> https://dl.dropboxusercontent.com/u/16655336/gr-audio-osx-wip-2014-03-01.diff 
> >
>
> 3) Patch gnuradio-devel; change "/PATH/TO" to be the correct path to the 
> patch:
> {{{
> sudo port patch gnuradio-devel
> cd `port work gnuradio-devel`/gnuradio*
> sudo patch -p1 < /PATH/TO/gr-audio-osx-wip-2014-03-01.diff
> }}}
>
> 4) build gnuradio-devel:
> {{{
> sudo port build gnuradio-devel
> }}}
>
> 5) install the new gr audio library (assuming PREFIX=/opt/local; if not, 
> change the "cp" destination):
> {{{
> cd `port work gnuradio-devel`/build/gr-audio/lib
> sudo cp libgnuradio-audio.3.7.3git.dylib /opt/local/lib
> }}}
>
> 6) Try it out!  For example:
> {{{
> /opt/local/share/gnuradio/examples/audio/audio_fft.py -r 96000 -I FUN
> /opt/local/share/gnuradio/examples/audio/dial_tone.py -r 1200 -O BuIlT
> }}}
>
> Try different rates, and different I/O devices.  You should see LOG printouts 
> from "audio_osx_source" and "audio_osx_sink" with information about what it's 
> doing.
>
> Let me know what you think! - MLD
>
> ps> I intentionally am having you install gnuradio-devel then create a 
> patched version in case things got messed up, for 2 reasons:
>
> a) If things get messed up either building or after copying 
> libgnuradio-audio, you can clean it up by doing
> {{{
> sudo port -f deactivate gnuradio-devel
> sudo port activate gnuradio-devel
> }}}
> and start from go.
>
> b) Sometimes 'port' thinks it is being smart by looking at the available 
> (deactivated) versions of a port, comparing to what is being requested, and 
> then activating a port instead of finishing the install of what you already 
> have being compiled.  Adding in the "-s" (from source) does not always help.  
> Hence, my having you copy the library by hand -- it's not difficult, and it's 
> easy to clean up if things don't work right.
>
>
> ___
> 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] how to write a block

[??????????????]

hi,
how to use the gr_modtoolto  write a block inherent from a in_tree_block,such 
as inherent from stream_to _vector
BZS___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GSOC 14 project "Vector Network Analyzer"

[zhenhua han]

Hi,

> How can we measure phase between two sine waves using FPGA?

Supposing the two sine waves have the same frequency.
For two discrete complex signals, v1 and v2. we can compute the phase
difference as follow.

v3 = v1 * conj(v2)
phase diff = arctan(imag(v3) , real(v3))

(conj() means conjugate)

Best,
Zhenhua



2014-03-05 1:36 GMT+08:00 MITUL VEKARIYA <10bec...@nirmauni.ac.in>:

> Hi
> I am Mitul Vekariya  - final year student of
> Electronics and Communication (ECE) branch at Nirma University, India.
> I am very interested in mentioned 
> project
> .
> I like digital signal processing, Embedded Linux, Digital Communication
> and RF designing.
> I didn't work on any USRP devices, but I have experience of FPGA
> programming using VHDL and LabVIEW. I am familiar with SDR fundamentals and
> GNURadio.
>
>
> --
>
> Regarding Project, I've found one good document 
> from
> agilent.
>
> Summary of what I understood from that document:
> 1) Using usrp b210 I can generate pure tone sine wave as test signal
> 2) I will connect DUT ( device under test ) with external components to
> the usrp  and measure transmitted and reflected signal
> 3) The amplitude and phase of the received signal will lead to different
> parameters
>
> How can we measure phase between two sine waves using FPGA? The method of
> zero crossing is advised or not?
> Please give you inputs on this project.
>
> Thanks
> Mitul Vekariya
> Institute of Technology
> Nirma University
> India
>
> ___
> 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