Re: How pass an input vector in an OOT QA test?
You'll have to tell us what you do with that `data` and what the io_signature of your block is. On 20.04.22 17:22, George Edwards wrote: Hello GNURadio Community, In an OOT QA testing of a signal processing block designed to accept an input vector of 4 elements, I am having problems passing the QA input as a vector. It sees the input as a stream. I tried passing the data in two ways, but each failed. Here are the two ways I have formated the QA data which I would like to be seen as a vector of 4 elements: data = (1.0, 2.0, 3.0, 4.0) and data = numpy.array([[1.0, 2.0, 3.0, 4.0], [5.0, 6.0, 7.0, 8.0]]) I would appreciate any suggestion. Thank you! George
UHD 4.2.0.0 released!
Hello GNU Radio community and friends of UHD, On behalf of everyone at NI/Ettus Research, I am pleased to announce the release of UHD 4.2[1], the latest version of the USRP Hardware Driver! UHD 4.2 brings new enhancements to the USRP X410, notably: * A new shipping bitfile, X410_CG_400, enabling 100 GbE 4x4 streaming support at 491.52 MS/s. An app note detailing system setup and results is forthcoming. * X410 DRAM record/replay support. This allows the use of the DRAM in a custom RFNoC application design to capture data from the radio front end or for waveforms to be uploaded from the host to be generated by the radio. * X410 GPIO support, including timed commands. Of course, there are also many bug fixes and improvements across the entire range of supported USRP devices. Be sure to check out the changelog at [1] for the full list. And as with any release, let us know of any problems by filing an issue against UHD on the GitHub repo[2] or by posting to the USRP-users mailing list. With very best regards, Aaron [1] https://github.com/EttusResearch/uhd/releases/tag/v4.2.0.0 [2] https://github.com/EttusResearch/uhd/issues/
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
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
>>>
>>>
>>>
>>>
GNU Radio Project Call April 2022: live now!
Heio SDR people, on https://twitch.tv/gnuradio, the GNU Radio dev call is about to start. I'd like to remind everyone that asking questions there, in our #gnuradio:gnuradio.org Matrix room, or on the bridged #gnuradio on the libera IRC network, and also on Discord, is heavily encouraged! Best regards, Marcus
Re: How pass an input vector in an OOT QA test?
Hi Marcus, Thanks for offering to assist me. The OOT signal processing blocks I have designed so far worked with streaming data. For this project, I wish to pass the data in as vectors (which is new to me). I am writing this OOT block to accept a vector of 100 floating point elements on each iteration. I wrote the QA Test so I can use the Debugger to parse the C++ code and get an understanding of how vector elements are passed into a block. For the QA Test, I restricted the vector size to 4 floating pointing elements (something I can observe easily for debugging purposes) and I set the I/0 signatures accordingly: sizeof(float)*4. Inside the QA file I set the input to data = (1.0, 2.0, 3.0, 4.0). My initial assumption was that I am passing in a vector of length 4 floating point elements. The test failed and gave an error message of data mismatched because the signature input was 16 (4*4 bytes/float) and the QA input was 4 (meaning it saw data in stream format one float at a time and not as one big vector with 4 elements). Then, I tried rewriting: data = numpy.array([[1.0, 2.0, 3.0, 4.0], [5.0, 6.0, 7.0, 8.0]]) Thinking, I am forcing things to look like vectors of size 4 elements, WRONG AGAIN! So I am seeking help on how to feed in vectors from a QA file into a block that needs its data in vector form. Thank you! Regards, George On Thu, Apr 21, 2022 at 3:57 AM Marcus Müller wrote: > You'll have to tell us what you do with that `data` and what the > io_signature of your > block is. > > On 20.04.22 17:22, George Edwards wrote: > > Hello GNURadio Community, > > > > In an OOT QA testing of a signal processing block designed to accept an > input vector of 4 > > elements, I am having problems passing the QA input as a vector. It sees > the input as a > > stream. I tried passing the data in two ways, but each failed. Here are > the two ways I > > have formated the QA data which I would like to be seen as a vector of 4 > elements: > > > > data = (1.0, 2.0, 3.0, 4.0) and > > data = numpy.array([[1.0, 2.0, 3.0, 4.0], [5.0, 6.0, 7.0, 8.0]]) > > > > I would appreciate any suggestion. > > > > Thank you! > > George > >
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
