On Wed, Jan 19, 2011 at 11:55:30AM -0700, Ben Reynwar wrote: > I'm new to all this, so I don't have a good handle on soft versus hard > decision making. My understanding is that a hard decision maker > simply returns the symbol value, and a soft decision maker would > return probabilities for various symbols values. Then this > probabilistic information would be interpreted by the decoder which > would make the hard decision for sets of symbols simultaneously. I > don't understand what receiver_cf is doing if it returning a stream of > floats.
You've got that right: a soft decider doesn't really decide, but rather gives a value how good the estimate is. Say you have a binary output, 1 and -1. A soft decider can also give any value in between. If you get a 0, then the soft decider really has no clue what was actually transmitted and instead of guessing a binary value, it relays this uncertainty. One place this is really important is the channel decoding. > On a related note, I've read that the minimum euclidean distance > minimizes the chance of error if you have white gaussian noise. Is > this always a sensible assumption or are there practical situations in > which a different measure would be better? If not, then the distance > could be used as a proxy for probability. If others measures are > sometimes better, then it would be nice to keep things more general. Just a couple of euro-cents I'd like to add: - White noise is a perfectly valid assumption. In most cases, your noise is WGN-ish anyway. If it isn't, then the constellation demodulator is not the right place to handle it, you'd use some kind of pre-whitening filter a priori. - I'd say if you have to implement a soft- and hard-decider for each constellation anyway, you're general enough. With the aforementioned point, this means the hard decider is sіmply always the minimum euclidean distance, as you said already. - After having a quick peek at your code, I wasn't quite sure if you've thought of differential PSKs? All that aside, I think this is a good approach. GNU Radio currently has a lot of fantastic DЅP code; what I miss is more structure, and I'm glad to hear about the plans to refactor the digital stuff. Cheers, MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association
pgp9ZW1uRj6XX.pgp
Description: PGP signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
