Forum: GNU Radio Rearranging a running flow graph

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Patrick S. (Guest)
on 2007-03-17 13:30
(Received via mailing list)
Hello!

I'd like to construct a demo for grc which can switch between two or
more branches in a flow graph, like AM or FM: given a Signal, this would
be modulated by an FM and an AM branch, then one is selected for a
simulated channel (noise) and afterwards the signal is fed to either a
FM or a AM demodulator. I want easily switch between the two behaviours,
but am not shure about how to do this the Right Way.

I'd do this now with multiplicators, but that introduces for every
branch a new block, and keeps the unused paths running, which is
rousource hungry (I don't have that much CPU power).

An other way would be to do disconnects and connects in the flow graph.
Is this a sensible way to go? Can I rearrange a running flow graph or do
I have to stop before rearranging and start the flow graph afterwards?
Josh: What do you think about integrating this into grc?

The third possibility would be contruct a swtich block that takes n
inputs and has a method to select the input by a number. Would this be
possible an a way so that the not-to be consumed path temporarily
discontinues processing? On continuation, the interrupted path would
work with old data. Any way to flush this or are the buffers small
enough to neglect this effect? I guess this would also be true for
connect/disconnect.

Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick S. <patrick dot strasser at  tugraz dot at>
Student of Telematik, Techn. University Graz, Austria
Trond D. (Guest)
on 2007-03-17 14:39
(Received via mailing list)
2007/3/17, Patrick S. <removed_email_address@domain.invalid>:
>
> The third possibility would be contruct a swtich block that takes n
> inputs and has a method to select the input by a number. Would this be
> possible an a way so that the not-to be consumed path temporarily
> discontinues processing? On continuation, the interrupted path would
> work with old data. Any way to flush this or are the buffers small
> enough to neglect this effect? I guess this would also be true for
> connect/disconnect.
>

A mute block already exist:
http://gnuradio.org/doc/doxygen/classgr__mute__cc.html.
--
Trond D.
Josh B. (Guest)
on 2007-03-17 17:07
(Received via mailing list)
Patrick S. wrote:
> branch a new block, and keeps the unused paths running, which is
> rousource hungry (I don't have that much CPU power).
A mute outputs zero when it is "muted", so this is as effective as the
multiplier (maybe a bit faster). I did not integrate the mute because
there is no way yet to use a variable/slider to control an enumerated
data type like the mute parameter which is true or false. A multiply
constant with a variable min=0, max=1, step=1 is the best solution at
the moment.
>
> An other way would be to do disconnects and connects in the flow
> graph. Is this a sensible way to go? Can I rearrange a running flow
> graph or do I have to stop before rearranging and start the flow graph
> afterwards?
> Josh: What do you think about integrating this into grc?

I did not know that one can disconnect blocks in a running flow graph.
This is possible? Anyway, I will save that idea for the future.
>
> The third possibility would be contruct a swtich block that takes n
> inputs and has a method to select the input by a number. Would this be
> possible an a way so that the not-to be consumed path temporarily
> discontinues processing? On continuation, the interrupted path would
> work with old data. Any way to flush this or are the buffers small
> enough to neglect this effect? I guess this would also be true for
> connect/disconnect.

I think gnuradio needs a mux and a demux block. A mux has N inputs and a
set_n method. The mux will only feed the output with the nth input
stream (throw out/ignore the other inputs). A demux has N outputs and a
set_n method. The demux will only feed the nth output with the input
stream.

The mux seems easy to make. Is the demux possible in the current
gnuradio? Meaning: can you feed one output and starve the other outputs?

In Patrick's example, the demux outputs would be an FM and an AM
demodulator.
>
> Patrick
-Josh
Eric B. (Guest)
on 2007-03-17 22:04
(Received via mailing list)
On Sat, Mar 17, 2007 at 12:29:34PM +0100, Patrick S. wrote:
> Hello!
>
> I'd like to construct a demo for grc which can switch between two or
> more branches in a flow graph, like AM or FM: given a Signal, this would
> be modulated by an FM and an AM branch, then one is selected for a
> simulated channel (noise) and afterwards the signal is fed to either a
> FM or a AM demodulator. I want easily switch between the two behaviours,
> but am not shure about how to do this the Right Way.

I think the "right answer" will be available as soon as Johnathan
finishes the work on "disconnect" in the gr_hier_block2 stuff.  This
will replace the existing hierarchical blocks, and will treat both
gr_blocks and hierarchical blocks as first class objects, able to be
connected and disconnected on the fly.

Johnathan, any estimate as to when this will be ready?

> I'd do this now with multiplicators, but that introduces for every
> branch a new block, and keeps the unused paths running, which is
> rousource hungry (I don't have that much CPU power).

Yes.

> An other way would be to do disconnects and connects in the flow graph.
> Is this a sensible way to go? Can I rearrange a running flow graph or do
> I have to stop before rearranging and start the flow graph afterwards?
> Josh: What do you think about integrating this into grc?

Yes, see above.  The existing gr.hier_blocks don't handle disconnect
well.

> The third possibility would be contruct a swtich block that takes n
> inputs and has a method to select the input by a number. Would this be
> possible an a way so that the not-to be consumed path temporarily
> discontinues processing? On continuation, the interrupted path would
> work with old data. Any way to flush this or are the buffers small
> enough to neglect this effect? I guess this would also be true for
> connect/disconnect.
>
> Patrick

Eric
Eric B. (Guest)
on 2007-03-17 22:10
(Received via mailing list)
On Sat, Mar 17, 2007 at 11:05:38AM -0400, Josh B. wrote:
> Patrick S. wrote:
> >Hello!
> >
>
> I did not know that one can disconnect blocks in a running flow graph.
> This is possible? Anyway, I will save that idea for the future.

It's currently flaky, and doesn't work well.

> stream (throw out/ignore the other inputs). A demux has N outputs and a
> set_n method. The demux will only feed the nth output with the input stream.
>
> The mux seems easy to make. Is the demux possible in the current
> gnuradio? Meaning: can you feed one output and starve the other outputs?

With the new gr_hier_block2, it will be possible to construct one.

> In Patrick's example, the demux outputs would be an FM and an AM
> demodulator.

Yes.

Eric
Patrick S. (Guest)
on 2007-03-18 18:20
(Received via mailing list)
Josh B. wrote on 2007-03-17 16:05:
> Patrick S. wrote:

>> The third possibility would be construct a switch block that takes n
>> inputs and has a method to select the input by a number.

> I think gnuradio needs a mux and a demux block. A mux has N inputs and a
> set_n method. The mux will only feed the output with the nth input
> stream (throw out/ignore the other inputs). A demux has N outputs and a
> set_n method. The demux will only feed the nth output with the input
> stream.

Exactly what I was thinking about. AFAIK the squelch block has an option
to output either zeros or nothing when squelched.

I would not call it multiplexer, as this implicates for me interleaving
of more than one stream to of from. I think our searched-fore behaviour
is rather a selector or multiswitch.

Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick S. <patrick dot strasser at  tugraz dot at>
Student of Telematik, Techn. University Graz, Austria
Johnathan C. (Guest)
on 2007-03-18 19:51
(Received via mailing list)
Patrick S. wrote:

> to output either zeros or nothing when squelched.
>
> I would not call it multiplexer, as this implicates for me interleaving
> of more than one stream to of from. I think our searched-fore behaviour
> is rather a selector or multiswitch.

A selector would be straightforward to implement with today's code.

Since all outputs in a flowgraph must generate equal numbers of items,
it's not possible today to make a block that directs it's input to
one-of-n outputs in a single block.  When the new hierarchical block
code is complete, you could make one that would connect and disconnect
the appropriate outputs to the input as needed in the set_n function.

--
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
Trond D. (Guest)
on 2007-04-16 13:54
(Received via mailing list)
2007/3/17, Josh B. <removed_email_address@domain.invalid>:
> I think gnuradio needs a mux and a demux block. A mux has N inputs and a
> set_n method. The mux will only feed the output with the nth input
> stream (throw out/ignore the other inputs). A demux has N outputs and a
> set_n method. The demux will only feed the nth output with the input stream.

Has anybody written something like this allready?

--
Trond D.
Eric B. (Guest)
on 2007-04-16 18:38
(Received via mailing list)
On Mon, Apr 16, 2007 at 11:51:09AM +0200, Trond D. wrote:
> 2007/3/17, Josh B. <removed_email_address@domain.invalid>:
> >I think gnuradio needs a mux and a demux block. A mux has N inputs and a
> >set_n method. The mux will only feed the output with the nth input
> >stream (throw out/ignore the other inputs). A demux has N outputs and a
> >set_n method. The demux will only feed the nth output with the input
> >stream.
>
> Has anybody written something like this allready?

No.

I think this should be implemented using the work-in-progress
that Johnathan's doing for hier_block2.  It may be about a week too
early to use ;)

Eric
Josh B. (Guest)
on 2007-06-17 07:34
(Received via mailing list)
Eric B. wrote:
>
> I think this should be implemented using the work-in-progress
> that Johnathan's doing for hier_block2.  It may be about a week too
> early to use ;)

How would you go about doing this? I had thought that one could use a
bunch of message sources and sinks, and a thread could facilitate data
transfer for only one source-sink pair. But how could several blocks
with single inputs appear as one block with multiple inputs? Seems like
trouble...

-------

On another note: The original problem was trying to toggle a section of
a running flow graph on and off. The gr.skiphead seems to be able to do
this by starving the data stream for the first n samples. Could there be
a gr.valve block that can starve a data stream based on a boolean flag?
The flag could set by an open/close method (or something to that
effect).

Or a block like this exists and I missed it?

-Josh
Josh B. (Guest)
on 2007-06-19 07:49
(Received via mailing list)
So, I went the python way and created a valve hier block. It is a
message sink and a message source with a thread that only forwards
messages when the valve is closed. (code attached)

I noticed that calling fg.stop() blocks because my thread is stuck in a
loop. I am using the gr.gr_threading framework. Is there a proper way to
setup a gr.gr_threading.Thread so that fg.stop() can kill/stop the
running threads?

Thanks,
-Josh
This topic is locked and can not be replied to.