-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
I’m trying to implement an application with GNU Radio Companion that
incorporates different branches. For example I have a Wav source and a
signal source and I want to switch between them. Or I want to hear the
signal at socertain points in the flow graph. The old way was to use a
variable chooser, const multipliers for muting of paths and adders. The
downside of this system is that all the paths continue to run
concurrently. I do not use the muted paths, but they still consume
processing power.
Now I found the valve block, and the doc says: Connect output to input
when valve is closed (not open).
I expected the valve to block when input is not connected to output. I
thougth the flow graph would starve/block on that path. In consequence
the path would not consume processing power. Now it seems - referring to
Josh’s message from 2010-05-06 [1] - that down the path from the valve
indeed starving happens, but the null sink in the valve happily
consumes, keeping the producers running.
I thought about replacing the null sink with something blocking. This
would for sure work with otherwise unconnected sources, like when
choosing between different sources. But I’m not sure what happens if the
path splits before the valve. Would the blocking be propagated back over
the split or be limited to the path with the valve?
Maybe I’m just on the wrong track and there is some other simple
solution for this problem.
Regards
Patrick
[1] http://article.gmane.org/gmane.comp.gnu.radio.general/26777
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0nrBYACgkQ/G6gHctkMa/WtQCfV6z15+BrBgPa12X/WCoCphXt
jqUAn0fSxmm94i/OS/FXKa/cC1E0cX8e
=Jn5p
-----END PGP SIGNATURE-----
The input blocks to the valve, when open, connect to null sinks. The
idea was to drain any incoming data. This could be desirable if for
example you had other blocks, like a file sink that also used this
stream. You wouln’t want to back-up indefinitely and then consume all
the old data when closed again. It depends on the topology. So maybe the
user should decide…
I think the valve needs a user-set policy. Consume when open, or block
when open. And while we are at it, for the outputs, produce zeros when
open, or block when open.
-Josh
On 01/07/2011 04:13 PM, Patrick S. wrote:
would for sure work with otherwise unconnected sources, like when
[1] http://article.gmane.org/gmane.comp.gnu.radio.general/26777
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
schrieb Josh B. on 2011-01-08 01:44:
The input blocks to the valve, when open, connect to null sinks. The
idea was to drain any incoming data. This could be desirable if for
example you had other blocks, like a file sink that also used this
stream. You wouln’t want to back-up indefinitely and then consume all
the old data when closed again. It depends on the topology. So maybe the
user should decide…
I think the valve needs a user-set policy. Consume when open, or block
when open. And while we are at it, for the outputs, produce zeros when
open, or block when open.
Just found out that the selector block fits my requirements much better.
But do I have the same behaviour here again?
I replaced my const multipliers/adders with selectors, but now it uses
much more cpu load 
Regards
Patrick
schrieb Josh B. am 2011-01-08 05:29:
Just found out that the selector block fits my requirements much better.
But do I have the same behaviour here again?
The valve is implemented with the selector.
Thanks.
What would be the best way to disable a branch of the flow graph, so
that the disabled path is stopped/starved/drained/disabled? I do not
care too much about stale data in buffers, I just want to get rid of the
unnecessary processing power that is consumed by the path branch. If
this is not possible in grc, I’d take the generated source and modify
it, no big deal.
Regards
Patrick
Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telemati_cs_, Techn. University Graz, Austria
On Sat, Jan 8, 2011 at 6:31 PM, Patrick S.
[email protected] wrote:
What would be the best way to disable a branch of the flow graph, so
that the disabled path is stopped/starved/drained/disabled? I do not
care too much about stale data in buffers, I just want to get rid of the
unnecessary processing power that is consumed by the path branch. If
this is not possible in grc, I’d take the generated source and modify
it, no big deal.
Hi Patrick,
The only way I know of to disable a block is to disconnect its inputs
and outputs from the rest of the graph. GRC can not do that so you
will have to edit the python code. You have to suspend execution
during reconfiguration:
http://gnuradio.org/redmine/wiki/gnuradio/TutorialsWritePythonApplications#Controlling-flow-graphs
I usually do:
self.lock()
self.disconnect(A,B1,C)
self.connect(A,B2,C)
self.unlock()
B1 will be disconnected but will still exist and you can use it again
later.
If you want to disable a whole branch with several blocks, I think you
will have to break all connections within the branch and not just he
input/output of the branch (I am not sure about this though). You can
of course put the branch in a hier block in which case you only have
to disconnect one block.
Alex
Patrick S. wrote:
What would be the best way to disable a branch of the flow graph, so
that the disabled path is stopped/starved/drained/disabled? I do not
care too much about stale data in buffers, I just want to get rid of the
unnecessary processing power that is consumed by the path branch. If
this is not possible in grc, I’d take the generated source and modify
it, no big deal.
Could you use a non-blocking message sink and a separate flow graph that
takes input from a message source and is started and stopped as needed ?
– Don W.
Just found out that the selector block fits my requirements much better.
But do I have the same behaviour here again?
The valve is implemented with the selector.
-josh