[Discuss-gnuradio] Enable QT multi threading in the qtgui template

[Sylvain Munaut]

Hi,

In my quest to implement some OOT GUI widgets, I was hit by a number
of crashes because I need to do rendering (which includes some X/xcb
calls) from another thread than the main GUI thread.

Now, under QT it's documented how to do it and it's fairly painless
_except_ that if you're under linux and using X11, you need to call
XInitThreads() before doing any GUI stuff (so before creating the
QApplication for instance).

My current solution is to add this before creating the QApplication :

if os.name == 'posix':
x11 = ctypes.cdll.LoadLibrary('libX11.so')
if x11:
x11.XInitThreads()

Does anyone see a better solution ?

Does that stand any chance of getting merged ?

Cheers,

Sylvain

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

[Discuss-gnuradio] Fwd: About setting the GRC block properties.

[Kevin]

Morning,

Sorry for taking so long to reply.

I have one question,
the block, "OFDM Mod"   <->  and these three, "OFDM Carrier
Allocator, FFT, OFDM Cyclic Prefixer",
shown on the website, http://gnuradio.org/doc/doxygen/ofdm_tx_core.png

Are they doing the same thing?

Thanks






-- Forwarded message --
From: Martin Braun (CEL) 
Date: Fri, Sep 20, 2013 at 6:08 PM
Subject: Re: [Discuss-gnuradio] About setting the GRC block properties.
To: GNURadio Discussion List 


On Fri, Sep 20, 2013 at 01:45:46PM -0500, Kevin wrote:
> "Virtual source" block shows "pre-ofdm", which means I need to create some
> blocks like "Virtual sink" labeled "pre-ofdm" before this?

Don't worry about these blocks, they are just to make the Figures look
complete (or rather, to label the inputs).

> "I think you just need brackets around the carrier allocation table.
> Also, use Python's range() to make stuff more readable."
>
>
> Can you explain it more specifically?
>
> bracket at which section?

You need more (). The carrier tables are vectors of vectors ((...), ...).
>
> "python's range()" I have no idea what this is?

Look up the range() function in Python.

MB

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

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


pgpnpfi6zwRXH.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: About setting the GRC block properties.

[Marcus Müller]

Hi Kevin,

no, they are not the same.
In the ofdm mod XML file (gr-digital/grc/digital_ofdm_mod.xml), the make 
element is:

grc_blks2.packet_mod_$(type.fcn)(digital.ofdm_mod(
options=grc_blks2.options(
modulation="$modulation",
fft_length=$fft_length,
occupied_tones=$occupied_tones,
cp_length=$cp_length,
pad_for_usrp=$pad_for_usrp,
log=None,
verbose=None,
),
),
payload_length=$payload_length,
)

So, OFDM mod is basically a packet encoder, which internally is a 
message queue based approach to managing packets.
This is nice, because internally digital.ofdm_mod has a send_pkt method 
that encodes your message, enabling it to work asynchronously, it 
generates a sync-friendly, preambling, data-encoding framework,
so it's a user-friendly data->symbols->preamble+symbols->ifft->cyclic 
prefixer->normalizer hier block,
while ofdm_tx_core.png only shows the very basic princible of generating 
OFDM signals in GNU Radio.


Hope I was of a little assistance,
Marcus



Morning,

Sorry for taking so long to reply.

I have one question,
the block, "OFDM Mod"   <->  and these three, "OFDM Carrier 
Allocator, FFT, OFDM Cyclic Prefixer",

shown on the website, http://gnuradio.org/doc/doxygen/ofdm_tx_core.png

Are they doing the same thing?

Thanks






-- Forwarded message --
From: *Martin Braun (CEL)* >

Date: Fri, Sep 20, 2013 at 6:08 PM
Subject: Re: [Discuss-gnuradio] About setting the GRC block properties.
To: GNURadio Discussion List >



On Fri, Sep 20, 2013 at 01:45:46PM -0500, Kevin wrote:
> "Virtual source" block shows "pre-ofdm", which means I need to 
create some

> blocks like "Virtual sink" labeled "pre-ofdm" before this?

Don't worry about these blocks, they are just to make the Figures look
complete (or rather, to label the inputs).

> "I think you just need brackets around the carrier allocation table.
> Also, use Python's range() to make stuff more readable."
>
>
> Can you explain it more specifically?
>
> bracket at which section?

You need more (). The carrier tables are vectors of vectors ((...), ...).
>
> "python's range()" I have no idea what this is?

Look up the range() function in Python.

MB

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790 
Fax: +49 721 608-46071 
www.cel.kit.edu 

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

___
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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tb.start(), tb.wait() or tb.stop() dows not work ... help

[Tom Rondeau]

On Mon, Sep 23, 2013 at 8:07 PM, shakib034  wrote:
> I am new to GNURADIO environment.
>
> I want the flow graph that i am working with to turn ON and OFF with 5 sec
> of interval.
>
> I tried  tb.start(), tb.wait(), tb.stop() and sleep(5).
>
> But that is not working.
>
> whenever I try to replace "tb.Run(True)" with any thing the program does not
> work.
>
> Any suggestion will be greatly appreciated.
>
> Thanks.

You probably don't want to be toggling the flowgraph on and off
constantly like this, anyways. That's a very inexact way of handling
it. You'll want some kind of gating block that handles this more
appropriately.

But regardless, you're method for doing this wouldn't work, anyways,
since you have the order wrong. The start function is a non-blocking
call that starts the flowgraph working. The wait is a blocking call
that sits there and waits for the flowgraph to finish. In your code,
you're never getting past the wait stage. You'd want this instead:

tb.start()
sleep(5)   # Let the flowgraph run for some amount of time.
tb.stop()
tb.wait()   # not really necessary, but makes sure the stop() call
propagates to all blocks before moving on.
sleep(5)   # wait 5 seconds before doing anything (like in a while loop)

Like I said, this isn't the best way to be accurate about how long
things run and stop for, but it'll get you in the right direction.

-- 
Tom
GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

Re: [Discuss-gnuradio] Addding enums to custom processing blocks

[Tom Rondeau]

On Tue, Sep 24, 2013 at 9:26 AM, John Wilson  wrote:
> Hi,
>
> What's the process by which enums are added to the Python namespace via SWIG
> in gnuradio? I mean in gr_firdes, the following are added to the gr.firdes
> namespace in Python:
>
>   enum win_type {
> WIN_HAMMING = 0,// max attenuation 53 dB
> WIN_HANN = 1,// max attenuation 44 dB
> WIN_BLACKMAN = 2,// max attenuation 74 dB
> WIN_RECTANGULAR = 3,
> WIN_KAISER = 4, // max attenuation variable with beta, google it
> WIN_BLACKMAN_hARRIS = 5,
>   };
>
> But I can't seem to get it to work with my code?
>
> Cheers,
>
> John

Which version of GNU Radio are you using? That'll make a difference on
how easy it is to set this up.

In 3.7, we declare the enum inside of the gr::filter namespace. In the
filter_swig.i file, the firdes.h header is included using both the C++
and Swig methods to makes sure everything in it is read and processed
properly.

%{
#include "gnuradio/filter/firdes.h"
%}

%include "gnnuradio/filter/firdes.h"

If you're running 3.6, you can do similar. But check how gr_firdes.i
is written such that it redeclares the enum in SWIG.

-- 
Tom
GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

Re: [Discuss-gnuradio] Enable QT multi threading in the qtgui template

[Tom Rondeau]

On Wed, Sep 25, 2013 at 11:39 AM, Sylvain Munaut <246...@gmail.com> wrote:
> Hi,
>
> In my quest to implement some OOT GUI widgets, I was hit by a number
> of crashes because I need to do rendering (which includes some X/xcb
> calls) from another thread than the main GUI thread.
>
> Now, under QT it's documented how to do it and it's fairly painless
> _except_ that if you're under linux and using X11, you need to call
> XInitThreads() before doing any GUI stuff (so before creating the
> QApplication for instance).
>
> My current solution is to add this before creating the QApplication :
>
> if os.name == 'posix':
> x11 = ctypes.cdll.LoadLibrary('libX11.so')
> if x11:
> x11.XInitThreads()
>
> Does anyone see a better solution ?
>
> Does that stand any chance of getting merged ?
>
> Cheers,
>
> Sylvain

Sylvain,

Have you solved your problem from yesterday with the OOT project
inheriting from the QTGUI blocks? Basically, it should be possible (at
least, I want it to be possible), but it's probably never been done
before. I have tried to make sure everything's been exported from
libgnuradio-qtgui to enable this, but I've never actually tried it.

And obviously, any patches you needed to make to the qtgui library for
this should go back into the main code to help this work better in the
future.

As to the posix/X11 issue. We do some similar stuff elsewhere for
different platform support, though mostly this is in the Cmake files.
It's not out of the question what you've done. We'd have to look at it
in the bigger picture. Your checks around it look good, though, so it
seems harmless enough. I'm guessing that ctypes.cdll.LoadLibrary
returns None if libX11.so isn't found?


-- 
Tom
GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

Re: [Discuss-gnuradio] Enable QT multi threading in the qtgui template

[Sylvain Munaut]

Hi,

> Have you solved your problem from yesterday with the OOT project
> inheriting from the QTGUI blocks?

No unfortunately. I made some progress though :
 - The QObject parent must be first in the inheritance.
 - Needed to include the Q_OBJECT macro in the class definition and
also enable the "AutoMOC" in the CMakeFile.txt
 - Return a dynamic_casted pointer to QWidget* in pyqwidget() method
rather than just "this".

Now it runs fine and just crashes on cleanup/shutdown.

Whenever a QWidget is added to a parent, the parent takes ownership of
the pointer and so it will be deleted when deleting the parent. Then
it will be deleted as part of GR, so that's the first issue.

But here I don't even seem to get to that point because the destructor
is called only once (I have a printf in it) and it still crashes ...
The Qt magic might be interfering with the SWIG magic ...


I also tried creating the QWidget subclass separately, like it's done
in the qtgui elements but I also have a problem on destruction because
there is a tight link between the two (exchanging a lot of data ..)
and they're destroyed independently by two completely different path
...
And it's also not such a nice solution because of the many
interactions needed between the two classes it'd be much better to
have one single object be a descendant of both QGLWidget and
gr_sync_block


> Basically, it should be possible (at
> least, I want it to be possible), but it's probably never been done
> before. I have tried to make sure everything's been exported from
> libgnuradio-qtgui to enable this, but I've never actually tried it.

Well in this case I'm not really extending a qtgui block, just adding
a new one that has to integrate with the 'top level' of the existing
ones.


> And obviously, any patches you needed to make to the qtgui library for
> this should go back into the main code to help this work better in the
> future.

For QT the only mod will probably be the multithread thing.
For WX on the other hand I'm still not sure how to make it work at all
and what kind of changes this would require.

But yeah, I definitely want this to work with an "out of the box" GR
and to get any required changes merged.


> As to the posix/X11 issue. We do some similar stuff elsewhere for
> different platform support, though mostly this is in the Cmake files.
> It's not out of the question what you've done. We'd have to look at it
> in the bigger picture. Your checks around it look good, though, so it
> seems harmless enough. I'm guessing that ctypes.cdll.LoadLibrary
> returns None if libX11.so isn't found?

Actually I though so, but under further checks it throws an OSError
exception so it would probably need to be wrapped in try catch.

Cheers,

Sylvain

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

Re: [Discuss-gnuradio] dual coherent channel rtl_sdr

[Marcus Leech]

Hmmm, interesting.Was this with E4000 tuners, or R820T tuners?
 
What was your exact test setup, tuned-frequency, etc?
 
 
 
on Sep 25, 2013, Juha Vierinen  wrote:

Hi guys,
 
Based on my very limited understanding on electronics, osclilators and other such things, I would expect oscillator effects to cancel out when looking at the relative phase of two channels. I would expect the phase jitter on the relative phase to be dominated by what happens in the ADC and the digital down conversion. That is why I am running the two dongles off the same clock.  
 
I have some measurements of the relative IQ signal (z_1/z_2) at 100 kHz, 10 Hz, and 1 Hz sample rates. I did a power spectrum estimate using a Hanning window to look at relative phase noise. I didn't do any incoherent averaging on any of these, so there is some statistical noise. I only see some "imperfections" in the 10 Hz and 1 Hz spectrum.  However, I see these kinds of effects in 100 times more expensive receivers too. For my purposes, the relative phase behaviour of the two channels is good enough. 
 
I have attached the spectra. I have also attached the 1 Hz IQ signal, which shows a small systematic wiggle, but very little phase difference between the two channels.
 
The samples also are aligned over two hours of sampling, which means that there cannot really be a very large amount of clock drift between the two systems.
 
Sure, the thing has it's faults. But with $16, you really can't beat the price. 
 
juha


On Wed, Sep 25, 2013 at 1:21 AM, Marcus D. Leech  wrote:
On 09/25/2013 12:04 AM, Jared Clements wrote:
 Hi Marcus,  Interesting discussion. I was wondering how well synchronized clocking might work.  Was hoping it would work better than it sounds.  Could you quantify the level of phase noise you're seeing, like with a power spectral density  plot?  Just for curiosity's sake?  I know of a recently updated OOT module that should have the blocks you need ;-)  I was hoping to build a correlating interferometer by modifying several of these dongles to run off the same clock.  I may need to rethink the plan.  Jared 
I'll get to that tomorrow night.  I just ran a simulation of what I was observing (just because the lab is downstairs, and I'm upstairs).  Looks like the best it does is about -40dB/c  75kHz from the carrier.  That's bluddy awful.   ___ 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] Fwd: About setting the GRC block properties.

[Kevin]

Thanks Marcus,

I am thinking to use "Random source" generating 010101..as source.
If I wanna modify the transmit diagram based on
http://gnuradio.org/doc/doxygen/ofdm_tx_core.pn
g
What would you suggest? Can you show me the block diagrams
for me to create the blocks before ofdm_rx_core.png, "Virtual source ->
OFDM Carrier Allocator -> FFT -> OFDM Cyclic Prefixer"
Am I right like creating "Random Source -> OFDM Mod -> Virtual sink"
Will it conflict between "OFDM Mod" and "Cyclic Prefixer"?
Or my thought is totally wrong!


Sincerely,


On Wed, Sep 25, 2013 at 11:45 AM, Marcus Müller  wrote:

>  Hi Kevin,
>
> no, they are not the same.
> In the ofdm mod XML file (gr-digital/grc/digital_ofdm_mod.xml), the make
> element is:
> grc_blks2.packet_mod_$(type.fcn)(digital.ofdm_mod(
> options=grc_blks2.options(
> modulation="$modulation",
> fft_length=$fft_length,
> occupied_tones=$occupied_tones,
> cp_length=$cp_length,
> pad_for_usrp=$pad_for_usrp,
> log=None,
> verbose=None,
> ),
> ),
> payload_length=$payload_length,
> )
>
> So, OFDM mod is basically a packet encoder, which internally is a message
> queue based approach to managing packets.
> This is nice, because internally digital.ofdm_mod has a send_pkt method
> that encodes your message, enabling it to work asynchronously, it generates
> a sync-friendly, preambling, data-encoding framework,
> so it's a user-friendly  data->symbols->preamble+symbols->ifft->cyclic
> prefixer->normalizer hier block,
> while ofdm_tx_core.png only shows the very basic princible of generating
> OFDM signals in GNU Radio.
>
> Hope I was of a little assistance,
> Marcus
>
>
>  Morning,
>
>  Sorry for taking so long to reply.
>
> I have one question,
> the block, "OFDM Mod"   <->  and these three, "OFDM Carrier
> Allocator, FFT, OFDM Cyclic Prefixer",
> shown on the website, http://gnuradio.org/doc/doxygen/ofdm_tx_core.png
>
>  Are they doing the same thing?
>
>  Thanks
>
>
>
>
>
>
> -- Forwarded message --
> From: Martin Braun (CEL) 
> Date: Fri, Sep 20, 2013 at 6:08 PM
> Subject: Re: [Discuss-gnuradio] About setting the GRC block properties.
> To: GNURadio Discussion List 
>
>
> On Fri, Sep 20, 2013 at 01:45:46PM -0500, Kevin wrote:
> > "Virtual source" block shows "pre-ofdm", which means I need to create
> some
> > blocks like "Virtual sink" labeled "pre-ofdm" before this?
>
>  Don't worry about these blocks, they are just to make the Figures look
> complete (or rather, to label the inputs).
>
> > "I think you just need brackets around the carrier allocation table.
> > Also, use Python's range() to make stuff more readable."
> >
> >
> > Can you explain it more specifically?
> >
> > bracket at which section?
>
>  You need more (). The carrier tables are vectors of vectors ((...), ...).
> >
> > "python's range()" I have no idea what this is?
>
>  Look up the range() function in Python.
>
> MB
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Python-based sink block causes graph freeze under certain conditions

[Ethan Trewhitt]

I created a Python-based sink block that works well in most cases. I
started having problems when I created a GUI checkbox (using GRC) to
control a Selector or Valve block in a separate subgraph. As soon as I
change the checkbox, the whole graph freezes.

So far I have tracked this down to the Python sink block. I grabbed
one of the built-in blocks and build a test that demonstrates the
problem in the simplest way. The graph looks like this (there are two
separate subgraphs):

Subgraph 1:
Constant Source #1 -> Throttle -> Python test sink

Subgraph 2:
Constant Source #2 -> Selector -> Throttle -> Null sink
Constant Source #3 -> ^   (points to the selector, also)

The checkbox switches the selector between Constant Source #2 and #3.
Whenever the Python test sink is part of the upper graph, switching
the lower graph (using the checkbox) causes everything to freeze.

Debugging steps:

I ran this graph via GDB and watched threads being created/destroyed.
Whenever the checkbox is changed, a bunch of threads are killed. I'm
guessing this is GR shutting down a bunch of blocks and trying to
restart them with different connections, but something in the Python
block isn't getting shut down, so everything stalls.

In the code below, if you replace the reference to "self.sink" with
"self.blocks_null_sink_1" in the connection setup, the problem goes
away.

Here's the code:


#!/usr/bin/env python

from gnuradio import blocks
from gnuradio import gr
from gnuradio.wxgui import forms
from grc_gnuradio import blks2 as grc_blks2
from grc_gnuradio import wxgui as grc_wxgui
import numpy

import wx

class sink_test(grc_wxgui.top_block_gui):

def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title="Sink Test")
self.check = check = True

##
# Blocks
##
self._check_check_box = forms.check_box(
parent=self.GetWin(),
value=self.check,
callback=self.set_check,
label="check",
true=True,
false=False,
)
self.Add(self._check_check_box)
self.const_source_x_0_1 = gr.sig_source_c(0, gr.GR_CONST_WAVE, 0, 0, 12)
self.const_source_x_0_0 = gr.sig_source_c(0, gr.GR_CONST_WAVE, 0, 0, 0)
self.const_source_x_0 = gr.sig_source_f(0, gr.GR_CONST_WAVE, 0, 0, 0)
self.blocks_throttle_0 = blocks.throttle(gr.sizeof_float*1, 1000)
self.blocks_throttle_1 = blocks.throttle(gr.sizeof_gr_complex*1, 1000)
self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_gr_complex*1)
self.blocks_null_sink_1 = blocks.null_sink(gr.sizeof_float*1)
 # not used by default. enable by connecting below
self.blks2_selector_0 = grc_blks2.selector(
item_size=gr.sizeof_gr_complex*1,
num_inputs=2,
num_outputs=1,
input_index=0 if check else 1,
output_index=0,
)
self.sink = test_sink()

##
# Connections
##
self.connect((self.const_source_x_0, 0), (self.blocks_throttle_0, 0))
self.connect((self.blocks_throttle_0, 0), (self.sink, 0))
   # change this from self.sink to self.blocks_null_sink_1 to see the
problem go away
self.connect((self.const_source_x_0_0, 0), (self.blks2_selector_0, 1))
self.connect((self.blks2_selector_0, 0), (self.blocks_throttle_1, 0))
self.connect((self.blocks_throttle_1, 0), (self.blocks_null_sink_0, 0))
self.connect((self.const_source_x_0_1, 0), (self.blks2_selector_0, 0))


def get_check(self):
return self.check

def set_check(self, check):
self.check = check
self._check_check_box.set_value(self.check)
self.blks2_selector_0.set_input_index(int(0 if self.check else 1))

# Python block
class test_sink(gr.sync_block):
def __init__(self):
gr.sync_block.__init__(
self,
name = "test_sink",
in_sig = [numpy.float32],
out_sig = None,
)
self.key = None

def work(self, input_items, output_items):
return len(input_items[0])

if __name__ == '__main__':
tb = sink_test()
tb.Run(True)

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

Re: [Discuss-gnuradio] Python-based sink block causes graph freeze under certain conditions

[Ethan Trewhitt]

Apologies - this bug has been found already:
http://gnuradio.org/redmine/issues/594

I tracked down the freeze to the "unlock()" call in selector.py, which
led me to the bug report. Hope it gets fixed soon :)

Until then, no graph changes!

On Wed, Sep 25, 2013 at 5:08 PM, Ethan Trewhitt  wrote:
> I created a Python-based sink block that works well in most cases. I
> started having problems when I created a GUI checkbox (using GRC) to
> control a Selector or Valve block in a separate subgraph. As soon as I
> change the checkbox, the whole graph freezes.
>
> So far I have tracked this down to the Python sink block. I grabbed
> one of the built-in blocks and build a test that demonstrates the
> problem in the simplest way. The graph looks like this (there are two
> separate subgraphs):
>
> Subgraph 1:
> Constant Source #1 -> Throttle -> Python test sink
>
> Subgraph 2:
> Constant Source #2 -> Selector -> Throttle -> Null sink
> Constant Source #3 -> ^   (points to the selector, also)
>
> The checkbox switches the selector between Constant Source #2 and #3.
> Whenever the Python test sink is part of the upper graph, switching
> the lower graph (using the checkbox) causes everything to freeze.
>
> Debugging steps:
>
> I ran this graph via GDB and watched threads being created/destroyed.
> Whenever the checkbox is changed, a bunch of threads are killed. I'm
> guessing this is GR shutting down a bunch of blocks and trying to
> restart them with different connections, but something in the Python
> block isn't getting shut down, so everything stalls.
>
> In the code below, if you replace the reference to "self.sink" with
> "self.blocks_null_sink_1" in the connection setup, the problem goes
> away.
>
> Here's the code:
>
>
> #!/usr/bin/env python
>
> from gnuradio import blocks
> from gnuradio import gr
> from gnuradio.wxgui import forms
> from grc_gnuradio import blks2 as grc_blks2
> from grc_gnuradio import wxgui as grc_wxgui
> import numpy
>
> import wx
>
> class sink_test(grc_wxgui.top_block_gui):
>
> def __init__(self):
> grc_wxgui.top_block_gui.__init__(self, title="Sink Test")
> self.check = check = True
>
> ##
> # Blocks
> ##
> self._check_check_box = forms.check_box(
> parent=self.GetWin(),
> value=self.check,
> callback=self.set_check,
> label="check",
> true=True,
> false=False,
> )
> self.Add(self._check_check_box)
> self.const_source_x_0_1 = gr.sig_source_c(0, gr.GR_CONST_WAVE, 0, 0, 
> 12)
> self.const_source_x_0_0 = gr.sig_source_c(0, gr.GR_CONST_WAVE, 0, 0, 
> 0)
> self.const_source_x_0 = gr.sig_source_f(0, gr.GR_CONST_WAVE, 0, 0, 0)
> self.blocks_throttle_0 = blocks.throttle(gr.sizeof_float*1, 1000)
> self.blocks_throttle_1 = blocks.throttle(gr.sizeof_gr_complex*1, 1000)
> self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_gr_complex*1)
> self.blocks_null_sink_1 = blocks.null_sink(gr.sizeof_float*1)
>  # not used by default. enable by connecting below
> self.blks2_selector_0 = grc_blks2.selector(
> item_size=gr.sizeof_gr_complex*1,
> num_inputs=2,
> num_outputs=1,
> input_index=0 if check else 1,
> output_index=0,
> )
> self.sink = test_sink()
>
> ##
> # Connections
> ##
> self.connect((self.const_source_x_0, 0), (self.blocks_throttle_0, 0))
> self.connect((self.blocks_throttle_0, 0), (self.sink, 0))
># change this from self.sink to self.blocks_null_sink_1 to see the
> problem go away
> self.connect((self.const_source_x_0_0, 0), (self.blks2_selector_0, 1))
> self.connect((self.blks2_selector_0, 0), (self.blocks_throttle_1, 0))
> self.connect((self.blocks_throttle_1, 0), (self.blocks_null_sink_0, 
> 0))
> self.connect((self.const_source_x_0_1, 0), (self.blks2_selector_0, 0))
>
>
> def get_check(self):
> return self.check
>
> def set_check(self, check):
> self.check = check
> self._check_check_box.set_value(self.check)
> self.blks2_selector_0.set_input_index(int(0 if self.check else 1))
>
> # Python block
> class test_sink(gr.sync_block):
> def __init__(self):
> gr.sync_block.__init__(
> self,
> name = "test_sink",
> in_sig = [numpy.float32],
> out_sig = None,
> )
> self.key = None
>
> def work(self, input_items, output_items):
> return len(input_items[0])
>
> if __name__ == '__main__':
> tb = sink_test()
> tb.Run(True)

___
Discuss-gnuradio mailing list
Discuss-gnuradio@g

Re: [Discuss-gnuradio] Enable QT multi threading in the qtgui template

[Sylvain Munaut]

> I also tried creating the QWidget subclass separately, like it's done
> in the qtgui elements but I also have a problem on destruction because
> there is a tight link between the two (exchanging a lot of data ..)
> and they're destroyed independently by two completely different path
> ...

Ah, at least I found how to deal with that.

The default top level generated by GRC does something like this :

qapp = Qt.QApplication(sys.argv)
tb = top_block()
tb.start()
tb.show()
qapp.exec_()
tb.stop()
tb = None

Now the problem is that the Qt stuff will start to get cleaned up
before all the block stop() methods have run and so some processing
might still be going on while some Qt element get destroyed and then
all hell breaks loose ( abort / segfaults / exceptions / ... )

Adding a tb.wait() right after the tb.stop() seems to fix the problem.
But it might even be better to register an "aboutToQuit()" signal
handler and issue the stop() & wait() to the flowgraph before any of
the Qt app cleanup even begins.
And this seems to fit the recommended usage
http://doc.qt.digia.com/4.7/qcoreapplication.html#aboutToQuit

And you get something like this :

qapp = Qt.QApplication(sys.argv)
tb = top_block()
tb.start()
tb.show()
def quitting():
tb.stop()
tb.wait()
qapp.connect(qapp, SIGNAL("aboutToQuit()"), quitting)
qapp.exec_()

Where the order of destruction makes more sense. You end up having :

- All stop() method called and wait for completion of all
- Destruction of all QWidgets by Qt
- Destruction of all blocks themselves

This at least gives the opportunity to blocks that create some Qt
widget to _know_ that they should stop accessing them because they
might not be there anymore ... (in my case I start/stop a worker
thread in the gr::sync_block start/stop methods and that thread
accesses the QWidget create by the block)


Cheers,

Sylvain

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

[Discuss-gnuradio] GNU Radio Support for Matchstiq

[Meaghan Zorij]

GNU Radio support for Epiq Solutions' Matchstiq SDR platform is now
publicly available.  This includes support for both the Matchstiq 001
(TI DM3730 ARM + Xilinx Spartan 6 LX45 FPGA), as well as the Matchstiq
Z01 (Xilinx Zynq Z7020). This was developed as an out-of-tree module
and is available on github:
https://github.com/epiqsolutions/gr-matchstiq.git

Currently, this release supports using Matchstiq as a source and works
with GNU Radio 3.6.4.  Future releases will add sink capabilities as
well support for GNU Radio 3.7.  Additionally, GNU Radio can run
from a host PC or natively on the Matchstiq itself for increased
throughput.

Thanks to all of the beta testers who assisted in the initial
validation of the block.  We look forward to any feedback and
questions on the gr-matchstiq block or the Matchstiq hardware itself.

Thanks,
Meaghan

-- 
Meaghan Zorij
Systems / Software Architect
Epiq Solutions

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

[Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1

[Daniel Domínguez]

Hi Tim.

The solution I found was to set the Fixed Frame Length parameter to 1 on
the OFDM Frame Equalizer block of the "Header Stream".

The original value for this field is set to 0, but I don't exactly know why
it works setting it to 1.

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

Re: [Discuss-gnuradio] Questions on rx_ofdm example in GR 3.7.1

[Daniel Domínguez]

Nope, the only thing I did was to set it to 1. I didn't changed the tag
names or anything else.


On Wed, Sep 25, 2013 at 5:06 PM, Monahan-Mitchell, Tim <
tmona...@qti.qualcomm.com> wrote:

>  Thanks, I will try that. So you did not have to make the change I
> suggested in the posting, and is described here:
>
> ** **
>
> http://gnuradio.org/redmine/issues/593 
>
> ** **
>
> Tim
>
> ** **
>
> *From:* Daniel Domínguez [mailto:eont...@gmail.com]
> *Sent:* Wednesday, September 25, 2013 5:52 PM
> *To:* Monahan-Mitchell, Tim
> *Subject:* [Discuss-gnuradio] Questions on rx_ofdm example in GR 3.7.1
>
> ** **
>
> Hi Tim.
>
> ** **
>
> The solution I found was to set the Fixed Frame Length parameter to 1 on
> the OFDM Frame Equalizer block of the "Header Stream".
>
> ** **
>
> The original value for this field is set to 0, but I don't exactly know
> why it works setting it to 1.
>
> ** **
>
> Regards.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GnuRadio as Antenna Analyzer and SWR meter

[Ethan Waldo]

This may be outside of the scope of what GnuRadio is trying to accomplish and 
complementary hardware would need to exist, but it would be great if GnuRadio 
had modules to build a software defined antenna analyzer for impedance matching 
as well as a software defined SWR meter.  Of course it currently has all the 
various spectrum analyzers and GnuRadio could easily control something like an 
external antenna tuner, but it would be great if (with the complementary 
hardware) GnuRadio could automatically measure wave reflection and match 
impedance and for its sources and sinks.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1

[Martin Braun (CEL)]

On Wed, Sep 25, 2013 at 04:57:55PM -0700, Daniel Domínguez wrote:
> The solution I found was to set the Fixed Frame Length parameter to 1 on the
> OFDM Frame Equalizer block of the "Header Stream".

Hi guys,

1 is the correct setting. I'm currently adding a tx into the example so
it runs as-is (like benchmark).

The reason: The headers have constant length, therefore it is not
necessary to propagate them as tagged streams. The way the header/paylod
demux work, it splits off the header and passes that regularly. There's
no need to generate a length tag.

MB


-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpZcA3TXg0nY.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio