Hi Jeff,
Thanks for your reply!
So let me make certain that I understand correctly your response where you
said there were 16*512 samples (8192 samples). So I take it that noutput_items
(which has alternating values of 15 and 16 when printed to the screen) tells
me the number of vectors of vlen elements the scheduler delivers on each
iteration. Therefore, to process all the data delivered in one
iteration (noutput_items
* vlen floating point samples), if I was simply designing an algorithm that
writes the input data to the output, I would do the following:
for (int j = 0; j < noutput_items; j++){
for (int i = 0; i < vlen; i++){
out[ vlen*j + i ] = in[ vlen*j + i ];
}
}
Am I right?
Thank you!
George
On Wed, Apr 20, 2022 at 5:40 PM Jeff Long <willco...@gmail.com> wrote:
> The item size is vlen * sizeof (type), so you are seeing 16 * 512
> "samples".
>
> On Wed, Apr 20, 2022 at 1:44 PM George Edwards <gedwards....@gmail.com>
> wrote:
>
>> Hello GNURadio Community,
>>
>> I have written a C++ OOT "sync" block with vector input and vector output
>> (data type float). I wrote a line in my program to print the value of
>> noutput_items on each GRC flow graph iteration and it alternately prints
>> the values 15 and 16. This is surprising!!! I was expecting this value
>> to be the 512, the number of elements in each input/output vector that I
>> designed the OOT to operate at. In my OOT design, the input/output
>> signatures were set to 512 floating point elements. In the GRC Flow graph
>> my block is fed by a stream to vector block (which brings in vectors of
>> 512 samples) and my block outputs its data to a vector to stream block
>> (which takes a vector of 512 elements and converts to a data stream).
>>
>> I was under the impression that the parameter noutput_items in the
>> work(...) function for an OOT sync block with vector input and output
>> provided
>> the number of elements in each output vector.
>>
>> I will appreciate any insight into this issue.
>>
>> Thanks!
>> George
>>
>>
>>
>>
