I agree with Steven, while there are definitely more "optimal" solutions like MLSE they don't always make sense for every application. GSM phones and the like have dedicated DSP resources to run a Viterbi algorithm but is this doable on the typical gnu users computer? I will defer to the experts on this but from my own low power(< 20 mA) portable wireless experience the ad-hoc techniques sometimes make more sense.
-Jeff -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Clark Sent: Friday, June 06, 2008 10:58 AM To: Ben Wojtowicz Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] gsm gmsk demodulation > On 6/6/08, Bob McGwier <[EMAIL PROTECTED]> wrote: >> >> This is not my professional experience. The sounding data is used to find >> the channel and then the data symbols are soft detected through a "viterbi >> equalizer" in every implementation I am aware of that is any good at all >> with the exception of one I wrote several years ago which estimates the data >> given the channel and then restimates the channel and then the data and then >> the channel and then the data, etc. MMSE and not MLE is the goal and this >> was a suboptimal implementation of the EM algorithm. It was suboptimal >> since it did not estimate the data bauds using ALL observations but only >> those between sounding data. Further, assumptions that the conditional >> distributions of the data given the observations could be described in 1st >> and 2nd product moments (not Gaussian but having similar properties). This >> has been published by many. The computational complexity is on a par with >> the viterbi equalizer and it outperforms it. >> >> Most of the cell phones I know use the Viterbi equalizer. >> >> Bob On Fri, Jun 6, 2008 at 9:41 AM, Ben Wojtowicz <[EMAIL PROTECTED]> wrote: > I agree with Bob, most gsm demodulators I have seen use a viterbi equalizer > (sometimes called MLSE equalization). > Ben > > Ok, good to hear from guys with more experience. So you would have a viterbi equalizer to mitigate ISI, and then wrap that in a layer of forward error correction? Is this computationally feasible for cpu-based software radio? Sounds like it could get computationally expensive pretty quick... -Steven _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio