Constant noutput_items

Hi All,

I want to ask that can we immobilize the noutput_items value to a
constant value when we write a block. So we can give always the same
amount of output.
Any help would be kindly appreciated.Thanks, Sema

On Wed, Mar 28, 2012 at 08:58:37AM +0100, s k wrote:

I want to ask that can we immobilize the noutput_items value to a constant
value when we write a block. So we can give always the same amount of output.

Short answer: no. Long answer: It depends. If you’re depending on the
input
items. For a source, or for a block independent on the input data,
there’s ways to do this.
Also, you can fix the output item size. Perhaps that’ll do what you
want (i.e. you can output vectors of fixed length).

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

Martin B. wrote in post #1053724:

On Wed, Mar 28, 2012 at 08:58:37AM +0100, s k wrote:

I want to ask that can we immobilize the noutput_items value to a constant
value when we write a block. So we can give always the same amount of output.

Short answer: no. Long answer: It depends. If you’re depending on the
input
items. For a source, or for a block independent on the input data,
there’s ways to do this.
Also, you can fix the output item size. Perhaps that’ll do what you
want (i.e. you can output vectors of fixed length).

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

Dear Martin,

Thank you for your answer. Can you please suggest some documents for I
can understand the ways you talked about.

I am trying to write a real-time signal processing block. When I fix the
sync block output (ex: return 1024) and use my block with connect()
function and plot it in python file, it gives either segmentation fault
or nothing. Are you talking about decimation block?

Thank you,
Sema

On Wed, Mar 28, 2012 at 8:52 AM, Michael D. [email protected]
wrote:

As Martin wrote, the shortest answer is: no, or, well, not really or not always.
Under some circumstances this could be made work at least sometimes, but I don’t
think you can guarantee it all of the time. For example, many of the OFDM blocks
always process exactly 1 packet’s or FFT’s worth of data, and hence have a
guaranteed -actual- number of consumed and generated items; the amount provided
and requested by the scheduler may be different that the actuals (and, I think,
generally is). IIRC, the technique used by these blocks is to set the I/O
signatures, output multiple, and ::forecast such that the number of I/O items is a
multiple of what is required (the packet or FFT length). In my (very limited)
testing, the OFDM blocks work for their defaults and sometimes other values; but
they’re not exactly robust – some values just don’t work (and, no, I cannot given
an example off the top of my head; just go and play with the OFDM benchmarks).
Good luck! - MLD

Another method to work with is the ability to set the maximum number
of items a block is allowed to process. You pass this in as a
max_noutput_items to a top_block’s run() or start() methods. This
won’t always have the same number, just sets the max. But we do not
implement a static scheduler like you’re looking for.

If you have a block that absolutely requires a certain number of items
to process, then you can use the forecast method to request a
particular minimum number of items. You may receive more than this,
but not less in this case. If you receive more, you only have to
process the number you want and return that amount; the scheduler will
use that to keep track of what data you have and have not handled.

This way of working can be useful in some cases, like the OFDM symbol
handling code. Most of the time, we try to let the scheduler provide
the data and we write the blocks to handle all or as much as possible
but have data members that keep state between calls to work.

Tom

As Martin wrote, the shortest answer is: no, or, well, not really or not
always. Under some circumstances this could be made work at least
sometimes, but I don’t think you can guarantee it all of the time. For
example, many of the OFDM blocks always process exactly 1 packet’s or
FFT’s worth of data, and hence have a guaranteed -actual- number of
consumed and generated items; the amount provided and requested by the
scheduler may be different that the actuals (and, I think, generally
is). IIRC, the technique used by these blocks is to set the I/O
signatures, output multiple, and ::forecast such that the number of I/O
items is a multiple of what is required (the packet or FFT length). In
my (very limited) testing, the OFDM blocks work for their defaults and
sometimes other values; but they’re not exactly robust – some values
just don’t work (and, no, I cannot given an example off the top of my
head; just go and play with the OFDM benchmarks). Good luck! - MLD

On Mar 28, 2012, at 5:43 AM, Martin B. wrote:

Short answer: no. Long answer: It depends. If you’re depending on the input
items. For a source, or for a block independent on the input data,
there’s ways to do this.
Also, you can fix the output item size. Perhaps that’ll do what you
want (i.e. you can output vectors of fixed length).

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