[Discuss-gnuradio] gr::blocks::peak_detector2_fb un reproducible behavior

[Ludwig Stephan (CR/AEH4)]

Hi Community,

I have a problem concerning the gr::blocks::peak_detector2_fb class (as far as 
I think). I does not seem to perform deterministically, although the 
constraining blocks are deterministic.

But first, please let me introduce myself:
I am Stephan Ludwig from Stuttgart, Germany. I did my diploma in communications 
engineering at University of Ulm and then was for six years of PhD time with 
Universitaet der Bundeswehr Munich, where I build FPGA/C++-based data link 
demonstrators for 'special applications'. Meanwhile, I have been using GNU 
Radio for about 3 month (full time) and already had a steep learning curve 
mainly supported by the source code ;-) 

Regarding the problem: please consider the attached GRC model with some screen 
shots in the zip-file located at https://www.sendspace.com/file/bwj7bo. I am 
trying to transmit a RRC pulse-shaped QPSK signal over an ideal (for the time 
being) channel, matched filter, CLK recovery Mueller & Müller; then a 
correlator on the Barker training sequence of symbols. Finally, I am trying to 
detect the correlation's peak, which behaves strangely.

If you consider this DSP chain, everything seems to be behaving 
deterministically, doesn't it? Source from File (The disabled blocks were used 
for generating the file.) generates identical patterns in every simulation run. 
Afterwards not one random process acts on the signal.

Hence, the simulation should produce reproducible results, but it does not! 
Start the simulation several times and you will notice that the 
peak_detector2_fb will output drawn from some patterns (cp. screen shots)

Do you have any idea why this happens?
I searched the wiki, stackoverflow, the list archive, and of course google. The 
only think I found was
http://lists.gnu.org/archive/html/discuss-gnuradio/2010-08/msg00384.html ,
but from the source code (peak_detector_XX_impl.cc.t) I did not get the point 
about the negative input. is this still valid?

I think, I understood the block's source code quite well, but cannot determine, 
why a second peak occurs in one of the cases, within the look-ahead window? 
From my understanding, this should not happen.
Could you please help me in hunting down this strange behavior?

Environment: I am using a fresh Kubuntu 14.10 install with (few days old) 
pybombs/gnuradio/grc from git.
I am executing the model from GRC 3.7.6git-214-g56f69533, get no error messages.

BTW1: If you have any suggestions on improving the model, any hint is very 
welcome.
BTW2: How would you neatly proceed in order to separate the frames from each 
other with this peak_detect trigger? Convert to a tagged stream (how?)? 
Header/Payload Demux?

Thanks for any help.

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