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).
<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?
<http://pastebin.com/da21Ww4B>
On Wed, May 28, 2014 at 3:40 PM, Marcus Müller <marcus.muel...@ettus.com>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 <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
> >>
> >
> >
>
>
--
Regards
Karan Talasila
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
