Re: [Discuss-gnuradio] lock and unlock with transmith_path and receive_path
On Wed, Feb 17, 2010 at 02:44:08PM -0800, Veljko Pejovic wrote: > Hi Eric, > > You can find the example here: > http://cs.ucsb.edu/~veljko/downloads/tx_ofdm_flex.tar.gz > The example (benchmark_ofdm_tx_new.py) changes the number of carriers > (from 50, to 100, 150, and so on) after every 300 packets sent. It can > use either set_ofdm_parameters or set_ofdm_parameters_high, both > functions do lock-disconnect-connect-unlock but at different levels in > the graph hierarchy. > > NOTE: I upgraded from release 3.2.2 to the current trunk and the > problem seems to be gone. If you want to replay the problem run the > example with gnuradio 3.2.2 and low decimation. At least that's when I > see it in my setup (Ubuntu 9.10, USRP2, XCVR2450) Glad to hear it's gone on the git master. I won't be looking for the problem on 3.2.2 :-) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] lock and unlock with transmith_path and receive_path
On Mon, Feb 15, 2010 at 10:51:05AM -0800, Veljko Pejovic wrote: > Update: > I moved the reconfiguration one level up, to transmit_path.py and it > works for high interpolation values (low bit rate), but still hangs > for the low ones. > > I'm quite puzzled now, it seems that lock() - unlock() gets stuck when > there's too much flow going on. > > > cheers, > Veljko Veljko, Can you post a link to a complete example that produces the problem? Both the case you described earlier as well as this one would be useful. The smaller the test case the better, if possible. Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] lock and unlock with transmith_path and receive_path
On Sun, Jan 24, 2010 at 02:21:12PM +0100, Carlo Donato Lecce wrote: > > Hello all, > > > I seem that using transmit_path and receive_path the reconfigure > of flow graph is bad. > The following code hung after the call of unlock. > > I think that there are a bugs in the transmit_path because > using a gr.null_source insted of transmit_path the program not hangs. > > Thanks, > > > Carlo. Carlo, It looks like you're missing the calls to connect that would have your top block know about the nested blocks. See below. Eric > from gnuradio import gr, gru, modulation_utils > from gnuradio import eng_notation > from gnuradio.eng_option import eng_option > from optparse import OptionParser > > import random, time, struct, sys, math > > # from current dir > from transmit_path import transmit_path > from receive_path import receive_path > > > class h_block(gr.hier_block2): > def __init__(self): > gr.hier_block2.__init__(self, "hello", gr.io_signature(0, 0, 0), > gr.io_signature(0, 0, 0)) > > class top_block(gr.top_block): > def __init__(self, mod_class, demod_class, rx_callback, options): > gr.top_block.__init__(self) > > self.txpath = transmit_path(mod_class, options) > self.rxpath = receive_path(demod_class, rx_callback, options) Try adding: self.connect(self.txpath) self.connect(self.rxpath) here. See also tunnel.py > self.source = gr.null_source(gr.sizeof_gr_complex) > self.sink = gr.null_sink(gr.sizeof_gr_complex) > > > self.connect(self.txpath, self.sink) > # self.connect(self.source2, self.sink2) > > def reconfigure(self): > self.lock() > self.disconnect(self.txpath, self.sink) > self.sink2 = gr.null_sink(gr.sizeof_gr_complex) > self.connect(self.txpath, self.sink2) > self.unlock() ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
