Re: [Discuss-gnuradio] GnuRadio flowgraphs in workerthread

[Johnathan Corgan]

On 10/11/2013 11:48 AM, Alex3371 wrote:
> Wow, thank you for your detailed answer.
> 
> But one thing I don't understand:
> 
> " If you called run() on the first one, it would not return from that
> call until the flowgraph exited, and your second flowgraph would get
> started too late. "
> 
> I don't want the flowgraphs to run parallel to each other. One
> flowgraph senses the spectrum with the USRP and the second flowgraph
> transmitts a signal with the same USRP (depending on the measurements
> of the spectrum). So it's important that they run consecutively.

Ah, I missed this.

> In this case, is it fine the way I do call run() for both flowgraphs?
> Would replacing it with start() + wait() make any difference?

Since you have a finite length flowgraph, there really is no difference.

> When the flowgraph is stopped by a head-block the threads are
> shutdown, but the flowgraph itself still exists with all the
> blockinternal member variables (including possible changes during the
> first run) and after a head-reset it can be re-run with the
> run()-method. This re-run starts where the previous run stopped. Is
> that correct?

Yes.  On occasion we've found bugs in blocks that assumed their start()
functions would only get called once (like in the ALSA audio
source/sinks) but otherwise this is how it works.

I would suggest, however, that you reconsider this approach if you are
eventually going to be doing anything more than simple processing.
Starting and stopping flowgraphs is using a very heavy hammer and takes
a long time (in sample terms).

Instead, think of always having the two flowgraphs instatiated and
started, and adding a message input port to a custom block on the
transmitter and message output port to a custom block on the receiver.

You can then move your control logic into a Python message only block
that receives a message from the receiver, does whatever needs to be
done as a result of this, then triggers the transmitter by sending a
message to it.

The flowgraph then is always running, but you've separated your signal
processing control from flowgraph run/start/stop/wait semantics.

You can also extend this idea of a control block to allow triggering the
receiver (via message passing) from a GUI button, which can have an
event handler in the Python block to trigger the receiver via message.

(This description is missing details on how this would change your
flowgraphs to be message triggered, as I'm not aware of what's in them.)

Asynchronous messaging is a very new feature of GNU Radio and we don't
have many examples of using it to learn from.  But the above scenario is
one use case we had in mind in designing it.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com

johnathan.vcf
Description: Vcard

signature.asc
Description: OpenPGP digital signature