On Fri, Oct 21, 2011 at 11:51 PM, Ben Reynwar <b...@reynwar.net> wrote:
> 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 So I have the same opinion as Ben here with regards to the use and location of these things, especially to avoid duplication of code. I have fixed the trellis examples and will be pushing updates to master that should fix things. Tom > 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 >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
