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<http://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 Kübel, Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller
teat_peak_search_error.grc
Description: teat_peak_search_error.grc
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
