Hi
Thanks for the reply. I used tb1.start() and tb2.run() and I think that
is
working. The two blocks don’t have connections with each other.
The flow is like:
tb1=gr.top_block()
- tb1.start()
- Some variable declaration…
Repeat step 3 and 4, five times
3. A function that creates tb2 and runs it and return the result
— tb2=gr.top_block()
— vector source—>convolution coding----->destination
— tb2.run()
— return destination.data()
4. send the result to the tb1 for processing
5 . tb1.wait()
As far as the result is concerned it seems right. But, I want to know
that
whether this type of thing is conceptually right or not ??
I read that there must be only one top_block(). Please guide me in
this…
Regards
Smith
On Mon, Jun 20, 2011 at 11:03, smith mark [email protected]
wrote:
As far as the result is concerned it seems right. But, I want to know that
whether this type of thing is conceptually right or not ??
It is functionally correct, as you noted, but using GNU Radio this way
is
not very common except perhaps in automated QA code.
Typically, flowgraphs run continuously, with data being injected into
the
graph via one or more sources and being removed via one or more sinks,
and
don’t get started and stopped or re-run except in response to some
application level event (like startup and shutdown, or for flowgraph
reconfiguration).
I think your use case would be better served by connecting your two
flowgraphs using a message sink and a message source that share a common
message queue, or even merging the two together, but it is hard to say
without more information about what you are trying to accomplish.
I read that there must be only one top_block(). Please guide me in this…
Having more than one top block is fine since release series 3.3, but
requires more attention to detail as you have to use the
start()/stop()/wait() sequence on each instead of the simpler run().
Johnathan
Thank you very much all for such clear explanation of things. Actually I
want to implement the coded OFDM. And was trying to figure out
how can I run the trellis-encoder and OFDM flow graphs together. Your
posts
did help me a lot :).
Smith
On Tue, Jun 21, 2011 at 1:45 AM, Johnathan C. <