# Peak\_Detector2 stalls simulation **URL:** \ **Category:** GNU Radio\ **Created:** [January 3, 2015, 12:36am UTC](https://www.ruby-forum.com/t/peak-detector2-stalls-simulation/233678 "2015-01-03T00:36:30Z")\ **Posts on this page:** 2\ **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 3, 2015, 12:36am UTC](https://www.ruby-forum.com/t/peak-detector2-stalls-simulation/233678/1 "2015-01-03T00:36:30Z")
Stephan, We have worked with this block and realized it has a bug (not just an inefficient functionality). This is easy to see if you consider what happens when the first time work is called, the threshold is passed, a peak is found in item “i” and so “d\_peak\_ind” is set to “i”, but there are less that d\_lookahead\_items to be processed. Then suppose the second time the work is called, no other peak is found and d\_lookahead\_remaining goes to 0. Then the output buffer will be accessed at: “optr[d\_peak\_ind] = 1” which may not even be a valid access since the value of d\_peak\_ind was set to “i” in the previous work call! Anyway, I attach a fix to this (we were supposed to post it sooner on the list but got delayed by some other issues). Please note that in this current form the functionality is a bit different than the one suggested in the manual, ie, the peak finder ONLY looks ahead d\_lookahead items from the point the threshold is crossed, but it does not reset this window every time a new peak is found within the window. It should be pretty easy to do this as well… Please let us know if you have any comments. best Achilleas ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 5, 2015, 10:52am UTC](https://www.ruby-forum.com/t/peak-detector2-stalls-simulation/233678/2 "2015-01-05T10:52:37Z")
Hello Achilleas, Thank you for your comments as well as your implementation. I very much like the clear separation that in every call of work(.) only one state is active. Sorry, but I cannot follow your bug description. In line 110 (actual git version, which do you use?), d\_peak\_ind = 1 is set in the case you describe, right? During the first call, the function does not return noutput\_items as amount of processed samples, but only the amount up to the peak’s index (-1). From my understanding of the scheduler, this leaves the (noutput\_items - d\_peak\_ind + 1) remaining samples in the input buffer, and thus the first sample (index 0) in the next work(.)-call should the one before the d\_peak\_ind of the previous call. Since all output items are held back up to this sample, the optr[.]=1 should come at the right position. But I am not sure about that, especially not about how the scheduler handle the case, if the output vector is longer than the return value of work(.). Hence my question about the (to me) unknown behavior of the scheduler in my original post. But I think, it is even worse! In the case you describe (look\_ahed does not count down to 0 in the very same run of work(.) like the peak), in a second call of work(.) all samples from the triggering value on (“old values”) are reconsidered. The old values decreased d\_look\_ahead\_remaining in the first call and now decrease this variable again, hence twice. And there is another bug in the original: If you have a single value above the threshold (within look\_ahead), the very next sample is indicated being the peak. This is because d\_peak\_ind is not set in the if-case// above threshold. Your code circumvents this bug, because triggering value is reconsidered in work(.), if in look\_ahead mode. Meanwhile, I implemented another peak\_search (attached), which also has a period of being quiet after a detected peak. I.e., if look\_ahead passed, no peak is searched until a given amount of samples passed. This is quite handy, if you have a fixed preamble/data structure. I think, I will combine both of our approaches. Just in case other users might want to use your block, I add some notes on the behavior of your code: 1. The average is updated with the first sample above the threshold 2. As with the original, the average value is not updated during the look\_ahead phase 3. The threshold is as given in the documentation as avg_threshold\_factor\_rise (the original is inconsistent with doc as avg_(1+threshold\_factor\_rise) ) @Martin/Tom/Marcus: How should we handle this? I prefer changing code, since this parallels my intuition of a threshold\_factor, but this will change behavior. Else adapt doc to actual code. 4. Concerning your (@Achilleas) comment on look\_ahead not being reset on finding a new max value: The original does not reset look\_ahead in such a case either. But in which documentation did you find a comment on that? I only have [GNU Radio Manual and C++ API Reference: gr::blocks::peak\_detector2\_fb Class Reference](http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1peak __detector2__ fb.html) PS: Thanks for your great book, Achilleas. It helped me a lot with my PhD on CPM comm. over non-coherent doubly-selective fading channels. The first chapters show a very clear and concise general concept of detection. I wish, I had found that earlier. Best regards Stephan Ludwig Robert Bosch GmbH Corporate Sector Research & Advance Engineering, Communication Technology (CR/AEH4) Renningen 70465 Stuttgart GERMANY > **[Want to know how to live #LikeABosch?](https://www.bosch.com/)** > > Moving stories and inspiring interviews. Experience the meaning of "invented for life" by Bosch completely new. Visit our international website. Tel. +49(711)811-8809 Fax +49(711)811-1052 Mobile +49(172)5630639 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 Kübel, Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller Von: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Im Auftrag von Achilleas Anastasopoulos Gesendet: Samstag, 3. Januar 2015 00:35 An: Ludwig Stephan (CR/AEH4); removed\_email\_address@domain.invalid Betreff: [Discuss-gnuradio] Peak\_Detector2 stalls simulation Stephan, We have worked with this block and realized it has a bug (not just an inefficient functionality). This is easy to see if you consider what happens when the first time work is called, the threshold is passed, a peak is found in item “i” and so “d\_peak\_ind” is set to “i”, but there are less that d\_lookahead\_items to be processed. Then suppose the second time the work is called, no other peak is found and d\_lookahead\_remaining goes to 0. Then the output buffer will be accessed at: “optr[d\_peak\_ind] = 1” which may not even be a valid access since the value of d\_peak\_ind was set to “i” in the previous work call! Anyway, I attach a fix to this (we were supposed to post it sooner on the list but got delayed by some other issues). Please note that in this current form the functionality is a bit different than the one suggested in the manual, ie, the peak finder ONLY looks ahead d\_lookahead items from the point the threshold is crossed, but it does not reset this window every time a new peak is found within the window. It should be pretty easy to do this as well… Please let us know if you have any comments. best Achilleas