# How to increase the noutput\_items **URL:** \ **Category:** GNU Radio\ **Created:** [April 1, 2015, 5:02pm UTC](https://www.ruby-forum.com/t/how-to-increase-the-noutput-items/241370 "2015-04-01T17:02:38Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [April 1, 2015, 5:02pm UTC](https://www.ruby-forum.com/t/how-to-increase-the-noutput-items/241370/1 "2015-04-01T17:02:38Z")
Dear all, I’m experiencing a problem with the noutput\_items. I have written a sync block which did “return” several times. I found the noutput\_items dropped exactly by the amount that I returned. For example, if 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 one of my “if statement” isn’t satisfied. In that case, several items wouldn’t be 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. I tried to use “set\_noutput\_items( )” or “set\_output\_buffer()” to some values 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? Thanks! Best regards, Zhe – View this message in context: [http://gnuradio.4.n7.nabble.com/How-to-increase-the-noutput-items-tp53075.html](http://gnuradio.4.n7.nabble.com/How-to-increase-the-noutput-items-tp53075.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![Zhe\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d07c76/32.png) [@Zhe\_F](https://www.ruby-forum.com/u/Zhe_F)\ **Post date:** [April 1, 2015, 5:23pm UTC](https://www.ruby-forum.com/t/how-to-increase-the-noutput-items/241370/2 "2015-04-01T17:23:05Z")
Hi, 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 [1] in your block’s constructor, so that GNU Radio won’t even ask you to work() if there’s not enough space available. Greetings, Marcus [1] [http://gnuradio.org/doc/doxygen/classgr\_1\_1block.html#a65cfc579150dc4d10c6180d3365aa9a8](http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a65cfc579150dc4d10c6180d3365aa9a8) ---
**Author:** ![Zhe\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d07c76/32.png) [@Zhe\_F](https://www.ruby-forum.com/u/Zhe_F)\ **Post date:** [April 1, 2015, 5:35pm UTC](https://www.ruby-forum.com/t/how-to-increase-the-noutput-items/241370/3 "2015-04-01T17:35:35Z")
Dear Marcus, 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 it in the work function, but it didn’t seem to function as I expected. After reading your comment, I put it in the constructor and nothing changed. Best regards, Zhe On Wed, Apr 1, 2015 at 11:18 AM, Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Zhe\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d07c76/32.png) [@Zhe\_F](https://www.ruby-forum.com/u/Zhe_F)\ **Post date:** [April 1, 2015, 5:47pm UTC](https://www.ruby-forum.com/t/how-to-increase-the-noutput-items/241370/4 "2015-04-01T17:47:07Z")
Zhe, 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 noutput\_items? v/r, Rich ---
**Author:** ![Zhe\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d07c76/32.png) [@Zhe\_F](https://www.ruby-forum.com/u/Zhe_F)\ **Post date:** [April 1, 2015, 7:51pm UTC](https://www.ruby-forum.com/t/how-to-increase-the-noutput-items/241370/5 "2015-04-01T19:51:00Z")
Dear Martin, I tried to call it in the constructor, and it’s the same as call it in the work function. It didn’t work as I expected. I was actually trying to update and adding more features to peak\_detector2. 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 and in the work function. Neither of these two ways helped me satisfy the above condition. Best regards, Zhe ---
**Author:** ![Zhe\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d07c76/32.png) [@Zhe\_F](https://www.ruby-forum.com/u/Zhe_F)\ **Post date:** [April 1, 2015, 7:59pm UTC](https://www.ruby-forum.com/t/how-to-increase-the-noutput-items/241370/6 "2015-04-01T19:59:00Z")
Dear Richard, 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 coded 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. > > > Dear all, > > We found a bug in peak\_detector2 when we were using it previously, s…o we tried to fix it. To make the peak\_detector2 more functional, we added two more parameters. Besides, we made an optional output of the average for debugging. > > Bug description: > In the previous block, the stall problem always happens at the end of the noutput\_items buffer. When the time "work" function is called, the threshold is passed and a peak is found in the term "i" which "d\_peak\_ind" is set to. When the input index is close to noutput\_items, the for loop may end after setting tmp = d\_peak\_ind and return tmp-1. Since only tmp-1 is returned, it's possible that tmp -1 is less than noutput\_items. So the next time the scheduler may set a very small noutput\_items. For example, 2, and the d\_found is still true. So the next time the work function is called, it directly goes to the peak finding mode and search for the peak. For noutput\_items =2, it will end shortly and it's highly possible that the very first input is detected as the peak, so tmp is set to 0. In that case, what we return now will be tmp-1 = -1 which is impossible. That's why the system stalls. > > You can also check the post below and run the example attached in the post to see the bug. > http://gnuradio.4.n7.nabble.com/Peak-Detector2-stalls-simulation-td51761.html > > Bug Fixing: > To avoid such a circumstance, we rewrite the peak\_detector2 block in the state machine way that only one state is active everytime "work" is called. We made sure that we'll wait for enough output buffers before we start to locate the peak within the look\_ahead. > > Additional parameters: > > The additional parameter is the average type. This parameter gives the user two options, to calculate the auto-regressive average all the time or to calculate the average only when the value of input signal is below threshold\_factor\_rise\*average. The first option is more accurate but requires more computational resource, while the second option is more computational friendly but less accurate. The user can decide by the character of their application. > > We were about to add another parameter to enable the "sliding window" option. But it seems there is an unsolved bug. So we decided to drop it for now. > > Optional avg output: > When we want to debug the peak\_detector2 by adding the average\_output port, we have to edit the xml file and rebuild the gnuradio which is inconvenient. So we make the average\_out port an optional output by adding one parameter "Debug" in xml file. When "Debug" is enabled, the block will have an additional output port avg\_out. When "Debug" is disabled, the avg\_out port will be hiden. > > QA TEST: > > We also modified the qa\_test to make the test work for the new peak\_detector2 but fails for the old peak\_detector2. I think you can also see the bug by running the qa\_test with the original peak\_detector2. > > This is our update to the peak\_detector2 which makes it robuster and more functional. Could you check and merge it? > > Best regards, > Zhe Best regards, Zhe On Wed, Apr 1, 2015 at 11:40 AM, Richard B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Zhe\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d07c76/32.png) [@Zhe\_F](https://www.ruby-forum.com/u/Zhe_F)\ **Post date:** [April 1, 2015, 7:24pm UTC](https://www.ruby-forum.com/t/how-to-increase-the-noutput-items/241370/7 "2015-04-01T19:24:08Z")
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? M ---
**Author:** ![Zhe\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d07c76/32.png) [@Zhe\_F](https://www.ruby-forum.com/u/Zhe_F)\ **Post date:** [April 1, 2015, 8:37pm UTC](https://www.ruby-forum.com/t/how-to-increase-the-noutput-items/241370/8 "2015-04-01T20:37:53Z")
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… Greetings, Marcus