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

[Marcus Müller]

Hi Activecat, hi Karan!

>You keep Marcus very busy, let me help to offload him.

Activecat: Thanks :) I'm not in charge of the mailing list, everyone
should feel free to
answer if he's able to help! Helping Karan was, by the way, not the
biggest of all
work loads, because I always enjoy reading a few lines of code. But as
you will see, there's not
much to add to your explanations, so keep that good work up ;)

So, back to topic:
>> 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
Sorry, you got that wrong:
The work function processes as many items as *you* define by returning
that number.
The upper boundary is the number of items available, which is noutput_items.
All items that have been available but you haven't consumed (by
returning less than noutput_items) will be saved for the next work call.

>> 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?
Usually, there's no guarantee that your work will always be called with
the same number of items.
The only guarantee you get is that noutput_items >= 1 !
So if you want to make sure you always get a certain number of items or
vectors of the right length, you will
have to use set_output_multiple or a vector input length.

> [...]
>
> If not, make sure you use set_output_multiple(fft_length) or at least
> set_min_noutput_items(fft_length), in this case the scheduler will not call
> work() function with insufficient number of elements.
Exactly!
>> 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
This is because you put in items of sizeof(gr_complex), but your block
expects sizeof(gr_complex)*fft_length. Solve this setting the vector
length of your vector source OR by adding a "stream to vector" block; do
the same for your sink OR add a "vector to stream".
> The correct way is, in your work() function you should have 2 loops,
> because now your in[0] is a vector but no longer solely a complex number.
As GNU Radio is now, this is not really true. Since vectors are but
vector elements that are directly sequential in memory, and these
vectors, like smaller items, are directly sequential in memory
themselves, there is no difference between 16384 items in two items of
length 8192*sizeof(gr_complex) and 16384 items of sizeof(gr_complex).
It's always good to remember: As a rule of thumb, the GNU Radio
scheduler does not care about your signal at all :D it only cares about
memory sizes. That's why it complains about item size mismatches -- it
has no way to look inside the data!

> 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?
>>
> No need, because set_output_multiple() works with sync block as well.
Exactly. Whenever you can say that for a certain amount of input, there
will be a proportional amount of output items, there's no need for
general_work, and you can use the sync, interpolator or decimator block
types.

Greetings,
Marcus



Note:
> Note:
> Apologize in advance if my answer is incorrect.

Activecat, you're already a rising star ;) so as a GNU Radio enthusiast
I really like when you bring yourself in! I've made dozens of mistakes,
and I never felt bad when someone corrected me afterwards, and you
shouldn't either.
If GNU Radio was for people that are perfect, then this project would be
as dead as a doornail, and as beginner-friendly as parachute-free
skydiving...
Software frameworks (heck, we call ourselves "ecosystem") like GNU Radio
only blossom when people discuss concepts, and that won't happen when
everyone has the same understanding and the same problems. So I
encourage everyone to experiment a lot, and ask questions that they
can't solve themselves! Answering questions definitively belongs into
the community part of experimenting and should be fruitful to both, the
one asking and the one answering.