On Tue, Apr 21, 2015 at 2:23 PM, Frank Fu wrote:
> Thanks for your response, Tom. So basically, the documentation needs to
> be updated to better reflect the desired behavior of the block. My
> interpretation of the behavior would be something like “The look_ahead
> value creates a minimum sear
Thanks for your response, Tom. So basically, the documentation needs to be
updated to better reflect the desired behavior of the block. My interpretation
of the behavior would be something like “The look_ahead value creates a minimum
search window. The peak is first searched within this windo
e making a decision. And using
set_output_multiple with large values has, in my experience, a performance
hit on a flowgraph.
Tom
[1]
http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1peak__detector2__fb.html
> ---
> From: Tom Rondeau
> Subject:Re: [Discuss-gnuradio]
contribute to a fix and
help make the peak detector block more stable, but I would have to know more
about how the block should behave. Any comments or insights are appreciated.
Frank Fu
---
From: Tom Rondeau
Subject:Re: [Discuss-gnuradio] Some misconceptions about the
Achilleas,
I think you've completely failed to understand the issue from my
perspective. I do NOT disagree that there is a bug in the code. I also do
NOT disagree that most of what you've tried to do in the rewrite is the
correct way to rethink the block. What I have a problem with is that you've
Hi all,
recently there has been some discussion regarding the peak_detector2 block,
both in the github/gnuradio (pull request 404) as well as in the issue
tracker (issue 783).
It is now well accepted that this block is buggy: there are cases the work
function returns -1, which is a bug (see issu