Gr-trellis broken on next branch

GNU Radio
1

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

2

On Thu, Oct 20, 2011 at 10:34 PM, Achilleas A. <
[email protected]> wrote:

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

3

The gnuradio “next” branch builds fine for me but “make check” fails for
gr-trellis.

Sean

From: discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid] on behalf
of Tom R. [[email protected]]
Sent: Friday, October 21, 2011 3:19 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] gr-trellis broken on next branch

On Thu, Oct 20, 2011 at 10:34 PM, Achilleas A.
<[email protected]mailto:[email protected]> 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

4

Sean,

this is strange…
I built it with cmake and passes all checks…

Achilleas

5

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

6

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 A.

7

On Fri, Oct 21, 2011 at 11:51 PM, Ben R. [email protected] wrote:

The constellation classes themselves are defined in gr-digital, so all

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