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. https://github.com/gnuradio/gnuradio/pull/404 Best regards, Zhe On Wed, Apr 1, 2015 at 11:40 AM, Richard Bell <richard.be...@gmail.com> wrote: > 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 > > On Wed, Apr 1, 2015 at 8:34 AM, Zhe Feng <feng...@umich.edu> wrote: > >> 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 <marcus.muel...@ettus.com> >> wrote: >> >>> 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 >>> >>> On 04/01/2015 04:47 PM, Zhe Feng wrote: >>> > 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 >>> > Sent from the GnuRadio mailing list archive at Nabble.com. >>> > >>> > _______________________________________________ >>> > 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 >>> >> >> >> >> -- >> Zhe Feng >> Electrical Engineering: System >> University of Michigan Ann Arbor >> Tel: 734-834-3188 >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- Zhe Feng Electrical Engineering: System University of Michigan Ann Arbor Tel: 734-834-3188
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
