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 [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
