I’m experiencing a problem with the noutput_items.
I have written a sync block which did “return” several times. I found
noutput_items dropped exactly by the amount that I returned. For
I wrote “return 10”, after that, I printed noutput_items and found it
decreased to noutput_items -10.
Due to this fashion, the noutput_items could decrease to a value that
my “if statement” isn’t satisfied. In that case, several items wouldn’t
outputed so the actual size of output items is smaller than the size of
input items. Is it still a sync block?
I tried to wait for the noutput_items to increase but it didn’t happen.
tried to use “set_noutput_items( )” or “set_output_buffer()” to some
I wanted, but they also failed.
So I’m asking that how to tell the scheduler effectively that I want to
increase the noutput_items?
View this message in context:
Sent from the GnuRadio mailing list archive at Nabble.com.
noutput_items is what GNU Radio can maximally allow your block to
produce, which is the free size in the output buffer, which is the input
buffer of the next block.
So if your block is faster than the downstream block, you will see
exactly the behaviour you are observing. This is normal, and good.
There’s nothing the scheduler can do about this – something
“downstream” of your block just “backs up” the item flow, and your block
will have to wait until whatever is downstream of it is done consuming
input, so that there is space for output from your block again.
You could try using set_min_noutput_items  in your block’s
constructor, so that GNU Radio won’t even ask you to work() if there’s
not enough space available.
Thanks for your comment!
I made a typo my previous post that I was going to say
“set_min_noutput_items” but I wrote “set_noutput_items”. I actually used
in the work function, but it didn’t seem to function as I expected.
reading your comment, I put it in the constructor and nothing changed.
On Wed, Apr 1, 2015 at 11:18 AM, Marcus Müller
Can you explain again why you require a min size for noutput_items? It
sounds like there might still be a misunderstanding as to what this
variable is used for. Why does your block care about the value of
I tried to call it in the constructor, and it’s the same as call it in
work function. It didn’t work as I expected.
I was actually trying to update and adding more features to
There is a conditional statement below in my work function.
if( noutput_items >= d_look_ahead)
I tried to use set_min_noutput_items (d_look_ahead) in the constructor
in the work function. Neither of these two ways helped me satisfy the
I was trying to update and adding more features to the peak_detector2.
There is a sliding look_ahead parameter described in peak_detector, but
it’s not actually implemented. There is a fixed look_ahead parameter
in peak_detector2, but there is a litte bug. So I was trying to combine
these two types of look_ahead windows in my new peak_detector2 block.
In my design, I have to guarantee the noutput_items is greater than the
d_look_ahead, otherwise, it might cause some unexpected problems. That’s
why I used a conditional statement to make sure I only enable the peak
finding process when I have enough noutput_items.
Please check the pull request for further details.
On Wed, Apr 1, 2015 at 11:40 AM, Richard B. [email protected]
I don’t know the details off the top of my head, but this might be one
of those functions that you can’t call during work(). Have you tried
calling it in the ctor?
Have you tried set_output_multiple(x)? That would ensure that you’d
always get n*x output space, with n in 1,2,3…