# Grc connection issue?

**URL:** <https://www.ruby-forum.com/t/grc-connection-issue/232566>\
**Category:** GNU Radio\
**Created:** [October 16, 2014, 9:53am UTC](https://www.ruby-forum.com/t/grc-connection-issue/232566 "2014-10-16T09:53:06Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [October 16, 2014, 9:53am UTC](https://www.ruby-forum.com/t/grc-connection-issue/232566/1 "2014-10-16T09:53:06Z")

</div>

Hi list,  
I have a custom block trying to connect with other blocks in gnuradio  
like:  
for i in xrange(len(self.sources)):  
self.connect(self.src[i], self.filt[i], self.resampler[i],  
(self.finder, i))  
number of connections should be equal to number of sources.  
All goes well, but it is executing only once, i.e. first block with :  
self.connect(self.src[0], self.filt[0], self.resampler[0],  
(self.finder, 0))  
other one getting terminated once above connection terminates.

Possible bug:  
my finder block looks for FCCH in input stream and if it does not find,  
will terminate, I suspect if it impacts on going connection of GRC.  
Presume:  
It should not be matter if first connection terminates, it should keep  
executing till last one

GRC connections executes sequentially???  
if yes, how can I achieve to execute all connections simultaneously  
please give me your thoughts

Thank you in advance

---

<div class="post-metadata">

**Author:** ![gsmandvoip](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/e19adc/32.png) [@gsmandvoip](https://www.ruby-forum.com/u/gsmandvoip)\
**Post date:** [October 16, 2014, 11:56am UTC](https://www.ruby-forum.com/t/grc-connection-issue/232566/2 "2014-10-16T11:56:17Z")

</div>

Hi gsmandvoip,

On 16.10.2014 09:52, gsmandvoip wrote:

> Hi list,  
> I have a custom block trying to connect with other blocks in gnuradio like:  
> for i in xrange(len(self.sources)):  
> self.connect(self.src[i], self.filt[i], self.resampler[i],  
> (self.finder, i))  
> shouldn’t that read “for i in xrange(len(self.src)):”?  
> This is but a stylistic thing, but when I get into loop trouble in  
> python, I often find myself trying to do things in a more “pythonic”  
> way:

for i, (src, filt, resampler) in enumerate( zip(self.src, self.filt,  
self.resampler) ):  
self.connect(src, filt, resampler, (self.finder,i))

> number of connections should be equal to number of sources.  
> All goes well, but it is executing only once, i.e. first block with :  
> self.connect(self.src[0], self.filt[0], self.resampler[0],  
> (self.finder, 0))  
> other one getting terminated once above connection terminates.
> 
> Possible bug:  
> my finder block looks for FCCH in input stream and if it does not find,  
> will terminate, I suspect if it impacts on going connection of GRC.  
> I didn’t understand this sentence ☹ could you explain?  
> I thought the problem was that only one of the len(self.src) connections  
> was made, and that must happen before you even start the flow graph, so  
> whatever your block does internally is irrelevant, as long as your  
> finder block has the right input signature.  
> Presume:  
> It should not be matter if first connection terminates, it should keep  
> executing till last one
> 
> GRC connections executes sequentially???  
> Clarification: GRC is the GNU Radio companion, the graphical tool to  
> define flow graphs. These flow graphs are then used to generate python,  
> and that calls GNU Radio functionality to set up the connections.

So, yes, connections are defined sequentially, but that must happen  
before you start() the flowgraph, so they are set up before anything  
calls your work. They will never be removed or redefined during normal  
flow graph operation.

> if yes, how can I achieve to execute all connections simultaneously  
> execute connections? A connection is a definition for GNU Radio to know  
> which output buffers are the input buffers of downstream blocks. After a  
> block finishes its work() method, all surrounding blocks are notified of  
> the change in available items and freed buffer space.  
> please give me your thoughts  
> You’re quite likely doing cool stuff!

Greetings,  
Marcus