On Mon, Jan 17, 2011 at 12:10 AM, Ben Reynwar <b...@reynwar.net> wrote: > On Sun, Jan 16, 2011 at 2:52 PM, Tom Rondeau <trondeau1...@gmail.com> wrote: >> On Sat, Jan 15, 2011 at 1:40 AM, Ben Reynwar <b...@reynwar.net> wrote: >>> Hi all, >>> >>> What do people think of introducing a constellation object into gnuradio? >>> >>> It would hold the constellation points and also a decision-making function. >>> New modulations could then be easily created by subclassing a constellation. >>> >>> It would also mean that the decision-making function for a given >>> modulation could >>> easily be used by different receivers (i.e. the standard receiver and >>> the ofdm receiver would >>> both use the same decision making code for a given modulation). >>> >>> I've already had a go at implementing this on my repo. >>> >>> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/lib/general/gr_constellation.h >>> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/lib/general/gr_constellation_receiver_cb.h >>> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/python/gnuradio/blks2impl/qam.py >>> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/python/gnuradio/blks2impl/generic_mod_demod.py >>> >>> Cheers, >>> Ben >> >> >> Ben, >> Are you talking about something different than >> gr_constellation_decoder_cb? I haven't looked at your code, but it >> strikes me that what you want is similar to that decoder code (you can >> find its use in dbpsk.py and dbpsk2.py in >> gnuradio-core/src/python/gnuradio/blks2impl). >> >> My only suggestion for this part is to have a constellation_decoder_cf >> that would output soft symbols instead of hard symbols. >> >> Let me know if I've missed something in what you are asking. >> >> Thanks, >> Tom >> > > gr_constellation_decoder_cb uses minimum distance to determine the > correct symbol. I would guess this would become a bottleneck for > large constellations. > > My suggestion was to create c++ classes representing constellations which > would > contain both the constellation points and a function to determine what > point a given > complex number corresponded to. This way different decision making > functions could > be written for each modulation (e.g. for PSK you just bin based on the > phase, for QAM you > bin based on the real and imag components.) These classes would not > be signal-processing > blocks, but rather would be passed to blocks as arguments. > > Separating out this code from the receivers would mean that it didn't > have to be implemented > separately for each receiver. > > This would effect gr_constellation_decoder_cb in that it would take a > constellation object when initialized, > > e.g. gr_constellation_decoder_cb::gr_constellation_decoder(const > gr_constellation_sptr constell) > > and would use constell.decision_maker to determine what symbol value to > return.
Ok, Ben, I got you. I think this sounds like a good direction. Looking at your code, I notice that it somewhat duplicates the constellation_decoder and somewhat duplicates the mpsk_receiver, but it is perhaps better than either. We already have a lot of duplicated functionality here and blocks that need to get pruned and some that need to be cleaned up, but we have to do this carefully and slowly. So here's what I'm thinking. First, there has been ongoing discussion about a refactoring of the build system. We're going to take this a step at a time, but one of the first major steps is to build a gr-digital top-level component and move all of the digital modulation code here. We would then import from gr.digital instead of gr for things like the Costas loop and mpsk_receiver. As we do this change, I would want to take your ideas to simplify and streamline the digital code we have. This move will break the API of some blocks and we will probably remove other blocks as well. We can do this under the gr_digital scope as everyone moves over to it while leaving but deprecating the current digital code in gnuradio-core to be removed at a later time. The other thing that I would really like to see us do is, like I said before, make the constellation decoders able to output soft symbols. This could just be by having a "decision_maker_hard" and "decision_maker_soft" function for each decoder. Then we can have receiver_cb and receiver_cf depending on which type we want for a particular application. How does this sound? Tom _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
