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

[Alexander Chemeris]

Hi Martin, hi all,

I'm sorry for delayed replies. That's not because I don't care - I
just have very tight schedule at this moment.

On Tue, May 24, 2011 at 10:04, Martin Braun <address@hidden> wrote:
> 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.

I believe so too. But first, big cool projects should make sure
GnuRadio fits :)

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

WiMAX receiver is our current goal, but we aim ultimately at creating
a full 4G modem. And want to create real working modem, not just an
offline model. We plan to port our code to some powerful DSP later to
make it run in real-time. That's why we want to stay with C/C++ -
Python is not a common guest at DSP.

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

Thanks. I'll look into them.

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

See explanation above about our intention to port to DSP.
Also I believe that it's better to avoid such mixes, because it forces
people to learn language which they don't know.

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

Yes, using Python for unit tests may be a good idea. But it has a
downside - it means that people still have to learn Python.

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

That's the question - how to link across licenses.

> You will have to get legal help here, I would not rely on anything said
> on this list.

In many cases opinion of the community leader plays no smaller role
then license itself. If Linus didn't state that he think proprietary
modules are allowed, Linux would have a very different role now.

-- 
Regards,
Alexander Chemeris.