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
Free large file hosting. Send big files the easy way!. I am trying to transmit a RRC
pulse-shaped QPSK signal over an ideal (for the time being) channel,
matched filter, CLK recovery Mueller & Mller; 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 Gren / Best regards
Stephan Ludwig
Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication
Technology (CR/AEH4)
Renningen
70465 Stuttgart
GERMANY
Tel. +49(711)811-8809
Fax +49(711)811-1052
Mobile +49(172)5630639
[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