Re: [Discuss-gnuradio] Amplitude settings in uhd_siggen

[Marcus Müller]

Dear Zealdeal,

you should know how OFDM works: An OFDM symbol is nothing more than the
IDFT of a vector of permutated, possibly padded symbols.
No, for the sake of a simple example, assume your symbol vector is
[1,1,1,...,1]; without doubt, you'll notice that the IDFT of that vector
has an entry that exhibits a magnitude much larger than 1, whilst the
other elements of the IDFT have a much smaller magnitude (should be 0!).
This uneven distribution of power in time domain is a problem so common
to all OFDM systems that there is a fixed term coined for that: the PAPR
(peak/average power ratio); I'm pretty sure that you've stumbled across
that in whatever introduced you to OFDM.

Best regards,
Marcus

On 02/17/2015 08:21 AM, zealdeal wrote:
> I'm bit confused here.
>
> You said "In the OFDM example, watch the amplitude of the signal before it
> enters the USRP sink. If it exceeds 1.0, I promise it will clip"
>
> I transmitted OFDM symbols, keeping transmission amplitude as 0.2
>
> Then, on the collected log, I ran gr_plot_ofdm.py tool. It shows the plot of
> transmitted signal in time domain.
>
> I see that the amplitude is much more than 1 in that plot.
>
> Could please tell me where am I going wrong?
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Amplitude-settings-in-uhd-siggen-tp52274p52337.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Amplitude settings in uhd_siggen

[Martin Braun]

On 02/17/2015 08:21 AM, zealdeal wrote:
> I'm bit confused here.
> 
> You said "In the OFDM example, watch the amplitude of the signal before it
> enters the USRP sink. If it exceeds 1.0, I promise it will clip"
> 
> I transmitted OFDM symbols, keeping transmission amplitude as 0.2
> 
> Then, on the collected log, I ran gr_plot_ofdm.py tool. It shows the plot of
> transmitted signal in time domain.
> 
> I see that the amplitude is much more than 1 in that plot.
> 
> Could please tell me where am I going wrong?

I'm not even entirely sure what gr_plot_ofdm.py does.
If your signal amplitude is smaller than 1.0 before it goes to the
usrp_sink, you're good.

Cheers,
M


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

Re: [Discuss-gnuradio] uhd_fft segfault

[Ergeerts Glenn]

glxgears shows 60 fps (using binary nvidia driver).

just to be complete: i had a linker error first when building gnuradio 
using pybombs, which i didn't yet mention.
The output is shown below. It seemed not critical to me since it happens 
when linking an example.
I 'solved' it by commenting the "add_subdirectory(examples/c++)" in 
gr-uhd/CMakeLists.txt .
Maybe i made a wrong assumption and could this be causing the problem 
mentioned before?
Or maybe this error can be helpfull for diagnosing the issue?


Linking CXX executable tags_demo
[ 45%] Built target pygen_gr_uhd_swig_c9605
[ 46%] Built target _uhd_swig
Scanning dependencies of target _vocoder_swig
[ 46%] Built target pygen_gr_vocoder_swig_aa5c8
[ 66%] Built target gnuradio-blocks
[ 66%] Built target pygen_gr_fcd_swig_f8a01
[ 66%] [ 66%] Built target pygen_gr_wavelet_swig_e3597
Building CXX object 
gr-vocoder/swig/CMakeFiles/_vocoder_swig.dir/vocoder_swigPYTHON_wrap.cxx.o
[ 66%] Built target _wxgui_swig
[ 66%] Built target pygen_gr_wxgui_swig_bf89e
[ 66%] Built target gr_runtime_test
[ 66%] Built target gr_pmt_test
Scanning dependencies of target test-gr-blocks
[ 66%] Built target pmt_swig
Scanning dependencies of target _blocks_swig0
/home/glenn/bin/gnuradio/lib/libuhd.so: undefined reference to 
`libusb_error_name'
collect2: error: ld returned 1 exit status
make[2]: *** [gr-uhd/examples/c++/tags_demo] Error 1
make[1]: *** [gr-uhd/examples/c++/CMakeFiles/tags_demo.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[ 66%] [ 66%] Building CXX object 
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/test_gr_blocks.cc.o
Building CXX object 
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_block.cc.o
[ 66%] Building CXX object 
gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o
[ 66%] Building CXX object 
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_top_block.cc.o
[ 66%] Building CXX object 
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_hier_block2.cc.o
[ 66%] Building CXX object 
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_hier_block2_derived.cc.o
[ 66%] Building CXX object 
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_blocks.cc.o
[ 66%] Building CXX object 
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_block_tags.cc.o
[ 66%] Building CXX object 
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_rotator.cc.o
Linking CXX executable test-gr-blocks
[ 66%] Built target test-gr-blocks
Linking CXX shared module _vocoder_swig.so
[ 66%] Built target _vocoder_swig
Linking CXX shared module _blocks_swig0.so
[ 66%] Built target _blocks_swig0
make: *** [all] Error 2
Build failed. See output above for error messages.


On 02/17/2015 01:37 AM, Richard Bell wrote:
> I once had an OpenGL issue mess with uhd_fft. If you run 'glxgears' from a 
> terminal does it work and do you get a normal frame rate (30+ fps, I get up 
> to 60). My fix was installing proper video card drivers. Just a thought.
>
> Rich
>
> Sent from my iPhone
>
>> On Feb 16, 2015, at 12:48 PM, Ergeerts Glenn  
>> wrote:
>>
>> yes i did, "pybombs list" shows this:
>>
>>   gnuradioinstalled  inventory
>> fc7861ac029a4297df5a0b1159cb07f922670054
>> git://http://www.gnuradio.org/git/gnuradio.git
>>uhdinstalled  inventory
>> 7d97ab60012b99ed92fb122a3a68d68515a404fa
>> git://https://github.com/EttusResearch/uhd.git
>>
>>
>>> On 02/16/2015 09:39 PM, Martin Braun wrote:
>>> Those swig traces are hard to parse, but you might have to rebuild GNU
>>> Radio against the current UHD build. Did you install both via Pybombs?
>>>
>>> M
>>>
 On 02/16/2015 09:09 PM, Ergeerts Glenn wrote:
 Hi,

 I'm new to SDR and gnuradio and trying to get started with an USRP B200
 and gnuradio on ubuntu 14.04.
 I'm using pybombs (up-to-date) for building. Building succeeds but i get
 a segfault when running uhd_fft.
 The backtrace is below.

 I checked if the correct libuhd was being used (with ldd),instead of an
 old version from an ubuntu package.
 I also tried uhd_find_devices (which uses pure uhd if i'm correct,
 without gnuradio?), this works fine.
 Running "pybombs verify gnuradio" results in:
 The following tests FAILED:
   183 - qa_uhd (Failed)
   192 - qa_fcd (Failed)
 Errors while running CT

 Running gnuradio/gr-uhd/python/uhd/qa_uhd.py in gdb segfaults with a
 similar backtrace as well.
 Finally, i tried changing the gnuradio recipe to use the maint branch
 instead of master.
 Rebuilding (after cleaning the build dir) results in the same situation
 however.

 I don't know where to look next. Did anyone experience the same problem?
 Thanks for any pointers!


 (gdb) bt
 #0  0x0001e626 in ?? ()
 #1  0x7079d3a0 in strstr (__needle=0x7082bfca "swig_ptr: ",
 __haystack=0xd9398 ) at
 /usr/include/string.h:337
 #2  SWIG_Python_FixMethods (methods=0x70a57380

[Discuss-gnuradio] PSK.py script giving errors

[vaibhav kulkarni]

Hi All,

I am trying to make the following system.

Packet Generator --> BPSK Modulator > Frequency Hopper
---> UHD Sink

I read that the generic block psk.py can be used as a BPSK modulator so for
the 1st two blocks I use the class psk_mod(generic_mod), setting the
constellations as 2. Also the input to this block is a byte stream. So the
1st two blocks of my system are set.

For frequency hopper () I want to send every new BPSK modulated packet on a
different frequency seperated at 5MHz starting from 2.40Ghz) as I use the
frequency_hopping.py module which uses stream_tags for frequenncy tuning.
and Finally connecting it to the usrp sink.

Final system looking like this psk_mod (hier_block2),
hopper_block(hier_block2)

self.connect(psk_mod, hopper_block, self.sink)

However the PSK block gives the following errors.

1. Traceback (most recent call last):
  File "./psk_fh.py", line 301, in 
main()
  File "./psk_fh.py", line 294, in main
top_block = FlowGraph(args)
  File "./psk_fh.py", line 258, in __init__
src = psk_mod()
  File "./psk_fh.py", line 119, in __init__
super(psk_mod, self).__init__(constellation, differential, *args,
**kwargs)
TypeError: __init__() takes exactly 4 arguments (3 given)

Any help to resolve this or another approach to this system is appriciated.

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

Re: [Discuss-gnuradio] [USRP-users] USRP, GNURadio Companion, Polyphase Channelizer Issue

[sreeraj r]

Hi,

You can also look into Tom's blog on channelizers [1]. Some of the grc
files in the blog might not work out of the box (especially those ones with
QT-GUI frequency sink + bus ports). You can simply toggle the busports and
connect it properly and make it work.

[1] http://www.trondeau.com/examples/2014/1/23/pfb-channelizers
-and-synthesizers.html

Regards
Sreeraj Rajendran

On Mon, Feb 16, 2015 at 11:02 PM, Marcus D. Leech  wrote:

> On 02/16/2015 04:54 PM, Ali Riaz wrote:
>
>> Hi Marcus,
>>
>> I was the one who posted a question on the usrp-mailing list regarding
>> the gnuradio companion channelizer a couple of days back, and was wondering
>> if you could help me on something. I tried using the filter as you
>> suggested, but I get a very strange result. I tried to get two partitioned
>> channels, but they're being partitioned in a very strange manner. I've
>> attached a photo for a visual for what I'm getting as a result. Any idea
>> why that's happening?
>>
>> P.S My apologies, I know you pointed me to the GNUradio discussion
>> mailing list, but it's been a while, and nobody has responded yet, and so
>> far all I have is your clue to go on.
>>
>> Thank you so much for all your help, really appreciate it.
>>
>> Best,
>> Ali
>>
>>  This is very squarely in the domain of the discuss-gnuradio mailing list.
>
> My understanding is that the polyphase channelizer behaves that way for
> even-numbers of channels.  Tom Rondeau on the discuss-gnuradio mailing list
>   is the best person, probably, to explain this.  I've copied that list.
>
>
>
>
> ___
> 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] [USRP-users] USRP, GNURadio Companion, Polyphase Channelizer Issue

[Tom Rondeau]

On Tue, Feb 17, 2015 at 7:22 AM, sreeraj r  wrote:

> Hi,
>
> You can also look into Tom's blog on channelizers [1]. Some of the grc
> files in the blog might not work out of the box (especially those ones with
> QT-GUI frequency sink + bus ports). You can simply toggle the busports
> and connect it properly and make it work.
>
> [1] http://www.trondeau.com/examples/2014/1/23/pfb-channelizers
> -and-synthesizers.html
>
> Regards
> Sreeraj Rajendran
>
>
> On Mon, Feb 16, 2015 at 11:02 PM, Marcus D. Leech 
> wrote:
>
>> On 02/16/2015 04:54 PM, Ali Riaz wrote:
>>
>>> Hi Marcus,
>>>
>>> I was the one who posted a question on the usrp-mailing list regarding
>>> the gnuradio companion channelizer a couple of days back, and was wondering
>>> if you could help me on something. I tried using the filter as you
>>> suggested, but I get a very strange result. I tried to get two partitioned
>>> channels, but they're being partitioned in a very strange manner. I've
>>> attached a photo for a visual for what I'm getting as a result. Any idea
>>> why that's happening?
>>>
>>> P.S My apologies, I know you pointed me to the GNUradio discussion
>>> mailing list, but it's been a while, and nobody has responded yet, and so
>>> far all I have is your clue to go on.
>>>
>>> Thank you so much for all your help, really appreciate it.
>>>
>>> Best,
>>> Ali
>>>
>>>  This is very squarely in the domain of the discuss-gnuradio mailing
>> list.
>>
>> My understanding is that the polyphase channelizer behaves that way for
>> even-numbers of channels.  Tom Rondeau on the discuss-gnuradio mailing list
>>   is the best person, probably, to explain this.  I've copied that list.
>>
>
Also, look at the documentation for the block:

http://gnuradio.org/doc/doxygen/classgr_1_1filter_1_1pfb__channelizer__ccf.html

Specifically, the set_channel_map function. It shows the mapping of the
channels. With an even number of channels, the N/2 channel wraps around
fs/2 and -fs/2 while channel 0 spans 0 Hz. You just have to set up your
input bandwidth, sample rate, and tuning to account for this.

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

Re: [Discuss-gnuradio] uhd_fft segfault

[Tom Rondeau]

On Tue, Feb 17, 2015 at 6:04 AM, Ergeerts Glenn <
glenn.ergee...@uantwerpen.be> wrote:

> glxgears shows 60 fps (using binary nvidia driver).
>
> just to be complete: i had a linker error first when building gnuradio
> using pybombs, which i didn't yet mention.
> The output is shown below. It seemed not critical to me since it happens
> when linking an example.
> I 'solved' it by commenting the "add_subdirectory(examples/c++)" in
> gr-uhd/CMakeLists.txt .
> Maybe i made a wrong assumption and could this be causing the problem
> mentioned before?
> Or maybe this error can be helpfull for diagnosing the issue?
>
>
> Linking CXX executable tags_demo
> [ 45%] Built target pygen_gr_uhd_swig_c9605
> [ 46%] Built target _uhd_swig
> Scanning dependencies of target _vocoder_swig
> [ 46%] Built target pygen_gr_vocoder_swig_aa5c8
> [ 66%] Built target gnuradio-blocks
> [ 66%] Built target pygen_gr_fcd_swig_f8a01
> [ 66%] [ 66%] Built target pygen_gr_wavelet_swig_e3597
> Building CXX object
> gr-vocoder/swig/CMakeFiles/_vocoder_swig.dir/vocoder_swigPYTHON_wrap.cxx.o
> [ 66%] Built target _wxgui_swig
> [ 66%] Built target pygen_gr_wxgui_swig_bf89e
> [ 66%] Built target gr_runtime_test
> [ 66%] Built target gr_pmt_test
> Scanning dependencies of target test-gr-blocks
> [ 66%] Built target pmt_swig
> Scanning dependencies of target _blocks_swig0
> /home/glenn/bin/gnuradio/lib/libuhd.so: undefined reference to
> `libusb_error_name'
> collect2: error: ld returned 1 exit status
> make[2]: *** [gr-uhd/examples/c++/tags_demo] Error 1
> make[1]: *** [gr-uhd/examples/c++/CMakeFiles/tags_demo.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> [ 66%] [ 66%] Building CXX object
> gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/test_gr_blocks.cc.o
> Building CXX object
> gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_block.cc.o
> [ 66%] Building CXX object
> gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o
> [ 66%] Building CXX object
> gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_top_block.cc.o
> [ 66%] Building CXX object
> gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_hier_block2.cc.o
> [ 66%] Building CXX object
> gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_hier_block2_derived.cc.o
> [ 66%] Building CXX object
> gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_blocks.cc.o
> [ 66%] Building CXX object
> gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_block_tags.cc.o
> [ 66%] Building CXX object
> gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_rotator.cc.o
> Linking CXX executable test-gr-blocks
> [ 66%] Built target test-gr-blocks
> Linking CXX shared module _vocoder_swig.so
> [ 66%] Built target _vocoder_swig
> Linking CXX shared module _blocks_swig0.so
> [ 66%] Built target _blocks_swig0
> make: *** [all] Error 2
> Build failed. See output above for error messages.



Yes, this is definitely a problem that is likely related to your original
question. This error here is showing an issue with libusb and libuhd, which
would need to work together for you to run uhd_fft. It looks like something
is confused in your build of UHD with regards to USB support. I would try
reinstalling UHD. Remove it with "./pybombs rnd uhd" and then rerun
"./pybombs install uhd". Then do the same for gnuradio and see if that
completes.

If you have /any/ error when building GNU Radio, this suggests a deeper
problem.

Tom




> On 02/17/2015 01:37 AM, Richard Bell wrote:
> > I once had an OpenGL issue mess with uhd_fft. If you run 'glxgears' from
> a terminal does it work and do you get a normal frame rate (30+ fps, I get
> up to 60). My fix was installing proper video card drivers. Just a thought.
> >
> > Rich
> >
> > Sent from my iPhone
> >
> >> On Feb 16, 2015, at 12:48 PM, Ergeerts Glenn <
> glenn.ergee...@uantwerpen.be> wrote:
> >>
> >> yes i did, "pybombs list" shows this:
> >>
> >>   gnuradioinstalled  inventory
> >> fc7861ac029a4297df5a0b1159cb07f922670054
> >> git://http://www.gnuradio.org/git/gnuradio.git
> >>uhdinstalled  inventory
> >> 7d97ab60012b99ed92fb122a3a68d68515a404fa
> >> git://https://github.com/EttusResearch/uhd.git
> >>
> >>
> >>> On 02/16/2015 09:39 PM, Martin Braun wrote:
> >>> Those swig traces are hard to parse, but you might have to rebuild GNU
> >>> Radio against the current UHD build. Did you install both via Pybombs?
> >>>
> >>> M
> >>>
>  On 02/16/2015 09:09 PM, Ergeerts Glenn wrote:
>  Hi,
> 
>  I'm new to SDR and gnuradio and trying to get started with an USRP
> B200
>  and gnuradio on ubuntu 14.04.
>  I'm using pybombs (up-to-date) for building. Building succeeds but i
> get
>  a segfault when running uhd_fft.
>  The backtrace is below.
> 
>  I checked if the correct libuhd was being used (with ldd),instead of
> an
>  old version from an ubuntu package.
>  I also tried uhd_find_devices (which uses pure uhd if i'm correct,
>  without gnuradio?), this works fine.
>  Ru

Re: [Discuss-gnuradio] uhd_fft segfault

[Marcus D. Leech]

On 02/17/2015 09:35 AM, Tom Rondeau wrote:
On Tue, Feb 17, 2015 at 6:04 AM, Ergeerts Glenn 
mailto:glenn.ergee...@uantwerpen.be>> 
wrote:


glxgears shows 60 fps (using binary nvidia driver).

just to be complete: i had a linker error first when building gnuradio
using pybombs, which i didn't yet mention.
The output is shown below. It seemed not critical to me since it
happens
when linking an example.
I 'solved' it by commenting the "add_subdirectory(examples/c++)" in
gr-uhd/CMakeLists.txt .
Maybe i made a wrong assumption and could this be causing the problem
mentioned before?
Or maybe this error can be helpfull for diagnosing the issue?


Linking CXX executable tags_demo
[ 45%] Built target pygen_gr_uhd_swig_c9605
[ 46%] Built target _uhd_swig
Scanning dependencies of target _vocoder_swig
[ 46%] Built target pygen_gr_vocoder_swig_aa5c8
[ 66%] Built target gnuradio-blocks
[ 66%] Built target pygen_gr_fcd_swig_f8a01
[ 66%] [ 66%] Built target pygen_gr_wavelet_swig_e3597
Building CXX object
gr-vocoder/swig/CMakeFiles/_vocoder_swig.dir/vocoder_swigPYTHON_wrap.cxx.o
[ 66%] Built target _wxgui_swig
[ 66%] Built target pygen_gr_wxgui_swig_bf89e
[ 66%] Built target gr_runtime_test
[ 66%] Built target gr_pmt_test
Scanning dependencies of target test-gr-blocks
[ 66%] Built target pmt_swig
Scanning dependencies of target _blocks_swig0
/home/glenn/bin/gnuradio/lib/libuhd.so: undefined reference to
`libusb_error_name'
collect2: error: ld returned 1 exit status
make[2]: *** [gr-uhd/examples/c++/tags_demo] Error 1
make[1]: *** [gr-uhd/examples/c++/CMakeFiles/tags_demo.dir/all]
Error 2
make[1]: *** Waiting for unfinished jobs
[ 66%] [ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/test_gr_blocks.cc.o
Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_block.cc.o
[ 66%] Building CXX object
gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_top_block.cc.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_hier_block2.cc.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_hier_block2_derived.cc.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_blocks.cc.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_block_tags.cc.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_rotator.cc.o
Linking CXX executable test-gr-blocks
[ 66%] Built target test-gr-blocks
Linking CXX shared module _vocoder_swig.so
[ 66%] Built target _vocoder_swig
Linking CXX shared module _blocks_swig0.so
[ 66%] Built target _blocks_swig0
make: *** [all] Error 2
Build failed. See output above for error messages.



Yes, this is definitely a problem that is likely related to your 
original question. This error here is showing an issue with libusb and 
libuhd, which would need to work together for you to run uhd_fft. It 
looks like something is confused in your build of UHD with regards to 
USB support. I would try reinstalling UHD. Remove it with "./pybombs 
rnd uhd" and then rerun "./pybombs install uhd". Then do the same for 
gnuradio and see if that completes.


If you have /any/ error when building GNU Radio, this suggests a 
deeper problem.


Tom

For B2xx support, you need a version of libusb that has 
libusb_error_name() -- older versions of the library don't have this 
API, and that's why

  you're getting the linker error.




On 02/17/2015 01:37 AM, Richard Bell wrote:
> I once had an OpenGL issue mess with uhd_fft. If you run
'glxgears' from a terminal does it work and do you get a normal
frame rate (30+ fps, I get up to 60). My fix was installing proper
video card drivers. Just a thought.
>
> Rich
>
> Sent from my iPhone
>
>> On Feb 16, 2015, at 12:48 PM, Ergeerts Glenn
mailto:glenn.ergee...@uantwerpen.be>> wrote:
>>
>> yes i did, "pybombs list" shows this:
>>
>>   gnuradioinstalled inventory
>> fc7861ac029a4297df5a0b1159cb07f922670054
>> git://http://www.gnuradio.org/git/gnuradio.git
>>uhdinstalled inventory
>> 7d97ab60012b99ed92fb122a3a68d68515a404fa
>> git://https://github.com/EttusResearch/uhd.git
>>
>>
>>> On 02/16/2015 09:39 PM, Martin Braun wrote:
>>> Those swig traces are hard to parse, but you might have to
rebuild GNU
>>> Radio against the current UHD build. Did you install both via
Pybombs?
>>>
>>> M
>>>
 On 02/16/2015 09:09 PM, Ergeerts Glenn wrote:
 Hi,

 I'm new to SDR and gnuradio and trying to get started with an
USRP B2

Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'hamming'

[Tom Rondeau]

On Sat, Feb 14, 2015 at 2:17 AM, Abhinav Jadon 
wrote:

> Hi ,
> I wrote a Out of Tree module for hamming code using ITPP library . It
> compiled when i ran the cmake.. , make and make install commands without
> error . I used the block in a flowgraph and the python script thus
> generated throws an error while executing it which looks like this .
>
> Traceback (most recent call last):
>   File "/home/iiitd/Desktop/hamming.py", line 62, in 
> tb = hamming()
>   File "/home/iiitd/Desktop/hamming.py", line 33, in __init__
> self.wsi_hamming_0 = wsi.hamming(3)
> AttributeError: 'module' object has no attribute 'hamming'
>
> I then checked the $PYTHONPATH and made sure it points to the directory
> where the files associated with the block are installed during make install
> ie /usr/local/lib/python2.7/dist-packages instead to
> /opt/qt/lib/python2.7/dist-packages .
>
>
> It would be really thankful if somebody helps me sort this out .
>
> The link to the my OOT code is
> https://www.dropbox.com/sh/8tstm4ckaphsis/AAD0cbS5eelaoaIe0gUExCBea?dl=0
>
> Thanks
> Abhinav Jadon
>

Did you use gr_modtool to build the OOT project?

Are you sure you are linking against the ITPP library correctly? If you ldd
on your resulting .so file, does it show it links properly?

Is your block in Python or in C++?

What version of GNU Radio are you running?

That link you sent goes nowhere.

You can run "gdb --args python hamming.py" to see a backtrace of where the
problem is really happening.

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

Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'hamming'

[Tom Rondeau]

On Sat, Feb 14, 2015 at 6:41 PM, Richard Bell 
wrote:

> I ran into this myself with a custom Python block. I was unable to resolve
> it. I gave up. Interested to learn a fix as well.
>

I don't think this is a Python block since he's linking against ITPP, but
it's not specified in his original question, so I can't be sure.

Anyways, I just tried making a Python block in an OOT project and it works
just fine.

$ gr_modtool nm
Name of the new module: testpy
Creating out-of-tree module in ./gr-testpy... Done.
Use 'gr_modtool add' to add a new block to this currently empty module.

$ cd gr-testpy
$ gr_modtool add
GNU Radio module name identified: testpy
('sink', 'source', 'sync', 'decimator', 'interpolator', 'general',
'tagged_stream', 'hier', 'noblock')
Enter block type: sync
Language (python/cpp): python
Language: Python
Enter name of block/code (without module name prefix): test01
Block/code identifier: test01
Enter valid argument list, including default arguments:
Add Python QA code? [Y/n]
Adding file 'python/test01.py'...
Adding file 'python/qa_test01.py'...
Editing python/CMakeLists.txt...
Adding file 'grc/testpy_test01.xml'...
Editing grc/CMakeLists.txt...



$ mkdir build; cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/opt/gr ../
$ make
$ make install
$ ipython
In [1]: import testpy

In [2]: dir(testpy)
Out[2]:
['__builtins__',
 '__doc__',
 '__file__',
 '__name__',
 '__package__',
 '__path__',
 'test01']

In [3]: a = testpy.test01()



Worked fine. You're not the only person with this problem, but no one has
yet shown me how to reproduce the error.

Tom



> On Feb 13, 2015, at 11:17 PM, Abhinav Jadon 
> wrote:
>
> Hi ,
> I wrote a Out of Tree module for hamming code using ITPP library . It
> compiled when i ran the cmake.. , make and make install commands without
> error . I used the block in a flowgraph and the python script thus
> generated throws an error while executing it which looks like this .
>
> Traceback (most recent call last):
>   File "/home/iiitd/Desktop/hamming.py", line 62, in 
> tb = hamming()
>   File "/home/iiitd/Desktop/hamming.py", line 33, in __init__
> self.wsi_hamming_0 = wsi.hamming(3)
> AttributeError: 'module' object has no attribute 'hamming'
>
> I then checked the $PYTHONPATH and made sure it points to the directory
> where the files associated with the block are installed during make install
> ie /usr/local/lib/python2.7/dist-packages instead to
> /opt/qt/lib/python2.7/dist-packages .
>
>
> It would be really thankful if somebody helps me sort this out .
>
> The link to the my OOT code is
> https://www.dropbox.com/sh/8tstm4ckaphsis/AAD0cbS5eelaoaIe0gUExCBea?dl=0
>
> Thanks
> Abhinav Jadon
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'hamming'

[Abhinav Jadon]

Hi ,
Sorry for not providing all the info . I dont know what happened to the
link though .
I used gr_modtool to create the OOT module ;
I wrote the module in C++ and i am using GNU Radio 3.7.6
I have created a git repository :
https://github.com/Jadoobaba/gr-wsi/tree/master/Documents/gr-wsi

ldd on the .so file has the following output .
iiitd@iiitd-ThinkPad-W530:/usr/local/lib$ ldd libgnuradio-wsi.so
linux-vdso.so.1 =>  (0x7fffc59fe000)
libboost_system.so.1.53.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.53.0 (0x7f79fc959000)
libgnuradio-runtime-3.7.6.1.so.0.0.0 =>
/usr/local/lib/libgnuradio-runtime-3.7.6.1.so.0.0.0 (0x7f79fc689000)
libgnuradio-pmt-3.7.6.1.so.0.0.0 =>
/usr/local/lib/libgnuradio-pmt-3.7.6.1.so.0.0.0 (0x7f79fc44)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f79fc13c000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f79fbf26000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f79fbb5d000)
libvolk.so.0.0.0 => /usr/local/lib/libvolk.so.0.0.0 (0x7f79fb80f000)
libboost_filesystem.so.1.53.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.53.0 (0x7f79fb5f9000)
libboost_thread.so.1.53.0 =>
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0 (0x7f79fb3e2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f79fb1c5000)
liblog4cpp.so.5 => /usr/lib/liblog4cpp.so.5 (0x7f79faf85000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f79fad7c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f79faa78000)
/lib64/ld-linux-x86-64.so.2 (0x7f79fcd87000)
liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0
(0x7f79fa7f8000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f79fa5de000)


While running gdb --args python hamming.py has the following result .
(gdb) run
Starting program: /usr/bin/python hamming.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe2576700 (LWP 4704)]
[New Thread 0x7fffe1d75700 (LWP 4705)]
[New Thread 0x7fffe0a9a700 (LWP 4706)]
[New Thread 0x7fffd3fff700 (LWP 4707)]
[New Thread 0x7fffd37fe700 (LWP 4708)]
Traceback (most recent call last):
  File "hamming.py", line 62, in 
tb = hamming()
  File "hamming.py", line 33, in __init__
self.wsi_hamming_0 = wsi.hamming(3)
AttributeError: 'module' object has no attribute 'hamming'
[Thread 0x7fffd37fe700 (LWP 4708) exited]
[Thread 0x7fffe0a9a700 (LWP 4706) exited]
[Thread 0x7fffe1d75700 (LWP 4705) exited]
[Thread 0x7fffe2576700 (LWP 4704) exited]
[Thread 0x77fd6740 (LWP 4699) exited]
[Inferior 1 (process 4699) exited with code 01]



Thanks in advance
Abhinav Jadon



On Tue, Feb 17, 2015 at 8:37 PM, Tom Rondeau  wrote:

> On Sat, Feb 14, 2015 at 6:41 PM, Richard Bell 
> wrote:
>
>> I ran into this myself with a custom Python block. I was unable to
>> resolve it. I gave up. Interested to learn a fix as well.
>>
>
> I don't think this is a Python block since he's linking against ITPP, but
> it's not specified in his original question, so I can't be sure.
>
> Anyways, I just tried making a Python block in an OOT project and it works
> just fine.
>
> $ gr_modtool nm
> Name of the new module: testpy
> Creating out-of-tree module in ./gr-testpy... Done.
> Use 'gr_modtool add' to add a new block to this currently empty module.
>
> $ cd gr-testpy
> $ gr_modtool add
> GNU Radio module name identified: testpy
> ('sink', 'source', 'sync', 'decimator', 'interpolator', 'general',
> 'tagged_stream', 'hier', 'noblock')
> Enter block type: sync
> Language (python/cpp): python
> Language: Python
> Enter name of block/code (without module name prefix): test01
> Block/code identifier: test01
> Enter valid argument list, including default arguments:
> Add Python QA code? [Y/n]
> Adding file 'python/test01.py'...
> Adding file 'python/qa_test01.py'...
> Editing python/CMakeLists.txt...
> Adding file 'grc/testpy_test01.xml'...
> Editing grc/CMakeLists.txt...
>
> 
>
> $ mkdir build; cd build
> $ cmake -DCMAKE_INSTALL_PREFIX=/opt/gr ../
> $ make
> $ make install
> $ ipython
> In [1]: import testpy
>
> In [2]: dir(testpy)
> Out[2]:
> ['__builtins__',
>  '__doc__',
>  '__file__',
>  '__name__',
>  '__package__',
>  '__path__',
>  'test01']
>
> In [3]: a = testpy.test01()
>
>
>
> Worked fine. You're not the only person with this problem, but no one has
> yet shown me how to reproduce the error.
>
> Tom
>
>
>
>> On Feb 13, 2015, at 11:17 PM, Abhinav Jadon 
>> wrote:
>>
>> Hi ,
>> I wrote a Out of Tree module for hamming code using ITPP library . It
>> compiled when i ran the cmake.. , make and make install commands without
>> error . I used the block in a flowgraph and the python script thus
>> generated throws an error while executing it which looks like this .
>>
>> Traceback (most recent call last):
>>   File "/home/iiitd/Desktop/hamming.py", line 62, in 
>> 

Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'hamming'

[Tom Rondeau]

On Tue, Feb 17, 2015 at 11:04 AM, Abhinav Jadon 
wrote:

> Hi ,
> Sorry for not providing all the info . I dont know what happened to the
> link though .
> I used gr_modtool to create the OOT module ;
> I wrote the module in C++ and i am using GNU Radio 3.7.6
> I have created a git repository :
> https://github.com/Jadoobaba/gr-wsi/tree/master/Documents/gr-wsi
>
> ldd on the .so file has the following output .
> iiitd@iiitd-ThinkPad-W530:/usr/local/lib$ ldd libgnuradio-wsi.so
> linux-vdso.so.1 =>  (0x7fffc59fe000)
> libboost_system.so.1.53.0 =>
> /usr/lib/x86_64-linux-gnu/libboost_system.so.1.53.0 (0x7f79fc959000)
> libgnuradio-runtime-3.7.6.1.so.0.0.0 =>
> /usr/local/lib/libgnuradio-runtime-3.7.6.1.so.0.0.0 (0x7f79fc689000)
> libgnuradio-pmt-3.7.6.1.so.0.0.0 =>
> /usr/local/lib/libgnuradio-pmt-3.7.6.1.so.0.0.0 (0x7f79fc44)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7f79fc13c000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x7f79fbf26000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f79fbb5d000)
> libvolk.so.0.0.0 => /usr/local/lib/libvolk.so.0.0.0
> (0x7f79fb80f000)
> libboost_filesystem.so.1.53.0 =>
> /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.53.0 (0x7f79fb5f9000)
> libboost_thread.so.1.53.0 =>
> /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0 (0x7f79fb3e2000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f79fb1c5000)
> liblog4cpp.so.5 => /usr/lib/liblog4cpp.so.5 (0x7f79faf85000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f79fad7c000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f79faa78000)
> /lib64/ld-linux-x86-64.so.2 (0x7f79fcd87000)
> liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0
> (0x7f79fa7f8000)
> libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f79fa5de000)
>


Yep, that tells you it right there. You are not linking against the ITPP
library. Here's the change you need to make to your lib/CMakeLists.txt file:

add_library(gnuradio-wsi SHARED ${wsi_sources})
-target_link_libraries(gnuradio-wsi ${Boost_LIBRARIES}
${GNURADIO_ALL_LIBRARIES})
+target_link_libraries(gnuradio-wsi ${Boost_LIBRARIES} ${wsi_libs})
 set_target_properties(gnuradio-wsi PROPERTIES DEFINE_SYMBOL
"gnuradio_wsi_EXPORTS")

You've created a wsi_libs variable already, but never added this to the
target_link_libraries call. So when trying to open the shared library and
make ITPP calls, you couldn't, which was causing the import to fail. Notice
all of the extra libraries it links against when you make this change
(libitpp.so, libblas.so, etc., etc.):

$ ldd lib/libgnuradio-wsi.so
linux-vdso.so.1 =>  (0x7fff5d8a1000)
libboost_system.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x7f9228b6f000)
libgnuradio-runtime-3.7.7git.so.0.0.0 =>
/opt/gr/lib/libgnuradio-runtime-3.7.7git.so.0.0.0 (0x7f922889f000)
libgnuradio-pmt-3.7.7git.so.0.0.0 =>
/opt/gr/lib/libgnuradio-pmt-3.7.7git.so.0.0.0 (0x7f9228657000)
libitpp.so.8 => /usr/lib/libitpp.so.8 (0x7f9228088000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f9227d83000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f9227b6d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f92277a7000)
libvolk.so.0.0.0 => /opt/gr/lib/libvolk.so.0.0.0 (0x7f9227481000)
libboost_filesystem.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x7f922726b000)
libboost_thread.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x7f9227055000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f9226e36000)
liblog4cpp.so.5 => /usr/lib/liblog4cpp.so.5 (0x7f9226bf6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f92269ee000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f92266e7000)
libfftw3.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3.so.3
(0x7f92262ef000)
liblapack.so.3 => /usr/lib/liblapack.so.3 (0x7f9225b53000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x7f9225586000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x7f9225377000)
/lib64/ld-linux-x86-64.so.2 (0x7f9228fb1000)
liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0
(0x7f92250f5000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f9224eda000)
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3
(0x7f9224bc1000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0
(0x7f9224984000)

I was hoping that the gdb call would tell us of the failure going on in
inside the module while it was trying to import it, but looks like that's
opaque here. Oh well.

Also, just as an aside, your git needs a bit of work. You've added the
build directory, which you should never do, as well as all of your
temporary emacs files (the files ending in ~). And for some reason, your
root directory is Documents wi

Re: [Discuss-gnuradio] sync_decimator_ff block with decimation above 262144 gives segfault

[Tom Rondeau]

On Thu, Feb 12, 2015 at 5:14 PM, Martin 
wrote:

> Hi all,
>
> When I set the decimation of a fir_filter or integrate block with float
> input and output to 262144 or above, gnuradio crashes with a segfault.
> With complex inputs and outputs I get a segfault above 524288.
> with short inputs and outputs it is at decimation 131072.
>
> This seems to be the case with most (all) sync_decimator blocks like
> fir_filters or the integration block.
>
> The blocks seem to be are accessing the input buffer outside the valid
> range. Which indicates that the input buffers are too small.
>
> What is strange is that if the datatype is 2 times as large  (float = 4
> bytes, complex = 8 bytes) the decimation factor may also be 2 times larger,
> which indicates that the problem occurs at a bufferposition that is 2x2 = 4
> times larger.
> So the buffersize does not seem to be fixed.
>
>
> The required buffersizes should be automatically calculated before
> creating the buffers.
> Are all buffers still calculated and instantiated in flat_flowgraph.cc ?
>
> I could not yet find any obvious errors in calculating the required buffer
> sizes. But something is going wrong.
>
> The buffersize calculation in flat_flowgraph.cc :
> flat_flowgraph::allocate_buffer(basic_block_sptr block, int port) {
> ...
> ...
> double decimation = (1.0/dgrblock->relative_rate());
> int multiple  = dgrblock->output_multiple();
> int history   = dgrblock->history();
> nitems = std::max(nitems, static_cast(2*(
> decimation*multiple+history)));
>
>
> When using the integration_ff block gdb debug shows that the segfault is
> at line 61 of integrate_ff_impl.cc
>
> 51integrate_ff_impl::work(int noutput_items,
> 52gr_vector_const_void_star &input_items,
> 53gr_vector_void_star &output_items)
> 54{
> 55  const float *in = (const float *)input_items[0];
> 56  float *out = (float *)output_items[0];
> 57
> 58  for (int i = 0; i < noutput_items; i++) {
> 59  out[i] = (float)0;
> 60  for (int j = 0; j < d_decim; j++)
> 61out[i] += in[i*d_decim+j];//<== segfault here !!!
> 62  }
>
>
> gnuradio-config-info -v
> 3.7.7git-0-gf0cd5041
>
> With best regards,
>
> Martin Dudok van Heel


Hi Martin,

Thanks for pointing this out. Could you please open this up as an Issue on
our issue tracker on gnuradio.org? Otherwise, this email and information
are likely to get lost and forgotten about before we can do anything about
it.

Now, doing that level of decimation is kind of crazy, which is why it's
taken over 10 years to find this bug. Still, it shouldn't segfault on it
even if the scheduler can't handle those numbers. This is almost certainly
related to the max buffer size.

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

[Discuss-gnuradio] Calling usrp_source block function from other block

[Anderson, Douglas J.]

Hi all,

I'm looking for the best way to retune the USRP from another block in a running 
flowgraph. I've seen the tune callback method used by bin_statistics_f, but I 
was wondering if there are other ways to do it. I took a look at message 
passing (http://gnuradio.org/doc/doxygen/page_msg_passing.html), but I'm not 
sure how to bind usrp_source's set_center_freq to handle a freq passed by 
message, etc.

Are there any examples of doing this laying around or is bin_statistics_f's 
tune callback still the best way to do it?

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

[Discuss-gnuradio] eye diagram error

[Mostafa Alizadeh]

Hello,

When I used eye diagram block (which seems to be a member of WxGUI class),
the following error appeared:

  File "/usr/local/lib/python2.7/dist-packages/baz/eye.py", line 98, in
__init__
self.st = gr.message_sink(gr.sizeof_float, msgq, dont_block=1)
AttributeError: 'module' object has no attribute 'message_sink'


what is the main problem?

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

Re: [Discuss-gnuradio] eye diagram error

[Marcus Müller]

Hi Mostafa,

which GNU Radio version are you using?
GNU Radio itself (to my knowledge) doesn't come with a dedicated eye
diagram, and it's possible that you're trying to use an out-of-tree
module that was meant for another version of GNU Radio.
You can try to emulate an eye diagram by using the Scope Sink, and
triggering on a signal that has an edge on every symbol center.

Best regards,
Marcus

On 02/17/2015 06:30 PM, Mostafa Alizadeh wrote:
> Hello, 
>
> When I used eye diagram block (which seems to be a member of WxGUI
> class), the following error appeared:
>
>   File "/usr/local/lib/python2.7/dist-packages/baz/eye.py", line 98,
> in __init__
> self.st  = gr.message_sink(gr.sizeof_float, msgq,
> dont_block=1)
> AttributeError: 'module' object has no attribute 'message_sink' 
>
>
> what is the main problem? 
>
> best, 
> Mostafa
>
>
>
> ___
> 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] uhd_fft segfault

[Ergeerts Glenn]

i have libusb-1.0-0-dev version 1.0.17-1ubuntu2 installed.
However, doing ldd on libuhd.so showed that /usr/local/lib/libusb-1.0.so.0 was 
used instead of the version from /usr/lib/ .
I'm not sure how it came there, i suspect from a PPA package i tried installing 
before reverting to pybombs.
After removing this file ldd now pick the correct libusb and gnuradio builds 
fine!
I have not been able to test it with the USRP connected but uhd_fft does not 
segfaults anymore so it seems fixed.

Thanks for the help and sorry for not providing this information up front!

On 02/17/2015 03:57 PM, Marcus D. Leech wrote:
On 02/17/2015 09:35 AM, Tom Rondeau wrote:
On Tue, Feb 17, 2015 at 6:04 AM, Ergeerts Glenn 
mailto:glenn.ergee...@uantwerpen.be>> wrote:
glxgears shows 60 fps (using binary nvidia driver).

just to be complete: i had a linker error first when building gnuradio
using pybombs, which i didn't yet mention.
The output is shown below. It seemed not critical to me since it happens
when linking an example.
I 'solved' it by commenting the "add_subdirectory(examples/c++)" in
gr-uhd/CMakeLists.txt .
Maybe i made a wrong assumption and could this be causing the problem
mentioned before?
Or maybe this error can be helpfull for diagnosing the issue?


Linking CXX executable tags_demo
[ 45%] Built target pygen_gr_uhd_swig_c9605
[ 46%] Built target _uhd_swig
Scanning dependencies of target _vocoder_swig
[ 46%] Built target pygen_gr_vocoder_swig_aa5c8
[ 66%] Built target gnuradio-blocks
[ 66%] Built target pygen_gr_fcd_swig_f8a01
[ 66%] [ 66%] Built target pygen_gr_wavelet_swig_e3597
Building CXX object
gr-vocoder/swig/CMakeFiles/_vocoder_swig.dir/vocoder_swigPYTHON_wrap.cxx.o
[ 66%] Built target _wxgui_swig
[ 66%] Built target pygen_gr_wxgui_swig_bf89e
[ 66%] Built target gr_runtime_test
[ 66%] Built target gr_pmt_test
Scanning dependencies of target test-gr-blocks
[ 66%] Built target pmt_swig
Scanning dependencies of target _blocks_swig0
/home/glenn/bin/gnuradio/lib/libuhd.so: undefined reference to
`libusb_error_name'
collect2: error: ld returned 1 exit status
make[2]: *** [gr-uhd/examples/c++/tags_demo] Error 1
make[1]: *** [gr-uhd/examples/c++/CMakeFiles/tags_demo.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[ 66%] [ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/test_gr_blocks.cc.o
Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_block.cc.o
[ 66%] Building CXX object
gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_top_block.cc.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_hier_block2.cc.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_hier_block2_derived.cc.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_blocks.cc.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_block_tags.cc.o
[ 66%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_rotator.cc.o
Linking CXX executable test-gr-blocks
[ 66%] Built target test-gr-blocks
Linking CXX shared module _vocoder_swig.so
[ 66%] Built target _vocoder_swig
Linking CXX shared module _blocks_swig0.so
[ 66%] Built target _blocks_swig0
make: *** [all] Error 2
Build failed. See output above for error messages.


Yes, this is definitely a problem that is likely related to your original 
question. This error here is showing an issue with libusb and libuhd, which 
would need to work together for you to run uhd_fft. It looks like something is 
confused in your build of UHD with regards to USB support. I would try 
reinstalling UHD. Remove it with "./pybombs rnd uhd" and then rerun "./pybombs 
install uhd". Then do the same for gnuradio and see if that completes.

If you have /any/ error when building GNU Radio, this suggests a deeper problem.

Tom

For B2xx support, you need a version of libusb that has libusb_error_name() -- 
older versions of the library don't have this API, and that's why
  you're getting the linker error.




On 02/17/2015 01:37 AM, Richard Bell wrote:
> I once had an OpenGL issue mess with uhd_fft. If you run 'glxgears' from a 
> terminal does it work and do you get a normal frame rate (30+ fps, I get up 
> to 60). My fix was installing proper video card drivers. Just a thought.
>
> Rich
>
> Sent from my iPhone
>
>> On Feb 16, 2015, at 12:48 PM, Ergeerts Glenn 
>> mailto:glenn.ergee...@uantwerpen.be>> wrote:
>>
>> yes i did, "pybombs list" shows this:
>>
>>   gnuradioinstalled  inventory
>> fc7861ac029a4297df5a0b1159cb07f922670054
>> git://http://www.gnuradio.org/git/gnuradio.git
>>uhdinstalled  inventory
>> 7d97ab60012b99ed92fb122a3a68d68515a404fa
>> git://https://github.com/EttusResearch/uhd.git
>>
>>
>>> On 02/16/2015 09:39 PM, Martin Braun wrote:
>>> Those swig traces are hard to parse, but you might have to rebuild GN

Re: [Discuss-gnuradio] Calling usrp_source block function from other block

[Tom Rondeau]

On Tue, Feb 17, 2015 at 11:52 AM, Anderson, Douglas J. <
dander...@its.bldrdoc.gov> wrote:

>   Hi all,
>
>  I'm looking for the best way to retune the USRP from another block in a
> running flowgraph. I've seen the tune callback method used by
> bin_statistics_f, but I was wondering if there are other ways to do it. I
> took a look at message passing (
> http://gnuradio.org/doc/doxygen/page_msg_passing.html), but I'm not sure
> how to bind usrp_source's set_center_freq to handle a freq passed by
> message, etc.
>
>  Are there any examples of doing this laying around or is
> bin_statistics_f's tune callback still the best way to do it?
>
>  -Doug
>

Hi Doug,

Take a look at the UHD page:

http://gnuradio.org/doc/doxygen/page_uhd.html

The existing command message interface to the UHD block's already allows
you to set the frequency with a message. This manual page will tell you how
to format that message properly.

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

Re: [Discuss-gnuradio] PSK.py script giving errors

[Tom Rondeau]

On Tue, Feb 17, 2015 at 6:15 AM, vaibhav kulkarni <
vaibhavkulkarn...@gmail.com> wrote:

> Hi All,
>
> I am trying to make the following system.
>
> Packet Generator --> BPSK Modulator > Frequency Hopper
> ---> UHD Sink
>
> I read that the generic block psk.py can be used as a BPSK modulator so
> for the 1st two blocks I use the class psk_mod(generic_mod), setting the
> constellations as 2. Also the input to this block is a byte stream. So the
> 1st two blocks of my system are set.
>
> For frequency hopper () I want to send every new BPSK modulated packet on
> a different frequency seperated at 5MHz starting from 2.40Ghz) as I use the
> frequency_hopping.py module which uses stream_tags for frequenncy tuning.
> and Finally connecting it to the usrp sink.
>
> Final system looking like this psk_mod (hier_block2),
> hopper_block(hier_block2)
>
> self.connect(psk_mod, hopper_block, self.sink)
>
> However the PSK block gives the following errors.
>
> 1. Traceback (most recent call last):
>   File "./psk_fh.py", line 301, in 
> main()
>   File "./psk_fh.py", line 294, in main
> top_block = FlowGraph(args)
>   File "./psk_fh.py", line 258, in __init__
> src = psk_mod()
>   File "./psk_fh.py", line 119, in __init__
> super(psk_mod, self).__init__(constellation, differential, *args,
> **kwargs)
> TypeError: __init__() takes exactly 4 arguments (3 given)
>
> Any help to resolve this or another approach to this system is
> appriciated.
>
> -
> Vaibhav Kulkarni
> ETH Zurich
>


This is probably related to a change in version for the psk_mod class. Take
a look at the psk.py file you have. The current version looks like:

 def __init__(self, constellation_points=_def_constellation_points,
 mod_code=_def_mod_code,
 differential=_def_differential,
 *args, **kwargs):

So you need that mod_code value set, as well. It's described in the class
documentation.

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

[Discuss-gnuradio] (no subject)

[Vishwanatha H G]

sir,...I needed the py code of low pass filter. please any one mail me
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio