discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] noutput_items


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] noutput_items
Date: Sun, 25 May 2014 10:20:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]