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

[Alexander Chemeris]

On Tue, May 24, 2011 at 13:55, Tom Rondeau <address@hidden> wrote:
> On Tue, May 24, 2011 at 7:04 AM, 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.
>> 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.
>
> I know I might be slightly biased here, but, yes, I think you'd be fine
> handling the receiver code in GNU Radio.

What about transmitter side?
We should be sure that we can implement full 4G modem in GnuRadio.

> You are going to have to work a bit
> on the receiver side packet handling, though, because I know WiMax has the
> concept of the downlink map that you have to properly separate. I'd look
> into the stream tagging infrastructure that we have now to handling passing
> around the necessary information.

Yes! DL-MAP is one of the nicest features of WiMAX, bu it makes packet
decoding highly non-linear process. I.e. you should decode header,
find out about encoding parameters of different zones and then decode
zone-by-zone. So we need a tight integration with MAC layer here,
which should command what to decode.

IIRC LTE has similar concept, so it's a must for 4G systems.

BTW, Wireless Innovation Forum is about to kick off a project about
open-source implementation of LTE-Advanced. We're discussing right now
whether we should join forces and create a reconfigurable WiMAX/LTE
implementation. It's a project with wonderful complexity and it needs
a good platform to stay on.

>> > 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).
>
> What Martin said. C++ is definitely doable, but you might want to start in
> Python, anyway. I've done a handful of C++-based flowgraphs, and it's
> relatively trivial to take a flowgraph in Python and convert it to C++, as
> long as you recognize anything that you did that is Pythonic in nature.

When I write in C++ I prefer to be C++-ish ;)
(if I understood you comment correctly)

Tom, it would be great to hear your opinion about licensing issues.
You're the leader of the community and your word is important here.
And if I understand correctly, you're also a liaison to FSF?

-- 
Regards,
Alexander Chemeris.