Re: [Discuss-gnuradio] Feature #394

[Tom Rondeau]

On Fri, Feb 24, 2012 at 9:48 PM, Andrew Davis <address@hidden> wrote:

Ok, I've got a branch on github:
https://github.com/glneo/gnuradio-davisaf/tree/optfir with optfir
ported and working in C++, it's part of gr ( gr.optfir ) like firdes.
This keeps the filter design tools together and allows the old optfir
to still be imported and used until I can get all the examples ported
( which will just be changing "optfir" to "gr.optfir" )

This is kinda just an update, it will probably not be ready for
merging until I finish porting the blks2 hier to C++. Then all the
examples can be done in both python and C++, hopefully this opens up
the API a bit.

Andrew,

Thanks. It might be easier to handle these in stages from a merge standpoint. Since you're just adding stuff, it's easy to add bits and pieces. If the optfir is ready, we can look into merging it while you make another branch for other conversions to C++.

Thanks!

Tom

 

On Wed, Feb 8, 2012 at 11:27 PM, Andrew Davis <address@hidden> wrote:
> Thanks, I think i'll work on QA too while i'm at it then.
>
>
> On Wed, Feb 8, 2012 at 10:32 PM, Tom Rondeau <address@hidden> wrote:
>>
>> On Tue, Feb 7, 2012 at 9:52 PM, Andrew Davis <address@hidden>
>> wrote:
>>>
>>> Hello all,
>>>
>>> I would like to help expand the C++ API, so I'm attempting to work on
>>> Feature #394 or "Re-implement hierarchical blocks currently living in blks2
>>> in C++ and put into gnuradio-core/src/lib/hier." I've started on am_demod.py
>>> but this requires optfir, which is also in python, I think this should also
>>> be available to us C++ users, so i'm converting it too.  I'm new to GnuRadio
>>> and would like to know if i'm on the right track before I get to far. The
>>> files so far are included.
>>>
>>> Thank you.
>>
>>
>>
>> Hi Andrew,
>> It looks to me like you're on the right track! Thanks for making a go at
>> it.
>>
>> So you seem to have the general style correct in the files that I looked
>> at. Once it's coded, the ultimate test is, obviously, to make sure that the
>> data produced by any of these guys is the same as is produced by the Python
>> versions. This is a good case where the QA code would be useful, so we would
>> have a set of tests with known output that you could compare against the new
>> implementations. Unfortunately, I don't see an QA for the optfir, but it
>> would probably be good to have one.
>>
>> Tom
>>
>