discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gr-trellis broken on next branch


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] gr-trellis broken on next branch
Date: Tue, 25 Oct 2011 19:02:24 -0400

On Fri, Oct 21, 2011 at 11:51 PM, Ben Reynwar <address@hidden> 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
<address@hidden> 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
>> <address@hidden <mailto:address@hidden>> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

[Prev in Thread] Current Thread [Next in Thread]