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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
