discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] Re: GNU Radio roadmap


From: Tom Rondeau
Subject: [Discuss-gnuradio] Re: GNU Radio roadmap
Date: Sat, 16 Oct 2010 17:18:21 -0400

On Wed, Oct 13, 2010 at 1:20 PM, Andrew Ge <address@hidden> wrote:
>  Tom,
>
> You have been doing some good work in using more efficient filters; have you
> integrated your code into GNU Radio code base yet? If there is a working
> version, could you please tell me where I can find it? Is it in the
> development version or in GNU Radio 3.3 release version.
>
> More importantly, which function modules are using the new filters?
>
> Thanks,
> Andrew

Andrew,
I'm not entirely sure which filter work you are talking about. If
you're thinking of the polyphase filterbank stuff, all of those are in
gnuradio-core/src/lib/filters/gr_pfb_*. You can see examples of all of
them in gnuradio-examples/python/pfb. In fact, I'm about to push the
synthesis filterbank block right now, which mostly completes the PFB
blocks.

There's some other IIR work that I started a while ago that's been put
on hold while we get some other stuff going. Regarding these filters,
they turn out to not be too much more efficient than the equivalent
FIR filter; especially when you use the FFT version of the FIRs. What
you get out of the IIR filters, though, is a lower group delay.
Because I've been mostly concerned with speed and not group delay,
when I got the numbers back from the IIR filters, it dropped lower on
my list of things to complete.

Tom


>> Message: 1
>> Date: Sat, 9 Oct 2010 12:08:55 -0400
>> From: Tom Rondeau<address@hidden>
>> Subject: Re: [Discuss-gnuradio] GNU Radio roadmap
>> To: "Pandeya, Neel L."<address@hidden>
>> Cc: address@hidden
>> Message-ID:
>>        <address@hidden>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> On Tue, Oct 5, 2010 at 7:36 PM, Pandeya, Neel L.<address@hidden>
>>  wrote:
>>>
>>> Hello:
>>>
>>>
>>>
>>> What is the roadmap for GNU Radio releases over the next 12 to 18
>>> months??
>>> What new features are planned?? Will the next release be a minor release
>>> (3.3.1), or major release (3.4.0)?? When is the next release planned
>>> for??
>>> Any insight is much appreciated. Thanks.
>>>
>>>
>>>
>>> --Sunil
>>
>> Sunil,
>>
>> Thanks for asking. That's a fair question, and I haven't been ignoring
>> it. The problem is, we don't have a really well-defined roadmap right
>> now, but it's something we are working on. By "we," I'm mostly talking
>> about Johnathan Corgan and myself. If I tried to tell you everything
>> we are thinking about for the future, it would be a) a really long
>> list and b) pretty incoherent. We have a few big ideas coming down the
>> line, but it's going to take some time still, and we need a bit more
>> time to define when we can properly role them out and in what
>> releases.
>>
>> I will give you some insight into the next couple of things we want to
>> do in the immediate future.
>>
>> 1. Rework the USRP-based examples to use UHD and get rid of
>> duplication (usrp_thing.py and usrp2_thing.py)
>>
>> 2. Refactor the build system. This is pretty major from the developers
>> side but hopefully fairly transparent to the user (if we do it right,
>> of course). This will make more top-level blocks that will be mostly
>> split out of gnuradio-core. The main purpose of this is to make
>> libgnuradio-core hold just what you need to get the runtime engine
>> working. We will then have a separate library for all of the signal
>> processing blocks. We also want to move all of the digital modulation
>> stuff (including OFDM) into its own top-level block space.
>>
>> This work is to help with a few issues. First, ease up the
>> requirements for getting the runtime engine installed, and second,
>> make it easier to understand how things interact. Exposing the second
>> bit of information will, hopefully, allow people more easily work with
>> the existing blocks as well as add their own.
>>
>> A third consequence of this move is that I want to improve the code
>> maintenance by making unit testing procedures that exercise more of
>> the code and make sure we don't let bit rot bite us. With the new
>> structure, we expect to improve on the testing procedures and help
>> make it obvious how to add your test code.
>>
>>
>> There are a few other ideas coming out soon that I want to announce
>> before December. My timeline here is due to a tutorial on GNU Radio
>> that I am giving at the WinnForum's SDR Technical Conference.
>>
>> So more soon, but I hope that helps give you some clues as to where we
>> are headed.
>>
>> Tom
>>
>>
>
>



reply via email to

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