Thank you so much for your complete explanation. Just the term *maximally* and WORK_CALLED_PRODUCE works for me :)
best, On Sun, May 25, 2014 at 12:50 PM, Marcus Müller <marcus.muel...@ettus.com>wrote: > Hi Mostafa, > > a few things: > 1. work() only is meaningful for sync and interpolator/decimator blocks; > then, you always have a fixed relation between consumed and produced > items, and you can't have a different number of output items on > different ports. > 2. noutput_items is the parameter of the work function that tells you > how many items you can produce *maximally*. It's not the number you > produced; in the (performance-wise) best case, you return noutput_items > to tell that your block consumed and produced everything GNU Radio asked > it to. If you produced less, you return exactly that amount. > 3. When using produce(), you should return the special value > WORK_CALLED_PRODUCE. > 4. If you're having different output item numbers on different ports, > you're bound to use a general block with general_work. Then you'll have > to consume() at each input the amount of items that you've used and > produce them at each output. Also, you should implement a forecast() > method just to give GNU Radio an idea how many items you need on which > input port if you have to produce a certain number of output items on > different ports. > 5. Most of the time, blocks described by 4. are complicated. I used to > write blocks like that, but nowadays I rarely do, because the message > port API of GNU Radio fits my designs' needs better, most of the time. > When dealing with things that are basically packets of digitally > modulated data, take a look at the Tagged Stream / PDU infrastructure as > described in the GNU Radio doxygen. > 6. I've seen some screenshots of defunctional flowgraphs where the > developer tried to implement correction loops (e.g. phase correction > loop) by outputting an error/correction estimate on one output port and > the corrected samples on the other, feeding back the correction to a > multiplier upstream. Don't fall into that trap! In GNU Radio, you can't > have sample loops, since this violates causality requirements (a block > can't produce output without input, but within a loop there is no input > without output). Just mentioning this because it can lead to a lot of > frustration ;) > > Greetings, > Marcus > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
