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