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 [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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
