|
From: | Karan Talasila |
Subject: | Re: [Discuss-gnuradio] assertion error beyond 4096 output items |
Date: | Thu, 29 May 2014 12:11:55 +0530 |
Hi Activecat, hi Karan!
Activecat: Thanks :) I'm not in charge of the mailing list, everyone
>You keep Marcus very busy, let me help to offload him.
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,Sorry, you got that wrong:
>> 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
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.
Usually, there's no guarantee that your work will always be called with
>> 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?
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.
> [...]
>Exactly!
> 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.
>> Regarding the first approach you suggested, we change the input signatureThis is because you put in items of sizeof(gr_complex), but your block
>> 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
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,As GNU Radio is now, this is not really true. Since vectors are but
> because now your in[0] is a vector but no longer solely a complex number.
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!
Exactly. Whenever you can say that for a certain amount of input, there
> 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.
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:Activecat, you're already a rising star ;) so as a GNU Radio enthusiast
> Apologize in advance if my answer is incorrect.
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.
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Prev in Thread] | Current Thread | [Next in Thread] |