discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Why not use matched filter in GMSK demodulator


From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] Why not use matched filter in GMSK demodulator
Date: Thu, 30 Jul 2009 20:31:44 -0400
User-agent: Thunderbird 2.0.0.22 (Windows/20090605)



Shizheng Li wrote:
Thank you for your reply!

I think the generic receiver for CPM you mentioned is the optimal receiver for CPM and the projection onto basis functions (correlation with basis functions) is equivalent to the matched filters, am I right?

yes; however see the comment i made about the colored noise and the detection vs detection/estimation in my earlier post

Go back to the GMSK transceiver I mentioned in the file

http://gnuradio.org/trac/browser/gnuradio/branches/releases/3.2/gnuradio-core/src/python/gnuradio/blks2impl/gmsk.py

The modulator structure is NRZ mapping --> Gaussian filter --> FM modulator
And the demodulator structure is FM demodulator --> Timing recovery --> detector

I think after the FM demodulator the signal can be viewed as a PAM modulated signal and what if I add a matched filter before the timing recovery? Can I improve the BER performance? I think the matched filter can maximize the output SNR. Will it make the detector work better?

you are already suboptimal when you do FM demodulation...

Best regards,
Shizheng Li



On Thu, Jul 30, 2009 at 2:07 PM, Achilleas Anastasopoulos <address@hidden <mailto:address@hidden>> wrote:


    There is no reason why you should not use a matched filter.
    However make sure you understand that a symbol-spaced MF
    generates sufficient statistics only for detection,
    ie, not for (epoch) synchronization.
    Also note that in the case of GMSK (CPM in general) a bank of MFs
    will generate colored noise.
    Another appropriate implementation of a front end projects the
    entire oversampled signal to a set of orthonormal basis functions
    which has the advantage of generating white noise samples for
    (simpler) further processing.

    Take a look at how a generic receiver for an arbitrary CPM
    is developed in

    http://gnuradio.org/svn/gnuradio/trunk/gr-trellis/src/examples/test_cpm.py

    There, the signal is first projected to its basis functions (which
    is calculated by a helper python application in "fsm_utils.py")
    to generate a sufficient statistic which is then used in conjunction
    with trellis decoding to do soft-decision sequence detection.
    What is missing though is epoch and phase syncronization (to do at
    some point...)

    Achilleas


    _______________________________________________
    Discuss-gnuradio mailing list
    address@hidden <mailto:address@hidden>
    http://lists.gnu.org/mailman/listinfo/discuss-gnuradio




--
Best Regards,
Shizheng Li
Ph.D. Student and Research Assistant
Department of Electrical and Computer Engineering
Iowa State University






reply via email to

[Prev in Thread] Current Thread [Next in Thread]