Re: [Discuss-gnuradio] Constellations in OOT projects

[Michael Berman]

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 Berman

On Thu, Sep 26, 2013 at 8:14 AM, Tom Rondeau <address@hidden> wrote:

On Tue, Sep 24, 2013 at 7:56 PM, Michael Berman <address@hidden> wrote:
> 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

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

> 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