discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 95, Issue 10


From: Andrew Ge
Subject: [Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 95, Issue 10
Date: Mon, 11 Oct 2010 09:41:22 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4

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

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]