Re: [Discuss-gnuradio] lock and unlock with transmit h_path and receive_path‏

[Veljko Pejovic]

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

2010/2/14 Veljko Pejovic <address@hidden>:
> Hi,
>
> I have a similar problem in my code.
> I modified benchmark_tx.py from gnuradio-examples/ofdm and ofdm.py
> from blks2impl so that I can change the number of active subcarriers
> on fly.
>
> In the packet sending loop of benchmark_tx I periodically do the following:
>
> lock the top block (tb.lock()), call a function in ofdm.py which
> disconnects the blocks within ofdm_mod:
>
>        self.disconnect((self._pkt_input, 0), (self.preambles, 0))
>        self.disconnect((self._pkt_input, 1), (self.preambles, 1))
>        self.disconnect(self.preambles, self.ifft, self.cp_adder,
> self.scale, self)
>
> rebuild them according to the parameters that I pass from
> benchmark_tx and reconnects them. After that I call tb.unlock().
>
> What happens is that sometimes it works, and sometimes it gets stuck
> (some sort of deadlock I assume). I tried swapping lock-unlock with
> stop-wait-start and that results in similar behavior (it actually goes
> a few iterations further on average). I also tried moving lock-unlock
> to the actual function in ofdm_mod, but that didn't change anything.
>
> Any suggestions?
>
> Thanks,
>
>
> Veljko
>
> 2010/2/8 Eric Blossom <address@hidden>:
>> 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
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>