Achilleas,
I'm rooting through your test_cpm.py code, and I have a few questions on what's
going on in there. Specifically:
What is the purpose of the two filters with coeffs MF[0,1]?
Why do you frequency-shift the modulated signal by -f0T to bring the "low"
frequency to zero before feeding it to the filters?
What is the purpose of the streams_to_stream conversion?
Sorry in advance if these are trivial questions.
--n
> Date: Thu, 30 Jul 2009 20:31:44 -0400
> From: anas...@umich.edu
> To: shizhen...@gmail.com
> Subject: Re: [Discuss-gnuradio] Why not use matched filter in GMSK demodulator
> CC: Discuss-gnuradio@gnu.org
>
>
>
> 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
> > <anas...@umich.edu <mailto:anas...@umich.edu>> 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
> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> > 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
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_________________________________________________________________
NEW mobile Hotmail. Optimized for YOUR phone. Click here.
http://windowslive.com/Mobile?ocid=TXT_TAGLM_WL_CS_MB_new_hotmail_072009
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
