Re: [Discuss-gnuradio] How to control the open and close state of a flow graph

[Josh Blum]

On 02/07/2012 06:51 AM, Zhonghua wrote:
> Hi every one,
> 
> I am trying to control the open and close state of the flow graph which
> implements transmission and receiving tasks. I would not like to use
> start() and stop() pair to do that because the construction time is too
> long. What I expect is sending a signal from another process to control
> the flow graph of local process.
> The architecture is very simple. In RX channel, Using uhd.usrp_source()
> to get flow and transferring it to a signal process block for example
> ieee802_15_4_demod_pkts().  TX part transferring flow from
> ieee802_15_4_mod_pkts to uhd.usrp_sink(). The RX and TX are put in two
> separate top_block and control them respectively. The simplest method I
> used to control is lock() and unlock(). My scenario is that when signal
> A arrived , call lock(), then when signal B arrived call unlock() to
> revive the flow. The result is sometimes in the period of signal A the
> flow does not stop and there is still data transferred from usrp_source
> to demod_pks block. Then, I try to use method that combines lock() +
> disconnect()+unlock() to stop the flow. For reviving the flow,
> lock()+connect()+unlock() is used. The result is identical with the
> former experiment.
> At last I realised maybe the usrp_source is two slow so it block the
> signal handler's action. To verify it, I added the period of signal B to
> give adequate time for the data transferring from usrp_source to the
> demod_pkts(). I found the signal handler's action became almost regular.
> If I came back to the old time configuration but set a lower sample rate
> of the uhd.usrp_source(), the signal handler's action also became regular.
> So now my question is if I have to keep a small period of signal B and
> simultaneously a relatively high sample rate, how can I control the
> flow? Are there some approaches to mute the usrp_source thoroughly at
> the period of signal B?
> Any suggestion is highly appreciated.
> 

There is a massive amount of overhead when using lock/unlock. Your
application will probably operate better of streams can be dynamically
redirected in real-time.

Here is a gr.stream_selector block:
http://gnuradio.org/cgit/jblum.git/tree/gr-blocks/include/gnuradio/blocks/stream_selector.h?h=new_blocks

Perhaps you can make use of this block, or perhaps it will help you to
write a custom block that solves your problem.

-Josh