Re: [Discuss-gnuradio] Constellations in OOT projects

[Michael Berman]

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 Berman

On Tue, Sep 24, 2013 at 1:16 PM, Michael Berman <address@hidden> wrote:

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 <module>

    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 Berman

On Mon, Sep 23, 2013 at 9:21 AM, Michael Berman <address@hidden> wrote:

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 Berman

On Sat, Sep 21, 2013 at 8:09 AM, Tom Rondeau <address@hidden> wrote:

On Fri, Sep 20, 2013 at 7:55 PM, Michael Berman <address@hidden> wrote:
> I am attempting to add a custom constellation class to be used with the
> generic_mod_demod object for digital PSK.  I have the code working as a
> simple addition to the gnuradio source with a re-compilation, however I
> would like to set this up similar to an Out Of Tree module (although it
> isn't entirely a standalone module).  Would the way I go about approaching
> this be the same as the adding an Out Of Tree module tutorial on the
> gnuradio website?  Or would there be a preferred method than the gr_modtool.
> I would like to set this up so that the code I add sits in the gr::digital
> scope and have everything look as though it all sits in the
> constellation.{cc, h, i} files.  Does anybody have recommendations for
> attacking this task?
>
>
> Thank you very much,
>
> Michael Berman

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