On Fri, Oct 21, 2011 at 1:06 PM, Achilleas Anastasopoulos
> 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.
> On 10/21/2011 3:19 PM, Tom Rondeau wrote:
>> On Thu, Oct 20, 2011 at 10:34 PM, Achilleas Anastasopoulos
>> 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
>> 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.