Re: How to generate control signals between block?

Trond,

I am glad you asked this question in such an eloquent way.
This has been my question about Gnuradio for a long time.

One way around it (not sure if it works for all scenarios)
is for the flow grap to communicate with the main pyhton program and the
rest of the flowgraphs through massage queues.

Let me explain with an example:
suppose as you say you have one flowgraph that listens to the channel
and tries to see whether a packet is present and in addition does some
freq/phase/time aquisition. Once such a packet is found then the
flowgraph has a message sink and puts this
half-baked packet in this queue, together with possibly another message
of a different TYPE (control message) with some parameters required
in the second flow (such as initial phase estimate, etc).

Now the external python script has an infinite loop and
looks always at this message queue.
Once it finds a messgae waiting it does 2 things:

First it sets the parameters of the SECOND flow graph according to the
control message in the queue.
Second, it passes this message to ANOTHER
queue associated with a message_source in the second flowgraph
(I assume that somehow the second flowgraph will start processing the
new input immediately; maybe the second message queue is of size 1).

I have written a small python script to test these ideas, based on
the “tunnel.py” code and at least I can communicate between the
flowgraph and the python main. I have not tested yet interaction with
two flowgrpahs…

I am very interested to hear opinions on this…

Achilleas

=============================

Hi,

I think I have a fairly good understanding of how the basics of GNU
Radio work, but there is one thing that I just can’t figure out: How
can I generate control signals between block and between blocks and
the world outside. I understand how to set up flow graph, but I can’t
find any good examples or tutorials on how to interact with the graph
once its running. I’ll give you an example:

I am creating a receiver, and the signal is divided into several flow
graphs. One graph performs acquistion on the incoming signal, and then
passes two parameters to the tracking loop. Now what would be the
correct way to signal the other graph? In GUI programming the
equivalent would be for one block to emit a certain signal, which
triggers a callback in another block, but I am not sure if this is the
way it is done in GNU Radio.

My application has fairly relaxed requirements: There are no hard
real-time requirements, as the demodulated data is not intended to be
displayed in real time. I have read about the new mblock, but it
seemed overkill for my application.

Hope I managed to present my question clearly.

– Trond D.


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

2007/3/5, Greg T. [email protected]:

ad hoc version of the more general scheme.
I read about the m-block architecture, and I must say that is seems
very nice, but a bit too complicated for my simple needs. I just need
to estimate some parameters at a low rate, and update another graph
dynamically. BTW: Has anybody else done any work on CDMA?

Trond D.

On Tue, Mar 06, 2007 at 09:57:57PM +0100, Trond D. wrote:

might want to do something before it is, but it seems like this is an
ad hoc version of the more general scheme.

I read about the m-block architecture, and I must say that is seems
very nice, but a bit too complicated for my simple needs. I just need
to estimate some parameters at a low rate, and update another graph
dynamically.

It should be pretty straight-forward to use (said the person
implementing it…) Basically you send and receive messages.

In the interim, you can use the existing gr.message and
gr.msg_queue primitives to get the job done.

Eric