discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Peak_Detector2 stalls simulation


From: Ludwig Stephan (CR/AEH4)
Subject: [Discuss-gnuradio] Peak_Detector2 stalls simulation
Date: Fri, 2 Jan 2015 17:13:08 +0000

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
<source>
<name> avg_out</name>
<type>float</type>
</source>
]
 
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.
 
2) The only way not to empty the input buffer is while d_found = true, but then input values have to increase within look_ahead.
 
3) 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 Grüßen / Best regards
 
Stephan Ludwig
 
Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication Technology (CR/AEH4)
Renningen
70465 Stuttgart
GERMANY
www.bosch.com
 
Tel. +49(711)811-8809
Fax +49(711)811-1052
Mobile +49(172)5630639
address@hidden
 
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
 
 
 

Attachment: teat_peak_search_error.grc
Description: teat_peak_search_error.grc


reply via email to

[Prev in Thread] Current Thread [Next in Thread]