Re: [Discuss-gnuradio] using uhd_fft with USRP1

[Activecat]

On Wed, Apr 30, 2014 at 4:17 AM, Martin Braun wrote:

> Hey Don,
>
> this is a bug in UHD, which is fixed on the current 'master'. If you're
> using 'master', you can simply update UHD and reinstall (git pull etc.).
>
> If you can't update for some reason right now, --wire-format=sc16 might
> help.
>
> Cheers,
> Martin
>


Unfortunately it becomes incompatible after the uhd update:

  RuntimeError:
  GR-UHD detected ABI compatibility mismatch with UHD library.
  GR-UHD was build against ABI: 3.7.0-0,
  but UHD library reports ABI: 3.7.1-0
  Suggestion: install an ABI compatible version of UHD,
  or rebuild GR-UHD component against this ABI version.

So, how to update the ABI, without a complete gnuradio rebuild ..?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] matplotlib runtime error

[Activecat]

On Mon, May 19, 2014 at 12:52 AM, Tom Rondeau  wrote:

> On Sun, May 18, 2014 at 9:00 AM, Marcus Müller 
> wrote:
>
>> Hi,
>> I think real-time and matplotlib kind of contradict in the first place -
>> really, matplotlib's performance is terrible. As a rule, it's Assisi
>> generally a bad idea to let your data file update your GUI. Usually, you
>> want something like a check every tenth of a second, if data has arrived,
>> and then updating your GUI accordingly. Otherwise, you will either end up
>> with refresh rates that are unnecessarily high (e.g. 200fps) or a GUI not
>> reacting to events (e.g. resizing) by redrawing. So that's two things bad
>> about your approach.
>>
>> As I explained, you'll have a hard time getting GUI to run in a block,
>> since by principle, GR blocks can not run in the main thread, and things
>> like Tim's qwt plot go through death, wind, fire and message passing to get
>> data out of the blocks' threads and into the GUI thread.
>>
>> Anyway, with matplotlib and pyqt to wrap the canvas in a qt application
>> and a little googling you can hack together guis that should work with the
>> qt generate option - no guarantee though. I'd rather get used to qwt in
>> most cases than stick with matplotlib...
>>
>> Greetings,
>> Marcus
>>
>
> I agree with Marcus. Don't try and use/abuse matplotlib for this purpose.
> I pointed to Tim's repo of PyQT/QWT blocks to show you how to use those
> tools to build GUIs in Python blocks.
>
> Tom
>


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

Re: [Discuss-gnuradio] mytx.cpp

[xianda]

Hello
I try to use the g++ to compile my code for example :tx.cpp.But where can i 
find the static library and dynamic library?
And the header :
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
Can someone help me to compile tx.cpp?Thank you very much.
g++ tx.cpp -I what -L what..???What command should i type into the shell?
Thank you.
Best regards

在 2014-05-14 02:01:40，"Tom Rondeau"  写道：

On Tue, May 13, 2014 at 1:00 PM, xianda  wrote:
Hello
  Thank you for your patience.
  And i run 3 steps:
  1.copy mytx.cpp to the uhd/host/example
  2.change the CMakeLists.txt on the uhd/host/example,and just:
SET(example_sources
benchmark_rate.cpp
network_relay.cpp
rx_multi_samples.cpp
rx_samples_to_file.cpp
rx_samples_to_udp.cpp
rx_timed_samples.cpp
test_dboard_coercion.cpp
test_messages.cpp
test_pps_input.cpp
test_timed_commands.cpp
transport_hammer.cpp
tx_bursts.cpp
tx_samples_from_file.cpp
tx_timed_samples.cpp
tx_waveforms.cpp
txrx_loopback_to_file.cpp
latency_test.cpp
fpgpio.cpp
mytx.cpp
)
   3. cd build
   cmake ..
   make
   This is right?

Another question:
   If i just write a cpp,what is the most convenient to run my .cpp 
document?To do something like up examples or by other ways?
Thank you very much.You help me a lot.
Best regards





Glad we could help, but you're really asking questions about compiling, code 
management, and cmake, which are not specific to GNU Radio. If someone here can 
help you and has the time to, great, but there's a ton of resources on the 
internet to help you understand these things.


Tom




 
At 2014-05-14 00:32:37,"Martin Braun"  wrote:
>On 13.05.2014 17:31, xianda wrote:
>> Hello
>> Thank you a lot.
>> 1.But now the header document in my tx.cpp is same as the
>> tx_waveforms.cpp.Now what should i do?How to change the CMakeList.txt?
>
>It's just a text file. Add your own file in there.
>
>> 2.I try to test.I copy the tx_waveforms.cpp to other catalogue.I try to
>> use the g++ to test,but it go wrong?Must i use the cmake?
>
>It definitely helps. If you manually compile, you might forget a -L or
>-I or whatever.
>
>M
>> Thank you.
>> Best regards
>>
>> 在 2014-05-13 22:47:34，"Tom Rondeau"  写道：
>>
>> On Tue, May 13, 2014 at 9:24 AM, xianda > > wrote:
>>
>> Hello
>>Thank you for your reply.
>>1.Because i just know a little about the cmake.If i
>> put my document into another folder,maybe i should write the
>> CMakeLists.txt.But if i put my document into the
>> uhd/host/examples,maybe i change a little of the
>> CMakeLists.txt.Is  it right?
>>
>>
>> Yes, cribbing from an existing file is an easy way to get started.
>> But this is really now a cmake issue, not a GNU Radio one. If
>> modifying an existing cmake file doesn't work or you need more help,
>> you'll have to study cmake a bit to work with it.
>>
>>2.Can you give me some advices  about my new transmit
>> document,namely,mytx.cpp?
>>3.What is the difference between gr-uhd and
>> uhd?Gr-uhd is just a part of UHD?Is it right?
>>Thank you very much.
>>
>>
>> gr-uhd is the wrapper around the library that allows it to fit into
>> and be used by GNU Radio. UHD is the external driver for the OS to
>> talk to USRP devices.
>>
>> Tom
>>
>> Best regards
>> 在 2014-05-13 16:02:57，"Martin Braun" > > 写道：
>>  >On 13.05.2014 09:35, 王先达 wrote:
>>  >>   Hello all
>>  >>I write a c++ document mytx.cpp and i place
>> it into the
>>  >> uhd/host/build/examples.And then what should i do to let it
>> run?Should i
>>  >> type the "make" command in the shell or do other
>> things?Thank you.
>>  >> Best regards,
>>  >> Xianda
>>  >
>>  >You don't have to put it in examples, but you can use the
>> CMakeLists.txt
>>  >file in this directory to figure out how to set up a build
>> environment.
>>  >
>>  >The usual flow of cmake, make will compile your program then.
>>  >
>>  >Martin
>>  >
>>  >
>>  >___
>>  >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/

Re: [Discuss-gnuradio] receive sensitivity of B200

[Marcus D. Leech]

On 05/18/2014 05:49 PM, Robert Light wrote:

Hi, I use B200 with OpenBTS at 900MHz. I get very low range (about 10m only) 
and I identified that this is due to receive channel in B200. Changing rxgain 
between 0 and 70dB makes vey little difference. Does anyone know how the 
receive sensitivity of B200 compare with, for example, WBX?
What could be the reason for this low sensitivity? uhd_fft spectrum looks  
"normal" , in the sense that I do not suspect a broken LNA.

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


Are you on the correct antenna port?

The B2xx RF section is roughly the same noise figure and total gain as a 
WBX.




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


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

[Discuss-gnuradio] receive sensitivity of B200

[Robert Light]

Hi, I use B200 with OpenBTS at 900MHz. I get very low range (about 10m only) 
and I identified that this is due to receive channel in B200. Changing rxgain 
between 0 and 70dB makes vey little difference. Does anyone know how the 
receive sensitivity of B200 compare with, for example, WBX?
What could be the reason for this low sensitivity? uhd_fft spectrum looks  
"normal" , in the sense that I do not suspect a broken LNA.

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

Re: [Discuss-gnuradio] Socket PDU

[zielalaoui]

Hi sara,
For your problem of the empty file sink. What did you use exactly, as
blocks, between the file source and the file sink?



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Socket-PDU-tp48297p48298.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] Socket PDU

[Sara Chérif]

Hello ,
I have 2 questions, please:
1- If I put a vector source as input or file source & I choose " No repeat"
for the input , I find that no output is written in file sink ! why ?
2- I want to receive real time voice packets from an application running on
another lap which is connected to the second lap (which has GNU Radio.)
using Ethernet Cable.
First : I found a block " socket PDU" in GNU Radio , if I used it , Do I
need to write the code of socket (client & server) ?
Second : I write IP of 1st lap & the port number used by the application in
the UDP Third  : I connected 3 blocks : " UDP source " then "socket PDU "
then "PDU to stream tagged" , I don't know why I have an error in the
connection of UDP source & socket PDU ! Please tell me what is the problem
?(as the arrow is red)
Thanks :)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] matplotlib runtime error

[Tom Rondeau]

On Sun, May 18, 2014 at 9:00 AM, Marcus Müller wrote:

> Hi,
> I think real-time and matplotlib kind of contradict in the first place -
> really, matplotlib's performance is terrible. As a rule, it's Assisi
> generally a bad idea to let your data file update your GUI. Usually, you
> want something like a check every tenth of a second, if data has arrived,
> and then updating your GUI accordingly. Otherwise, you will either end up
> with refresh rates that are unnecessarily high (e.g. 200fps) or a GUI not
> reacting to events (e.g. resizing) by redrawing. So that's two things bad
> about your approach.
>
> As I explained, you'll have a hard time getting GUI to run in a block,
> since by principle, GR blocks can not run in the main thread, and things
> like Tim's qwt plot go through death, wind, fire and message passing to get
> data out of the blocks' threads and into the GUI thread.
>
> Anyway, with matplotlib and pyqt to wrap the canvas in a qt application
> and a little googling you can hack together guis that should work with the
> qt generate option - no guarantee though. I'd rather get used to qwt in
> most cases than stick with matplotlib...
>
> Greetings,
> Marcus
>

I agree with Marcus. Don't try and use/abuse matplotlib for this purpose. I
pointed to Tim's repo of PyQT/QWT blocks to show you how to use those tools
to build GUIs in Python blocks.

Tom



> On May 18, 2014 2:25:00 PM CEST, Activecat  wrote:
>
>> On Fri, May 2, 2014 at 8:56 PM, Tom Rondeau  wrote:
>>
>>> On Fri, May 2, 2014 at 8:49 AM, Marcus Müller 
>>> wrote:
>>>
 Hi Activecat,

 typical GUI problem; background is that X applications are inherently
 hard to multithread, which basically requires graphical toolkits to run in
 a main loop. This conflicts with every block being run in its own thread.

 The easiest solution nowadays should be that you generate a QT flow
 graph in GRC, use PyQT to generate your GUI, register a message handler and
 integrate matplotlib (there are examples out there, just don't have one at
 my fingertips right now), and use the message passing interface to get data
 out of your flow graph into your GUI.

 Greetings,
 Marcus

>>>
>>> Tim's written a number of blocks like this:
>>> https://github.com/osh/gr-pyqt
>>>
>>> Tom
>>>
>>
>>
>>
>> The examples (https://github.com/osh/gr-pyqt) are using Qt and Qwt to
>> plot graphs, not matplotlib.
>> (When all the "import pylab" are removed, everything still work as usual,
>> except for pylab.fftshift ).
>>
>> In order to stick to matplotlib, I created a custom block, register a
>> message handler, and use the message passing interface to get data out from
>> the flowgraph into the custom block. (Everything is as described by Marcus
>> as above, except I do not use QT.)
>> For this flowgraph, Generate-Option="No GUI"
>>
>> When I put "self.axes1.figure.canvas.draw()"  or  "pyplot.draw()"  in the
>> message handler, the same error still happens:
>> ERROR: handler caught exception: main thread is not in main loop
>>
>> Question:
>> How to get rid of this error?
>> Or, does this mean plotting using matplotlib is not an option ..?
>>
>> My objective is to plot graphs in realtime using matplotlib.
>> I try to stick to Matplotlib because it is the tool I that I am using for
>> numerical analysis.
>>
>>
>>
>> The custom block is coded as:
>>
>> #!/usr/bin/env python
>> # -*- coding: utf-8 -*-
>>
>> import numpy
>> from gnuradio import gr
>>
>> import pmt
>> from matplotlib import pyplot
>>
>>
>> class matplotlib4(gr.sync_block):
>>
>> def __init__(self):
>> gr.sync_block.__init__(self,
>> name="matplotlib4",
>> in_sig=None,
>> out_sig=None)
>>
>> pyplot.ion()
>> self.fig1 = pyplot.figure()
>> self.ax1 = self.fig1.add_subplot(2,1,1)
>> self.ax1.set_ylabel('Real')
>> self.ax1.set_xlabel('time')
>> self.ax1.set_ylim(-1.2, 1.2)
>> self.ax1.grid(True)
>> self.line1, = self.ax1.plot( [0.3]*1000 )
>> self.line2, = self.ax1.plot( [0.3]*1000 )
>> self.axes1 = pyplot.gca()
>> pyplot.draw()   # no error of "main thread is not in main
>> loop"
>> pyplot.show()   # no error of "main thread is not in main
>> loop"
>>
>> self.message_port_register_in( pmt.intern("cpdus"))
>> self.set_msg_handler(pmt.intern("cpdus"), self.handler4)
>>
>>
>> def handler4( self, msg ):
>> samples = pmt.cdr(msg)
>> data = numpy.array( pmt.c32vector_elements(samples),
>> dtype=numpy.complex64 )
>>
>> self.line1.set_ydata( data.real )
>> self.line2.set_ydata( data.imag )
>> #self.fig1.canvas.draw()  

Re: [Discuss-gnuradio] matplotlib runtime error

[Marcus Müller]

Hi,
I think real-time and matplotlib kind of contradict in the first place - 
really, matplotlib's performance is terrible. As a rule, it's Assisi generally 
a bad idea to let your data file update your GUI. Usually, you want something 
like a check every tenth of a second, if data has arrived, and then updating 
your GUI accordingly. Otherwise, you will either end up with refresh rates that 
are unnecessarily high (e.g. 200fps) or a GUI not reacting to events (e.g. 
resizing) by redrawing. So that's two things bad about your approach.

As I explained, you'll have a hard time getting GUI to run in a block, since by 
principle, GR blocks can not run in the main thread, and things like Tim's qwt 
plot go through death, wind, fire and message passing to get data out of the 
blocks' threads and into the GUI thread.

Anyway, with matplotlib and pyqt to wrap the canvas in a qt application and a 
little googling you can hack together guis that should work with the qt 
generate option - no guarantee though. I'd rather get used to qwt in most cases 
than stick with matplotlib...

Greetings,
Marcus


On May 18, 2014 2:25:00 PM CEST, Activecat  wrote:
>On Fri, May 2, 2014 at 8:56 PM, Tom Rondeau  wrote:
>
>> On Fri, May 2, 2014 at 8:49 AM, Marcus Müller
>wrote:
>>
>>> Hi Activecat,
>>>
>>> typical GUI problem; background is that X applications are
>inherently
>>> hard to multithread, which basically requires graphical toolkits to
>run in
>>> a main loop. This conflicts with every block being run in its own
>thread.
>>>
>>> The easiest solution nowadays should be that you generate a QT flow
>graph
>>> in GRC, use PyQT to generate your GUI, register a message handler
>and
>>> integrate matplotlib (there are examples out there, just don't have
>one at
>>> my fingertips right now), and use the message passing interface to
>get data
>>> out of your flow graph into your GUI.
>>>
>>> Greetings,
>>> Marcus
>>>
>>
>> Tim's written a number of blocks like this:
>> https://github.com/osh/gr-pyqt
>>
>> Tom
>>
>
>
>
>The examples (https://github.com/osh/gr-pyqt) are using Qt and Qwt to
>plot
>graphs, not matplotlib.
>(When all the "import pylab" are removed, everything still work as
>usual,
>except for pylab.fftshift ).
>
>In order to stick to matplotlib, I created a custom block, register a
>message handler, and use the message passing interface to get data out
>from
>the flowgraph into the custom block. (Everything is as described by
>Marcus
>as above, except I do not use QT.)
>For this flowgraph, Generate-Option="No GUI"
>
>When I put "self.axes1.figure.canvas.draw()"  or  "pyplot.draw()"  in
>the
>message handler, the same error still happens:
>ERROR: handler caught exception: main thread is not in main loop
>
>Question:
>How to get rid of this error?
>Or, does this mean plotting using matplotlib is not an option ..?
>
>My objective is to plot graphs in realtime using matplotlib.
>I try to stick to Matplotlib because it is the tool I that I am using
>for
>numerical analysis.
>
>
>
>The custom block is coded as:
>
>#!/usr/bin/env python
># -*- coding: utf-8 -*-
>
>import numpy
>from gnuradio import gr
>
>import pmt
>from matplotlib import pyplot
>
>
>class matplotlib4(gr.sync_block):
>
>def __init__(self):
>gr.sync_block.__init__(self,
>name="matplotlib4",
>in_sig=None,
>out_sig=None)
>
>pyplot.ion()
>self.fig1 = pyplot.figure()
>self.ax1 = self.fig1.add_subplot(2,1,1)
>self.ax1.set_ylabel('Real')
>self.ax1.set_xlabel('time')
>self.ax1.set_ylim(-1.2, 1.2)
>self.ax1.grid(True)
>self.line1, = self.ax1.plot( [0.3]*1000 )
>self.line2, = self.ax1.plot( [0.3]*1000 )
>self.axes1 = pyplot.gca()
>  pyplot.draw()   # no error of "main thread is not in main
>loop"
>  pyplot.show()   # no error of "main thread is not in main
>loop"
>
>self.message_port_register_in( pmt.intern("cpdus"))
>   self.set_msg_handler(pmt.intern("cpdus"), self.handler4)
>
>
>def handler4( self, msg ):
>samples = pmt.cdr(msg)
>data = numpy.array( pmt.c32vector_elements(samples),
>dtype=numpy.complex64 )
>
>self.line1.set_ydata( data.real )
>self.line2.set_ydata( data.imag )
>#self.fig1.canvas.draw()   # handler caught
>exception: main thread is not in main loop
>#pyplot.draw() # handler caught
>exception: main thread is not in main loop
>#self.axes1.figure.canvas.draw()   # handler caught
>exception: main thread is not in main loop
>print "handler4(): x.size={}".format( data.size )
>
>
>def work(self, input_items, output_items):
>