[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] gr::blocks::peak_detector2_fb un reproducible behavio
Ludwig Stephan (CR/AEH4)
[Discuss-gnuradio] gr::blocks::peak_detector2_fb un reproducible behavior
Fri, 12 Dec 2014 12:56:24 +0000
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
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
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?)?
Thanks for any help.
Mit freundlichen Grüßen / Best regards
Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication Technology
Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr.
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
|[Prev in Thread]
||[Next in Thread]|
- [Discuss-gnuradio] gr::blocks::peak_detector2_fb un reproducible behavior,
Ludwig Stephan (CR/AEH4) <=