On Thu, Jan 20, 2011 at 1:46 AM, Martin Braun <martin.br...@kit.edu> wrote: > 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. >
That makes sense. What kind of values would you output when you have more than 2 symbols? Would you just give the distances to the closest n points? >> 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. Good to know. > - 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? I've just implemented it for PSK but have to tidy it up a bit before pushing it to my github repo. Works fine for differential PSK, although I had to put map_bb blocks into the generic blocks to get gray coding working. > > 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 > > > _______________________________________________ > 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
