Big vector problem

Hi all

I have a problem with a big vector. The input/output of my entity is
like:
: gr_block (“sub_channel_vff”,
gr_make_io_signature2 (2, 2, sizeof (float)*3072, sizeof
(char)),
gr_make_io_signature2 (1, 2, sizeof (float)*5376))

And my forecast is like:
ninput_items_required[i] = 76/4;

The problem is that one input Frame has a size about 76*3072= 233472
values and I cut four parts (at different positions) of size 5376 out of
it.
If I run the simulation I get an error:
…is requesting more input data than we can provide.
ninput_items_required = 19
max_possible_items_available = 4…

If I reduce the ninput_items_required value the simulation works, but
the value reflectes not the truth and in the gr_block file is written:
“The estimate doesn’t have to be exact, but should be close”. Knows
anybody a solution or a detour to work with this big vectors?

Any idea? Any help will be appreciated

Thanks
Michael

On Mon, Jun 06, 2011 at 09:33:52AM +0200, Michael Höin wrote:

ninput_items_required[i] = 76/4;
the value reflectes not the truth and in the gr_block file is written:
“The estimate doesn’t have to be exact, but should be close”. Knows
anybody a solution or a detour to work with this big vectors?

Any idea? Any help will be appreciated

Hi Michael,

without knowing what you’re block’s supposed to do, two solutions come
to mind:

  1. You re-think the functionality of the block. Does it really need
    these massive input vectors?

  2. You re-write the block to operate on streams. This should not be a
    problem since you’ve already chosen a gr_block instead of a
    gr_sync_block. You might need some internal buffers (that operate
    outside the buffers provided by GNU Radio) and some state variables to
    remember where you are in the stream.
    Are you simply cutting stuff out of a stream? In that case, a re-write
    should be fairly simple.

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

Hi Martin

  1. With this big vectors the code is very easy to read, because the
    standard has the same blocksizes.

  2. Yes, a streamconvertion is a possible solution.

I also think about dummy data vectors to get a lower forecast value. Is
this a good idea?

Thanks Michael

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