Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?

[Martin Braun]

On Mon, May 23, 2011 at 11:50:52PM +0400, Alexander Chemeris wrote:
> Hi community,

Hi Alex,
 
> Our WiMAX Scanner project (http://code.google.com/p/wimax-scanner/)
> approaches the moment when we should start writing C/C++ code - our
> Matlab model decodes broadcast messages from all recordings we have on
> hands.

That's great. I think GNU Radio would benefit from having big, cool
projects.
Here's my thoughts and experiences:

> At this point we have to make a choice - rely on GnuRadio or create
> our own framework. Until recently I was sure would create our own
> framework, but recent discussions on this list made me think GnuRadio
> may be an option. So, I'm looking for the community help with the the
> following questions:
> 
> 1) How well is GnuRadio suited for packet data processing? WiMAX is
> essentially a packet-oriented system.

What you're writing is receiver-only, right? In that case, GNU Radio
will be able to handle all your data just fine. It gets tricky when you
have a transceiver with timing-sensitive operations, but it seems your
project would work well. GNU Radio is pretty agnostic of the data moved
between blocks.

> 2) We don't want to use Python. Is there anything we can't do without
> it? And where can we find examples of C++-only flowgraphs?

There are some examples in gnuradio-examples/c++. It's really not that
hard, and I've done some C++-only projects with great success.

However, let me ask why you don't want to use Python. Is it because you
want a final product that works without Python, or do you have a real
'allergy'?
Because I recommend that *even* for a C++-only project, you still use
Python for unit tests. Also, this gives you the opportunity to quickly
click together tests using GRC. This will make development a *lot*
easier.
Side note: Porting from Matlab to Python is much simpler than going from
Matlab to C++ (for porting your unit tests).

> 3) Right now all our code is open-source, but we must leave an option
> for proprietary plugins. How can we make this possible?
> 
> 4) Related to (3) - how can we make sure our protocol stack can be
> embedded into a closed-source application/system?

IANAL, TINLA. I'm guessing your best bet would be to separate the
actual DSP code from the GNU Radio bindings and have very lean GNU Radio
blocks (being GPL) which only call your module. Still, I don't know how
or if you may link code across licenses. 
You will have to get legal help here, I would not rely on anything said
on this list.

Good luck with your project!

MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

pgpTK4aU1WZhW.pgp
Description: PGP signature