# Peak\_Detector2 stalls simulation **URL:** \ **Category:** GNU Radio\ **Created:** [January 2, 2015, 6:14pm UTC](https://www.ruby-forum.com/t/peak-detector2-stalls-simulation/233669 "2015-01-02T18:14:35Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [January 2, 2015, 6:14pm UTC](https://www.ruby-forum.com/t/peak-detector2-stalls-simulation/233669/1 "2015-01-02T18:14:35Z")
Hello and Season’s Greetings, I am experiencing a problem with the blocks::peak\_detector2 block. The simulation stalls after some time. My conjecture is that this is due to the kind the block handles its output in work(), but I am not sure, since I am not that deep into the scheduler. I am kindly asking for comments and hints on this issue. My System: Kubuntu 14.10 64 Bit GNURadio from Git via Pybombs Consider the attached minimal GRC example for reproducing the problem [I just changed gnuradio/gr-blocks/grc/blocks\_peak\_detector2.xml such that the additional “averaged value” output port is visible in GRC, i.e. added avg\_out float ] Symptoms: - With the setup from the minimal example the displayed waves of the 3-input QT GUI Time Sink stall. - If the Peak-Detector and sub-sequent parts are disabled, the simulations keeps on running (i.e. does not stall) - if peak\_detector2 is enabled, but its outputs are just connected to null sinks, the simulation stalls again. Conjecture: - Either the input buffer of Peak Detector2 over-flows or - not enough output items are produced in order to remain synchronous Traceback: I do not have a clue, what is actually malfunctioning, hence I am asking for help. Thoughts: 1. Have a look at gnuradio/gr-blocks/lib/peak\_detector2\_fb\_impl.cc. This is a synchronous block and in the ::work(.) function noutput\_items is returned (line 106), if no peak has been detected within the input values. From my understanding, once an input value is above the threshold, the block searches for the peak within the next look\_ahead values. Name this part the “active peak search”, which is indicated by d\_found = true. If the search continues for more than another call of work(.), I cannot predict the blocks behaviour, because I do not know the details of the scheduler, especially, where input and especially output indexing starts if no input items have been consumed in a previous call of work(.). If a peak is detected (d\_found = true), all samples being previous to the peak’s one are “consumed” (line 112: return tmp - 1), and d\_peak\_ind = 1 is set. Just for clarification: Does it matter that the allocated memory of output\_items[0] is noutput\_items of size, but a smaller number is returned from work(.)? (I do not think so) In the next call of work(.), the input samples with relative index starting from 0 are considered. Because this is a synchronized block (output items = returned nr. of “consumed” input items), from my understanding this is the peak’s sample (index 0, BTW: thus I think d\_peak\_ind = 0 should have been set in the previous function call) and all subsequent ones. If d\_found=true at the beginning of the function, this would mean that some samples are checked a second time. Although this might be inefficient, I do not consider this being the root of the problem. 1. The only way not to empty the input buffer is while d\_found = true, but then input values have to increase within look\_ahead. 2. Why is noutput\_items \>= 2 required (cp. Assert in line 65)? I haven’t got any idea how to proceede from here. Do you have any ideas/hints/comments? Thank you in advance. Mit freundlichen Gren / Best regards Stephan Ludwig Robert Bosch GmbH Corporate Sector Research & Advance Engineering, Communication Technology (CR/AEH4) Renningen 70465 Stuttgart GERMANY [www.bosch.com](http://www.bosch.com)[http://www.bosch.com](http://www.bosch.com) Tel. +49(711)811-8809 Fax +49(711)811-1052 Mobile +49(172)5630639 removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 14000; Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. Volkmar Denner, Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Dirk Hoheisel, Christoph Kbel, Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller