Peak_Detector2 stalls simulation

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.comhttp://www.bosch.com

Tel. +49(711)811-8809
Fax +49(711)811-1052
Mobile +49(172)5630639
[email protected]mailto:[email protected]

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