Re: Constellations in OOT projects

GNU Radio
1

On Fri, Sep 20, 2013 at 7:55 PM, Michael B. [email protected]
wrote:

attacking this task?

Thank you very much,

Michael B.

Hi Michael,
Please use a proper subject line in the future to help us sort and
keep track of things.

As to your question, that shouldn’t be a problem. You should be able
to create a class in your OOT module and inherit from
gr::digital::constellation (or one of it’s children). And just putting
it inside the gr::digital namespace. This will obviously now exist in
your own lib.so and not in libgnuradio-digital.so. So I’m
not sure what you mean by “sits inside constellation.{cc,h,i}”. If you
are in an OOT project, you wouldn’t be able to add this directly to
the gnuradio-digital library or Python module (ok, there’s a way to do
the latter by smashing it in during install, but that’s seriously ugly
business that you want no part of).

And use gr_modtool. Definitely the best, easiest, and preferred way of
setting things up. When creating your new class, use ‘gr_modtool add’
and for the ‘code type’ use ‘noblock.’

–
Tom
GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

2

Tom,

Thanks for the response. This is what i was thinking was the
appropriate
action, I just wanted to make sure. As for the header, I didn’t realize
I
didn’t add one until after I sent the email out; I’ll try to not let
that
one happen again.

Thanks,

Michael B.

3

I am having issues implementing what was discussed previously. I have
created an OOT module (constellation_theta), and placed it within the
gr::digital namespace. All of the cpp code is written and working fine.
As I am attempting to add a custom constellation, I used the existing
instances of constellations (bpsk, qpsk, etc.) as an example for my
constellation object as far as the swig .i files and the cpp files from
the
gr-digital section of the gnuradio gr-digital source for my new module.
When I attempt to run this module, I get the following python runtime
error:

…
File
“/usr/local/lib/python2.7/dist-packages/constellation_theta/constellation_theta_swig.py”,
line 102, in
constellation_theta = constellation_theta.make;
NameError: name ‘constellation_theta’ is not defined

This line is driven directly from the swig .i file, of which I copied
the
format from the …/gnuradio/gr-digital/swig/constellation.i file.
Comparing the generated .py files from the installed swig generated
code,
I also do not understand why I have so many differences from this. The
gnuradio code has the cpp class laid out inside the .py file perfectly,
with all of the exposed methods; however, my code has none of that, just
the basic constructor (which I don’t even want exposed to preserve the
shared pointer structure).

I am not sure where to go from this point on getting this up and
running,
any help would be greatly appreciated.

Thank you very much,

Michael B.

4

Upon looking at the generated *_swig.py files, I am seeing more of the
differences. For some reason my OOT module is not generating the python
wrapper for the constellation_theta class, it is only creating the
wrapper
for the shared pointer object. I am curious now as to what the gnuradio
swig interface files are doing elsewhere that are causing that build to
pick up the object files when only the shared pointer is called out in
the
swig .i file.

Thank you very much for the help,

Michael B.

5

Thank you for the advice, I have gotten this working now. It was a
user
error in that I was not including the gnuradio/digital/constellation.h
file
in the swig .i. Also to note for anybody in the future, I also had to
link
the libgnuradio-digital.so into the CMakeLists.txt file in the lib
directory at the end of the target_link_libraries line. This was due to
a
runtime python error about not being able to find the constellation
object
in the OOT .so object.

Thank you very much,

Michael B.

6

On Tue, Sep 24, 2013 at 7:56 PM, Michael B. [email protected]
wrote:

Michael B.
All I can suggest right now is to make sure your .h file is properly
included in the swig.i file. Notice that in digital_swig.i, it’s
included twice, once in line 51 (#include inside the %{ and %}) and
line 121 (as %include).

But also note the %include of constellation.i. This is needed to
Python-ize some of the interfaces.

Tom