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
pgpGqd3gIeZ4h.pgp
Description: PGP signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio