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

[Bob McGwier]

This is NOT optimal.  CPM and FM detector is a noncoherent detection of 
MSK/GMSK.  The near optimal receiver for MSK and GMSK does two things:

1) it does a coherent detection of the received symbols and
2) it does something like a trellis/viterbi decode for the correct phase 
path through the symbols using the fact that at each symbol time the 
phase transition is +/- pi/2.

Should you follow this type of construction, the performance of coherent 
detection/with "viterbi error correction" for the paths, the performance 
is approximately the same as QPSK with the same bit rate.

Bob


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?
>
> 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?
>
> 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>   


--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"You don't need to see the whole staircase, just
take the first step.", MLK.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn