Re: [Discuss-gnuradio] assertion error beyond 4096 output items

[Karan Talasila]

Hi Marcus,

                   Thank you for evaluating our code and help debugging it. what we understand from your reply is that work function at a time processes noutput_items and this can be lesser than or more than the fft_length. As an example in our code when we give the fft length as 8192, but the noutput_items is still  4096, so does that mean it has to execute work function twice to process 4096*2=8192 items?

Regarding the first approach you suggested, we change the input signature and output signature to (sizeof (gr_complex)*fft_length) so that it is a single vector that is being processed. Then we return 1 as suggested. But it is throwing an itemsize mismatch error. I have attached the c++ file here ( http://pastebin.com/TKemtbxN ). The error says

ERROR: test_001_t (__main__.qa_al_enc)
2: ------------------------------

----------------------------------------
2: Traceback (most recent call last):
2:   File "/home/sagar/gr-alamouti/python/qa_al_enc.py", line 66, in test_001_t
2:     self.tb.connect(src,opr)
2:   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 130, in connect
2:     self._connect(points[i-1], points[i])
2:   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 142, in _connect
2:     dst_block.to_basic_block(), dst_port)
2:   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 4350, in primitive_connect
2:     return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
2: ValueError: itemsize mismatch: vector_source_c1:0 using 8, al_enc1:0 using 65536

The python qa file link is (http://pastebin.com/da21Ww4B).

For the second method suggested should we write a general work function and a forecast function which would mean doing away with sync block that we are using with work function right now?

On Wed, May 28, 2014 at 3:40 PM, Marcus Müller <address@hidden> wrote:

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 <address@hidden>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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>

--
Regards
Karan Talasila