On Fri, Feb 24, 2012 at 9:48 PM, Andrew Davis <glneolistm...@gmail.com>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 <glneolistm...@gmail.com> > 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 <t...@trondeau.com> wrote: > >> > >> On Tue, Feb 7, 2012 at 9:52 PM, Andrew Davis <glneolistm...@gmail.com> > >> 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 > >> > > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
