Hi All,
@Marcus @activecat @Martin Thank you all for your help. We were
able to solve the problem we had for itemsize greater than or equal to
8192. We used set_output_multiple(fft_length) in the constructor and it
worked. Now it is working for any input fft length.
So at the input of the C++ we are giving vector_source_c() and then input
output signatures are sizeof(gr_complex). The work function is taking
noutput_items and returning noutput_items. We understand now that because
we have used set_output_multiple(fft_length) in the constructor, the
noutput_items is fixed at the fft_length and then work function is being
called.
However one small doubt,when we print value of noutput_items in C++ program
inside the work function ,the print statement is executed twice for any
fft_length we use. Is this correct? It should only print once the value of
noutput_items if i am right.
Thank you once again.
On Thu, May 29, 2014 at 2:53 AM, Marcus Müller <[email protected]>
wrote:
> 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.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
--
Regards
Karan Talasila
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
