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