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

[Nick Foster]

Shizheng,

For an alternative noncoherent GMSK demodulator that does a lot better than the stock one, see the GMSK receiver I put together for my AIS project:

https://www.cgran.org/wiki/AIS

It uses a modified decision-feedback equalizer to estimate the channel and remove ISI. It seems to do pretty well for my application. If you have a continuous signal (i.e., not in short bursts) you can even use the stock LMS DFE block. My application uses short packets, so I run them through the DFE multiple times to train it. The DFE avoids the colored-noise problem you get when you invert the channel with a matched filter. It's pretty simple, but it works.

--n

> Date: Thu, 30 Jul 2009 20:31:44 -0400
> From: address@hidden
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] Why not use matched filter in GMSK demodulator
> CC: address@hidden
>
>
>
> 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
> >
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

---

Bing™ brings you maps, menus, and reviews organized in one place. Try it now.