Re: [Discuss-gnuradio] Fixing the number of input_items streaming in a block

[Michael Dickens]

Hi Savino - The short answer is: no. That said, you -can- give hints to the scheduler -- the part of GNU Radio runtime that determines how many items are provided to "work" for any given block. For example, you can set an I/O signature such that the item size is your desired vector length (in actual I/O items). In this scenario, you can't control how many such vectors are provided for "work", but you are guaranteed that each "item" will constitute a single vector's worth of data & it's pretty simple to figure out how many vectors are in the I/O. There are other scheduler hints that can affect memory alignment and making sure the output is a multiple of some number of items; and setting a history of data to keep around after each "work" call; and probably a few others I don't recall right now. Hope this is useful! - MLD

On Tue, Aug 7, 2018, at 10:16 AM, Savino Piccolomo wrote:

Just to clarify,

I am basically asking if there is a way to fix the number of input_items streaming in and processed by the work function each time it is called by GRC.

Note: I am not talking about the number of input signals (i.e. wires connected to the block) or the dimension of the vectors streaming in (could also be float data in the simplest case).

Thanks

On Fri, 3 Aug 2018 at 19:28, Savino Piccolomo <address@hidden> wrote:

Hi all,

I am writing a gnuradio block in python equivalent to the QT GUI time Sink block but which plots an input vector/s instead of input stream/s.

The input_items in the work function is a matrix of shape:

(inputs, vectors, vector_length),

where inputs is the number of input vectors to be plotted, vector_length is the size of  each vector to be plotted and vectors is the number of vectors streaming and processed at each call of the work function.

I have noticed that vectors is connected to vector_length; more precisely, for increasing vector_length, vectors decreases till eventually 1; for decreasing vector_length, vectors increases and the computation time increases as well, because at each step (i.e. each time the work function is called) more data (vectors) has to be processed.

My question therefore is: is there a way to fix (possibly to 1) vectors?

So far I haven't find a way playing around with functions as consume and forecast. Any help would be appreciated.

Thanks,

- Savino