Multiplie top blocks

Hi!

During the buildup phase of my gnuradio scripts (in init of classes
that inherit from top_block or some classes that are initialized from a
topblock instance), I try to use gnuradio to convert some data. E.g. I
use gr.fft to do FFT on some constant data, or apply the function of
some special blocks to other constant data. With the old hierblock2
etc., that worked fine for me.

We’ve been working with an old gnuradio revision to not break up the
system upon changes to the trunk. But now, it is time to get to a newer
revision (skipping about 2000 revisions). After porting everything to
your new top_block structure, now I encounter the problem that creation
of several top blocks is not allowed. Actually, the second or later
created topblock should be terminated before the first will be started,
but I use the other blocks during setup of the “main” topblock.

How can I solve this problem? I don’t like to recode so that every
initialization is done before creating the main block, since this forces
me to have knowledge of internals outside this block. Is there any smart
way to have the signal interrupt handler for example just tied to the
currently running block, e.g. allowing several top blocks to be created,
but only one to be running? Maybe to defer the registering of the
handler until start of the implementation.

Any suggestions are welcome!

Greetings
Dominik

Hello,

This is definitely a defect, I think. It is obstructing useful ways to
use GNU Radio for.

I did it as said, allowing only one instance to be running, but several
to be created.

Dominik

On Tue, May 13, 2008 at 07:35:31PM +0200, Dominik A. wrote:

Hello,

This is definitely a defect, I think. It is obstructing useful ways to use
GNU Radio for.

I did it as said, allowing only one instance to be running, but several to
be created.

Dominik

Known problem. It’ll be fixed as part of the MP-scheduler work.

Johnathan, I couldn’t find the ticket number of the “only one
top_block” problem. Could you please create a ticket.

Thanks,
Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs