# Re: gr::blocks::peak\_detector2\_fb un reproducible behavior

**URL:** <https://www.ruby-forum.com/t/re-gr-peak-detector2-fb-un-reproducible-behavior/233430>\
**Category:** GNU Radio\
**Created:** [December 12, 2014, 5:31pm UTC](https://www.ruby-forum.com/t/re-gr-peak-detector2-fb-un-reproducible-behavior/233430 "2014-12-12T17:31:10Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**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:** [December 12, 2014, 5:31pm UTC](https://www.ruby-forum.com/t/re-gr-peak-detector2-fb-un-reproducible-behavior/233430/1 "2014-12-12T17:31:10Z")

</div>

Hello,

a short update before the weekend:  
I was not able to hunt down the problem of non-reproducibility, but  
another one.

I had an input signal, which had its max. value as the first value  
getting over the (very high) threshold. This value is not taken as the  
peak, but any second but largest value within the look\_ahead window.  
The reason for that is that in line 73ff. of peak\_detect\_fb\_impl.cc  
d\_peak\_val/d\_peak\_ind are not set, but only with the next iteration,  
then starting from line 84f (because any value \> -inf).

A suitable test case for the qa\_peak\_detector2.py file has input vectors  
data = [0, 0, 10, 3, 4, 5, 6, 7, 8, 9,  
5, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0]  
expected\_result = (0, 0, 1, 0, 0, 0, 0, 0, 0, 0,  
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)

One could change line 73ff. like this  
d\_peak\_val = iptr[i];  
d\_peak\_ind = I;

but, then there remains a problem with this test case:  
data = [10, 0, 1, 3, 4, 5, 6, 7, 8, 9,  
5, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0]  
expected\_result = (1, 0, 0, 0, 0, 0, 0, 0, 0, 0,  
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)

The first run of work() will output 0 items, if the look\_ahead window is  
larger than noutput\_items (=the amount of \_in\_put items), and the  
assert(noutput\_items \>= 2) hurts. Subsequent calls of work() will output  
0 items as long as the amount of regarded items is smaller than the  
window length.

Can anybody imagine/explain, why this whole thing stalls? Do you have  
any ideas how to get out of this miserable position?

Thank you for any help.

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 Kbel,  
Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller
