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