On Fri, Feb 27, 2009 at 10:13:39PM -0800, Paul Mathews wrote: > I have a nice gnuradio app running using USRP, with 3 FFTsinks going at > once, with the 1st FFTsink taking data from the USRP and the 2nd and 3rd > FFTsinks each showing the results of further processing: > > 1) USRP downconverting to 1 MHz ---> FFT display 1 > 2) Channel filter LP to 16 kHz ---> FFT display 2 > 3) AM demod and BP filter 2 to 10 kHz --> FFT display 3 > > I've added some code to the worker_thread class to do automatic tuning: > > 1) Coarse tuning based on highest peak location in FFT 1 > 2) Fine AFC based on highest peak location in FFT 2 > > Once I've located the carrier peak in FFT 1 and centered USRP tuning on it, > I have no further need to FFT and display the USRP data, and I'd like to > shut down that message queue, FFT, and FFT display to free up resources. I'm > thinking I need to 'disconnect' connected blocks, but I'm having trouble > figuring out how to do that. Any hints will be appreciated. > > My attempts to naively use the 'disconnect' method consistently yield > messages like this one: > > File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py", > line 9 > 5, in disconnect > self._tb.disconnect(points[0].basic_block()) > File > "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runt > ime.py", line 1477, in disconnect > return _gnuradio_swig_py_runtime.gr_top_block_sptr_disconnect(*args) > ValueError: cannot disconnect block message_sink(15), not found > > > Paul Mathews
>From the message, it sounds like the block you are trying to disconnect has already been disconnected. Can you post a link to a _small_ test case the demonstrates the problem. Are you using lock/unlock around your disconnects and connects? Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
