discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Feature #394


From: Andrew Davis
Subject: Re: [Discuss-gnuradio] Feature #394
Date: Fri, 24 Feb 2012 21:48:14 -0500

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]