Re: Meaning of value in noutput_items for an OOT with vector input
Hi Jeff,
Thank you very much!
George
On Thu, Apr 21, 2022 at 12:21 PM Jeff Long wrote:
> Right. Of course you can just use one loop of noutput_items * vlen
> iterations.
>
> Technically noutput_items says how many items you may write, not how many
> the scheduler is delivering (implying input). In a sync block, they are the
> same though, unless you overwritten forecast().
>
> On Thu, Apr 21, 2022 at 12:14 PM George Edwards
> wrote:
>
>> 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 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
>>> 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
Re: Meaning of value in noutput_items for an OOT with vector input
Right. Of course you can just use one loop of noutput_items * vlen
iterations.
Technically noutput_items says how many items you may write, not how many
the scheduler is delivering (implying input). In a sync block, they are the
same though, unless you overwritten forecast().
On Thu, Apr 21, 2022 at 12:14 PM George Edwards
wrote:
> 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 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
>> 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
>>>
>>>
>>>
>>>
Re: Meaning of value in noutput_items for an OOT with vector input
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 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
> 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
>>
>>
>>
>>
Re: Meaning of value in noutput_items for an OOT with vector input
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 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 > > > >
