Your Problem is actually here:
(C++ work function)
" while ( i < d_fft_length ) {"
you never check that your in[] and out[] indices are within noutput_items!
You only get a limited amount of items per work call. For sync blocks,
this is noutput_items.
What you do is just ignore that number, take d_fft_length items (whether
there are more or less
available) and process them. Then you "return noutput_items", which is
also wrong,
because you actually process d_fft_length.
What you most probably want to do is either directly process vectors, or
set an output multiple.
A vector is actually just an item with vector_length*single_itemsize
size, so you need to change your in- and
output signatures by multiplying sizeof(whatever) with fft_length; then,
in your work, you only process
one vector, thus you should return 1;.
If you use set_output_multiple, your item size stays the same
(sizeof(gr_complex)), and you don't have to change your code,
aside from replacing return noutput_items by what you've actually
consumed (ie. d_fft_length).
Greetings,
Marcus
On 28.05.2014 12:00, Karan Talasila wrote:
> @Marcus. Instead of using a grc gui flowgraph to test our block, we have
> written a qa test code in python which connects vector source, block that
> we are testing and vector sink just like the example given in out of tree
> modules to generate square of the input items.
>
> We are writing an alamouti code block which takes in an input stream of N
> complex numbers and gives out 2 output steams of N items each. I will
> attach the C++ code of block( http://pastebin.com/Kdnk1t8x ) and also the
> python qa test code below(http://pastebin.com/da21Ww4B).
> <http://pastebin.com/da21Ww4B>
>
>
> On Wed, May 28, 2014 at 2:58 PM, Martin Braun <martin.br...@ettus.com>wrote:
>
>> On 28.05.2014 11:13, Martin Braun wrote:
>>
>>> On 28.05.2014 09:45, Karan Talasila wrote:
>>>
>>>> Hi
>>>> we have written a c++ block using out of tree modules which uses a
>>>> sync block that outputs same no of items as input items given. we have
>>>> written a python test file where the inputs and outputs are complex
>>>> floats. The test code is running well until 4096 items. But when the
>>>> output items size is greater than or equal to 8192, ctest shows an
>>>> assertion error which says
>>>>
>>>> -10+5j !=10+5j beyond 7 places.
>>>>
>>> This looks like floating point quantization errors. Show us your QA, and
>>> make sure you're using the assertFloatTuplesAlmostEqual (not sure if
>>> that's the right name) call.
>>>
>> Ah, as Marcus M points out, this is a signature error, rather than
>> quantization :)
>> Still, this all points to your code being incorrect, or your QA making
>> invalid assumptions.
>>
>> Maybe you should be tracking state in your block (these number indicate
>> that more than 1 work function call seem unveil your bug).
>>
>>
>> M
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
