The block I added into gr-trellis is trellis_constellation_metrics_cf. This block is equivalent to trellis_metrics_c in that it takes a stream of symbols and outputs a stream of metrics. The difference is that treliis_constellation_metrics_cf uses a constellation object (which is passed to it upon initialisation) to perform the symbol to metrics conversion. trellis_metrics_c calculates the distance between each symbol and each constellation point, which could clearly be improved upon by the modulation specific method in a constellation object, especially for large constellations.
The constellation classes themselves are defined in gr-digital, so all modulation specific code would be contained in gr-digital. The dependency on gr-digital enables modulation specific code to be accessed by the gr-trellis code without requiring that modulation specific code be in gr-trellis itself. I think that's a pretty logical arrangement. >>> from gnuradio import digital, trellis >>> constellation = digital.qam.qam_constellation(16) >>> symbols_to_metrics = trellis.constellation_metrics_cf(constellation, >>> digital.TRELLIS_EUCLIDEAN) Although currently there's just the one block with a dependency on gr-digital, going forward it might be nice to have combined blocks using constellation objects, so I would be disinclined to move it out of gr-trellis. Cheers, Ben On Fri, Oct 21, 2011 at 1:06 PM, Achilleas Anastasopoulos <anas...@umich.edu> wrote: > Tom, > > this requires some further discussion. > > We need to know what is the plan with gr-digital. > In some sense EVERYTHING can be included in there, > however this is not a good design. > > gr-trellis is not an "implementation of digital > modulation"; it provides digital encoding/decoding techniques > that is important to keep modulation INDEPENDENT. > This was the design philosophy from the first line of > code that went into this and can be seen in all the examples > that are provided: the only aspect of these examples that depends on > a specific modulation is the lookuptable of the constellation. > > I would like to welcome more users/developers to comment > on this before we make any significant changes to the module. > > best, > Achilleas > > > On 10/21/2011 3:19 PM, Tom Rondeau wrote: >> >> On Thu, Oct 20, 2011 at 10:34 PM, Achilleas Anastasopoulos >> <anas...@umich.edu <mailto:anas...@umich.edu>> wrote: >> >> After installing the next branch i realized that gr-trellis is not >> working properly! >> >> This is due to some work (by Ben Raynwar) that makes gr-trellis >> dependent on gr-digital (???) >> In particular the constants related to trellis_metric_type.h cannot be >> accessed in python/grc >> as part of the trellis module, but as part of the digital module >> (this problem appears for instance if you run some of the pccc/sccc >> examples in gnuradio-examples/grc/trellis). >> >> This can be an easy fix (import digital in all the grc blocks >> requiring metric types, and make appropriate changes). >> >> However I wonder what is the point of making a self-contained >> module like gr-trellis dependent on another module (gr-digital) >> If the only reason is to to use the "constellation" object in the >> "metrics" blocks then these blocks should >> reside in the gr-digital module instead of the gr-trellis, so that the >> latter can still be self-contained. >> >> Ben, can you please explain what is your rational in doing these >> changes. >> >> thanks, >> Achilleas >> >> >> >> Achilleas, >> This was my doing. Ben had moved the metric types into gnuradio-core to >> work with his constellation work, so I moved them over with everything >> else into gr-digital. I then made gr-trellis depend on gr-digital >> because of this. Because gr-trellis is an implementation of digital >> modulation, it makes sense that it should depend on gr-digital. >> >> I made sure that gr-trellis would both build and pass 'make check,' so >> the QA code is obviously not testing all of the proper dependencies and >> cases in gr-trellis. We need to fix that to make sure the applications >> still run as we move stuff around. >> >> Depending on what gr-trellis requires out of gr-digital, we could >> possibly import digital into the trellis module inside of the >> __init__.py file. >> >> Tom >> > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
