Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
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 martin.br...@kit.edu 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Wed, May 25, 2011 at 22:29, Michael Dickens m...@alum.mit.edu wrote: Hi Alexander - I think Martin Tom covered that GNU Radio is quite capable of being programmed for the basic receiver processing. You might need to play around a bit with your DSP blocks, but otherwise I think GNU Radio's data processing is up to the task. Yes, with an exception that we our receiver is not basic (e.g. see comment about DL-MAP) and we also need transmitter, and integration with MAC level, ugh. On May 23, 2011, at 3:50 PM, Alexander Chemeris wrote: 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 and TINAL. I think, as has been said, you'll really want to consult a lawyer to figure out how to best meet your needs. GNU Radio is licensed solely under the GPLv3, which is written with the intent that -anything directly- using source or binary becomes part of a greater work and hence would also fall under this or an equivalent license (e.g., if used in a sold product). In the case of GNU Radio, that means any C++ code that links with GNU Radio's libraries, or Python script that makes use of GNU Radio's Python / SWIG files / libraries. To the best of my knowledge, because GNU Radio is not dual-licensed, neither can greater works derived from it. Ettus' UHD code is (will be?) an example of a dual license (GPL for the primary source, or some other license allowing you to do closed source for your needs when you pay to license the code from Ettus); Qt tries to do this dual-license as well -- I don't know how well they succeed, but they do try. IMHO, you have 3 primary choices for keeping your code closed source: (0) Do not use GNU Radio; use some other project that has a less restrictive license. Yes, this is an option. (1) Do not distribute a product or service that uses the code: Nobody will care how you license your code so long as you / your company does not sell or distribute your product -- e.g., if you use it just in house for testing and evaluation, then you can license it however you want. However, I doubt that this is what you're looking for: why develop such a product, but not sell or distribute it? That brings us to: Right. (2) Make sure your code does not -directly- rely on GNU Radio's headers, Python scripts, or compiled libraries: Use currently available GNU Radio blocks as much as you can (or, those written and released by others), and then create a pipe or socket connection to your specific code. Because your code does not rely -directly- on GNU Radio's codebase / libraries, it forms an independent work thus you can license it as you choose. That said, this method is certainly a nuisance and, depending what blocks are available versus what you need, it might also be impractical (never impossible :). Let me clarify. We will publish our main source code as open-source (we already do for our Matlab models). But we want (1) to allow other parties to replace some parts of our open-source code with their proprietary blocks and (2) more importantly - allow creation of proprietary solutions to be based on this code. So far, (2) would require you to create a socket/IPC based API and use it to embed into a larger system - though this implies that you add latency in your processing path. Requirement (1) may go the same way, as long as it's only for some blocks, but again - this may add latency. I'm not yet sure how bad is this added latency, but in general, latency is an important characteristic for 4G. Interesting thing is how Linux kernel allows proprietary modules. If I understand this correctly (IANAL), it's because kernel's API is clearly defined and kernel it's considered, that it's a kernel native feature - to be able load and run modules, just like it's for applications. With this logic, it's possible to allow modules with GnuRadio if there are a clearly defined external API. But note, that the kernel is licensed under GPLv2, and GnuRadio is under GPLv3 - I'm not sure whether this trick works for the latter. I don't know of another way to look at this issue -- maybe someone on this list is more enlightened? That said: Unless you feel strongly that your work truly needs to be proprietary, then why not just create a project on the CGRAN or your preferred area (e.g., github) make your work public -- it will benefit many others in the SDR / DSP world (and, likely, beyond). We're more concerned about others to use our work. That's what is missing for many GnuRadio projects - we build software for ourselves. We want to create a software which will be used by many. Good luck, and please do keep the list informed on your project -- it sounds quite interesting! - MLD Thanks! I'll do my best keeping the community informed.
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Wed, May 25, 2011 at 23:21, Jeff Brower jbro...@signalogic.com wrote: Michael- Hi Alexander - I think Martin Tom covered that GNU Radio is quite capable of being programmed for the basic receiver processing. You might need to play around a bit with your DSP blocks, but otherwise I think GNU Radio's data processing is up to the task. On May 23, 2011, at 3:50 PM, Alexander Chemeris wrote: 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 and TINAL. I think, as has been said, you'll really want to consult a lawyer to figure out how to best meet your needs. GNU Radio is licensed solely under the GPLv3, which is written with the intent that -anything directly- using source or binary becomes part of a greater work and hence would also fall under this or an equivalent license (e.g., if used in a sold product). In the case of GNU Radio, that means any C++ code that links with GNU Radio's libraries, or Python script that makes use of GNU Radio's Python / SWIG files / libraries. To the best of my knowledge, because GNU Radio is not dual-licensed, neither can greater works derived from it. Ettus' UHD code is (will be?) an example of a dual license (GPL for the primary source, or some other license allowing you to do closed source for your needs when you pay to license the code from Ettus); Qt tries to do this dual-license as well -- I don't know how well they succeed, but they do try. IMHO, you have 3 primary choices for keeping your code closed source: (0) Do not use GNU Radio; use some other project that has a less restrictive license. (1) Do not distribute a product or service that uses the code: Nobody will care how you license your code so long as you / your company does not sell or distribute your product -- e.g., if you use it just in house for testing and evaluation, then you can license it however you want. However, I doubt that this is what you're looking for: why develop such a product, but not sell or distribute it? That brings us to: (2) Make sure your code does not -directly- rely on GNU Radio's headers, Python scripts, or compiled libraries: Use currently available GNU Radio blocks as much as you can (or, those written and released by others), and then create a pipe or socket connection to your specific code. Because your code does not rely -directly- on GNU Radio's codebase / libraries, it forms an independent work thus you can license it as you choose. That said, this method is certainly a nuisance and, depending what blocks are available versus what you need, it might also be impractical (never impossible :). This is where I think licensing discussions tend to go off track. Legal precedents have clearly established requirements for interoperability. In that context, the key point is not what code links to, but where it resides and what shape it takes. Linking based arguments are fuzzy and argued ad infinitum until at least one such case reaches the Supreme Court -- not likely any time soon. If code resides across a network, across a bus (i.e. on a PCIe card inside the GNU radio host server), or some other clearly non-GNU radio location then interoperability becomes the metric. It doesn't matter what header files or libraries (or whether the libraries are static or shared object, etc) were used to create an interface to the code that is physically separate -- in that case, the code is clearly out of the scope of the license. I've mentioned on the forum before the need for ways to insert proprietary code within the GNU radio framework, as have others. For example, is it possible for GNU radio users to insert code blocks into the FPGA data flow, for instance if FPGA Verilog code contained user defined stubs or simple reference examples to serve as a starting point? Could an Nvidia accelerator be used? To me, it's a matter of imagination, creativity, and persistence -- if GNU radio developers believe in the need for proprietary IP within their framework, then it can be done. So far, evidently, they don't believe. Alexander is asking excellent questions and I'm surprised at the tepid response -- he's got like 4 replies so far? He's the prototype GNU radio user who needs to maintain his group's IP, he should be receiving how to's, not INALs. Jeff, thanks. Yes, I'm trying to solve a bigger problem then just my personal case. And you're right - if we want to see serious projects to use GnuRadio, then there must be how-to's and examples. -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Thu, May 26, 2011 at 18:10, Marcus D. Leech mle...@ripnet.com wrote: On 26/05/2011 9:55 AM, Michael Dickens wrote: It would be great if you could share with the list example code snippets of how you do the pipes. For example: Where in an online repository one can find such code. I think that's what Jeff was getting at: that we are providing IANAL advice rather than code examples. I, for one, have never actually tried the pipes -- I've just heard that they are possible and that using them does not form a greater work in the GPL sense. - MLD ___ Actually, my SIDSuite code uses this a little bit, in that data recording is handled outside of Gnu Radio. The basic idea is that there's a shell script that sets up the environment (creates the FIFO files, starts the external programs in the background, etc), then the Gnu Radio flow-graph is called. The flow-graphs just use File Source and File Sink with buffering turned off--as far as Gnu Radio is concerned, it's writing to a file, but in fact, it's a FIFO file or named pipe. See: http://www.sbrac.org/files/sidsuite.tar.gz It doesn't do it as much as other code that I've written, but it gives one a flavour for how the pipes are used. Cool! It would be truly great to see a simplified example of this in the GnuRadio repository, and at least somehow mentioned on the wiki. The other trick that I use is to use the XMLRPC server stuff that Josh put in GRC--it allows you to set flowgraph variables from an outside program, which is really great! Hum. Any examples? I also wonder - have you quantified overhead of those methods - in latency, jitter, memory, etc? -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Anti-tivoization is one of main differences (but not the only), but it's about a different issue. http://en.wikipedia.org/wiki/Tivoization On Sat, May 28, 2011 at 05:14, Colby Boyer colby.bo...@gmail.com wrote: Isn't the main difference between v2 and v3 the Tivo Exception as the call it? Not sure. I guess I should add IANAL. TINLA. :P On Fri, May 27, 2011 at 3:32 PM, Marcus D. Leech mle...@ripnet.com wrote: How do the companies write closed-source drivers for the Linux Kernel without running into GPL2 issues? I can only recall that there is a user-land and a kernel-land driver, where the kernel-land is the only part that is open source. Is this correct? Perhaps that method could work well? I thought GPLV2 was less onerous in this regard, and that case-law had established that a loadable kernel driver didn't necessarily get infected by the GPL virus. IANAL. TINLA. Etc. The last kernel driver I worked on we were planning to open-source as a way of encouraging people to buy our (very closed-source!) chips. Project fell apart before we hit market. Sigh. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Cool! It would be truly great to see a simplified example of this in the GnuRadio repository, and at least somehow mentioned on the wiki. Yes, I suppose it would. I'll put it on my list, but so many other things to do :-( The other trick that I use is to use the XMLRPC server stuff that Josh put in GRC--it allows you to set flowgraph variables from an outside program, which is really great! Hum. Any examples? I also wonder - have you quantified overhead of those methods - in latency, jitter, memory, etc? Well, in terms of the FIFO I/O, they're pretty-darned efficient in Linux, at least as efficient as disk I/O, although since FIFOs (named pipes) are implemented in kernel memory, they're typically a lot faster. I've never needed the XMLRPC stuff to go real fast, since I typically use it to modify flow-graph parameters that change infrequently. One of the things I use it for in one of my applications that I did for a customer is for active RFI excision for a science application. The flow-graph produces a spectral estimate which is sent over a FIFO to an external program that analyses the spectrum, and then, if necessary, sends back parameters for a multi-notch filter into the flow-graph. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Hi community, On Mon, May 23, 2011 at 23:50, Alexander Chemeris alexander.cheme...@gmail.com wrote: Hi community, 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. 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. 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? 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? I want to add some more questions: 5) How well is GnuRadio suited for real-time operation? 5.1) Specifically - is memory allocated from heap with malloc() or it supports non-blocking memory pools? 5.2) Can the whole flowgraph be executed from a single thread to minimize cross-thread communication overhead (and jitter)? -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Sat, May 28, 2011 at 18:23, Marcus D. Leech mle...@ripnet.com wrote: Cool! It would be truly great to see a simplified example of this in the GnuRadio repository, and at least somehow mentioned on the wiki. Yes, I suppose it would. I'll put it on my list, but so many other things to do :-( The other trick that I use is to use the XMLRPC server stuff that Josh put in GRC--it allows you to set flowgraph variables from an outside program, which is really great! Hum. Any examples? I also wonder - have you quantified overhead of those methods - in latency, jitter, memory, etc? Well, in terms of the FIFO I/O, they're pretty-darned efficient in Linux, at least as efficient as disk I/O, although since FIFOs (named pipes) are implemented in kernel memory, they're typically a lot faster. Problem here is that FIFO's are not very well suited for real-time operation, IIRC. Have you tried a shared memory and shared signals across applications? I've never needed the XMLRPC stuff to go real fast, since I typically use it to modify flow-graph parameters that change infrequently. One of the things I use it for in one of my applications that I did for a customer is for active RFI excision for a science application. The flow-graph produces a spectral estimate which is sent over a FIFO to an external program that analyses the spectrum, and then, if necessary, sends back parameters for a multi-notch filter into the flow-graph. Good idea. With only one problem - XML is a bit of overhead for real-time application messaging :) I wonder - have anyone considered using Google's Protocol Buffers or a similar messaging scheme with fast serialization/deserialization? http://code.google.com/apis/protocolbuffers/docs/overview.html -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On May 28, 2011, at 11:26 AM, Alexander Chemeris wrote: 5) How well is GnuRadio suited for real-time operation? In a general sense, yes, GNU Radio is well suited for real-time signal processing of data streams. That said: Real time is only meaningful knowing the performance criteria. What sort of performance do you require processing for? 5.1) Specifically - is memory allocated from heap with malloc() or it supports non-blocking memory pools? IIRC (Tom? Eric?): GNU Radio uses the standard C++ new command for most memory allocations -- and thus it is memory from the heap. One can always overload this method globally or locally if required, to provide memory from pools or other means. 5.2) Can the whole flowgraph be executed from a single thread to minimize cross-thread communication overhead (and jitter)? Yes. Your choices are a single thread for all or 1 thread per block. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Sat, May 28, 2011 at 19:38, Michael Dickens m...@alum.mit.edu wrote: On May 28, 2011, at 11:26 AM, Alexander Chemeris wrote: 5) How well is GnuRadio suited for real-time operation? In a general sense, yes, GNU Radio is well suited for real-time signal processing of data streams. That said: Real time is only meaningful knowing the performance criteria. What sort of performance do you require processing for? Real-time is not about performance, but about predictability ;) I have to be sure that my flowgraph always executes before the deadline is hit. So everything that introduces jitter is a no-no. 5.1) Specifically - is memory allocated from heap with malloc() or it supports non-blocking memory pools? IIRC (Tom? Eric?): GNU Radio uses the standard C++ new command for most memory allocations -- and thus it is memory from the heap. One can always overload this method globally or locally if required, to provide memory from pools or other means. Is this new called during the flowgraph execution loop? It's too bad, if it is. Standard memory allocation schemes introduce random delays in a thread execution. And implementation of a lock-free memory allocator is a complex task. We used memory pools instead, but this requires special care - you can't replace a new with memory pool get() with a regexp. 5.2) Can the whole flowgraph be executed from a single thread to minimize cross-thread communication overhead (and jitter)? Yes. Your choices are a single thread for all or 1 thread per block. - MLD Great. -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Problem here is that FIFO's are not very well suited for real-time operation, IIRC. Have you tried a shared memory and shared signals across applications? It depends on what you mean by real time. Certainly FIFO I/O will be slower than intra-flowgraph ring buffers, but not so horribly sluggish and latency prone that they can't be used for a large class of real-time applications. I use them extensively in a radio astronomy application, and they don't seem to add any noticable latency above the already-not-spectacular latency within Gnu Radio. Good idea. With only one problem - XML is a bit of overhead for real-time application messaging :) Are you concerned about parsing overhead? And what do you mean by real time?? Are you concerned about reacting to stimuli on microsecond timescales? In which case, deep thought would certainly be required about the entire architecture, and not just the protocol syntax. I wonder - have anyone considered using Google's Protocol Buffers or a similar messaging scheme with fast serialization/deserialization? http://code.google.com/apis/protocolbuffers/docs/overview.html Don't know anything about it. Might be worth looking at for *someone*. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Real-time is not about performance, but about predictability ;) I have to be sure that my flowgraph always executes before the deadline is hit. So everything that introduces jitter is a no-no. In general, Gnu Radio executes on general-purpose OSes, which means that there will *always* be microsecond-to-milllisecond scale jitter in executing code. If you want 100s-of-nanosecond to microsecond scale execution timing predicability, Gnu Radio is going to be the least of your worries, in my experience. The kernel can prempt you at any time to deal with interrupts, etc. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Sat, May 28, 2011 at 19:52, Marcus D. Leech mle...@ripnet.com wrote: Problem here is that FIFO's are not very well suited for real-time operation, IIRC. Have you tried a shared memory and shared signals across applications? It depends on what you mean by real time. Certainly FIFO I/O will be slower than intra-flowgraph ring buffers, but not so horribly sluggish and latency prone that they can't be used for a large class of real-time applications. I mean Soft Real-Time: http://en.wikipedia.org/wiki/Real-time_computing#Hard.2C_firm.2C_and_soft_real-time So, I actually do care about two parameters: 1) Real-timeness - i.e. whether using of this primitive can introduce unexpected delays into execution. 2) Latency and throughput - if real-timeness requirement is met, then I want to know how well performance of the primitive is. I use them extensively in a radio astronomy application, and they don't seem to add any noticable latency above the already-not-spectacular latency within Gnu Radio. Is there information about what is the biggest latency-injector in GnuRadio? Good idea. With only one problem - XML is a bit of overhead for real-time application messaging :) Are you concerned about parsing overhead? And what do you mean by real time?? Are you concerned about reacting to stimuli on microsecond timescales? In which case, deep thought would certainly be required about the entire architecture, and not just the protocol syntax. That's what I try to do right now - evaluate whether GnuRadio can perform well enough in general :) I probably spent too much time developing VoIP media processing where you can hear every non-realtimness with your ears. But RF processing should be no less real-time, imho. -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Sat, May 28, 2011 at 19:59, Marcus D. Leech mle...@ripnet.com wrote: Real-time is not about performance, but about predictability ;) I have to be sure that my flowgraph always executes before the deadline is hit. So everything that introduces jitter is a no-no. In general, Gnu Radio executes on general-purpose OSes, which means that there will *always* be microsecond-to-milllisecond scale jitter in executing code. If you want 100s-of-nanosecond to microsecond scale execution timing predicability, Gnu Radio is going to be the least of your worries, in my experience. The kernel can prempt you at any time to deal with interrupts, etc. You can do with sub-ms jitter on a decent Linux kernel. We performed a tons of experiments with our VoIP media processing code (sipXmediaLib) to make sure our processing is real-time. -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Is there information about what is the biggest latency-injector in GnuRadio? Nearly all of the basic computational blocks are as blazing-fast as they can be on a general-purpose CPU. The biggest latency injector is the scheduler in general, and the buffer management part of that scheduler in particular. The Gnu Radio architecture is optimized for throughput, not latency, which means *BIG* ring-buffers between blocks, and a complicated mechanism for calculating the shape of those ring buffers. Scheduling across multiple threads is *great* for throughput, to be sure, but it complicates optimization in other directions. This is not an easy problem to solve. the protocol syntax. That's what I try to do right now - evaluate whether GnuRadio can perform well enough in general :) I probably spent too much time developing VoIP media processing where you can hear every non-realtimness with your ears. But RF processing should be no less real-time, imho. It depends very much on the type of RF processing you're doing. Gnu Radio is used for a *large* number of different applications--some of those applications are a more-awkward fit, and some fit really well. RF signal processing doesn't have a single set of universal constraints that everyone can agree on are vital. Even among different types of telecom applications, there isn't general agreement--some have quite-sloppy requirements for latency, while others have very tight requirements for latency. For my use of Gnu Radio, I care very much about overall throughput-type performance, and reliability of the data. I dont' have a stimulus response type of model that needs to respond on timescales of a few sample times. But others have much-tighter requirements. I don't need to know in real-time, for example, that the ionosphere has changed reflectivity by 1%--I'm perfectly happy to find out about that up to several seconds after it's happened :-) In my science application that does active RFI-excision, it needs to respond on very lazy timescales, since one spends perhaps several days building up an RFI map (and the corresponding notch filter coefficients) before commencing real science. But there have certainly been plenty of other folks on this list trying to get a good feel for the shape of the real-timeness of Gnu Radio, and whether it would be suitable out of the box for their application. All I can suggest is to try some experiments on various host hardware, with the latest code, and see where it takes you. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
I thought the 1 thread execution scheduler was deprecated in gnuradio? al fayez -Original Message- From: Michael Dickens m...@alum.mit.edu To: Alexander Chemeris alexander.cheme...@gmail.com Cc: Gnuradio-discuss discuss-gnuradio@gnu.org Sent: Sat, May 28, 2011 11:38 am Subject: Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not? On May 28, 2011, at 11:26 AM, Alexander Chemeris wrote: 5) How well is GnuRadio suited for real-time operation? In a general sense, yes, GNU Radio is well suited for real-time signal processing of data streams. That said: Real time is only meaningful knowing the performance criteria. What sort of performance do you require processing for? 5.1) Specifically - is memory allocated from heap with malloc() or it supports non-blocking memory pools? IIRC (Tom? Eric?): GNU Radio uses the standard C++ new command for most memory allocations -- and thus it is memory from the heap. One can always overload this method globally or locally if required, to provide memory from pools or other means. 5.2) Can the whole flowgraph be executed from a single thread to minimize cross-thread communication overhead (and jitter)? Yes. Your choices are a single thread for all or 1 thread per block. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
I thought the 1 thread execution scheduler was deprecated in gnuradio? al fayez You may still turn it off, but the TPB scheduling policy is now the default. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Marcus- Alexander is asking excellent questions and I'm surprised at the tepid response -- he's got like 4 replies so far? He's the prototype GNU radio user who needs to maintain his group's IP, he should be receiving how to's, not INALs. -Jeff Actually, IANAL is a perfectly-valid response. IP licensing arrangements are complicated and studded with sinkholes and minefields. I've avoided the issue (I hope!) in my proprietary stuff that uses Gnu Radio by doing two things: o minimizing the stuff that I do inside the flow-graph if I can conveniently do it outside o speaking to the flowgraph via named pipes and moving the proprietary and user-goop into non Gnu Radio compiled code. This is probably the safest thing that somebody who isn't a lawyer can do without consulting an (expensive) IPR lawyer. I agree this is a good approach with clear intent. Especially if you can show things would work the same way if the pipes connected over Ethernet to another server that did not have GNU radio installed. Maybe if GRC had some blocks for this purpose... -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Fri, May 27, 2011 at 2:31 PM, Jeff Brower jbro...@signalogic.com wrote: Marcus- Alexander is asking excellent questions and I'm surprised at the tepid response -- he's got like 4 replies so far? He's the prototype GNU radio user who needs to maintain his group's IP, he should be receiving how to's, not INALs. -Jeff Actually, IANAL is a perfectly-valid response. IP licensing arrangements are complicated and studded with sinkholes and minefields. I've avoided the issue (I hope!) in my proprietary stuff that uses Gnu Radio by doing two things: o minimizing the stuff that I do inside the flow-graph if I can conveniently do it outside o speaking to the flowgraph via named pipes and moving the proprietary and user-goop into non Gnu Radio compiled code. This is probably the safest thing that somebody who isn't a lawyer can do without consulting an (expensive) IPR lawyer. I agree this is a good approach with clear intent. Especially if you can show things would work the same way if the pipes connected over Ethernet to another server that did not have GNU radio installed. Maybe if GRC had some blocks for this purpose... -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio How do the companies write closed-source drivers for the Linux Kernel without running into GPL2 issues? I can only recall that there is a user-land and a kernel-land driver, where the kernel-land is the only part that is open source. Is this correct? Perhaps that method could work well? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
How do the companies write closed-source drivers for the Linux Kernel without running into GPL2 issues? I can only recall that there is a user-land and a kernel-land driver, where the kernel-land is the only part that is open source. Is this correct? Perhaps that method could work well? I thought GPLV2 was less onerous in this regard, and that case-law had established that a loadable kernel driver didn't necessarily get infected by the GPL virus. IANAL. TINLA. Etc. The last kernel driver I worked on we were planning to open-source as a way of encouraging people to buy our (very closed-source!) chips. Project fell apart before we hit market. Sigh. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Isn't the main difference between v2 and v3 the Tivo Exception as the call it? Not sure. I guess I should add IANAL. TINLA. :P On Fri, May 27, 2011 at 3:32 PM, Marcus D. Leech mle...@ripnet.com wrote: How do the companies write closed-source drivers for the Linux Kernel without running into GPL2 issues? I can only recall that there is a user-land and a kernel-land driver, where the kernel-land is the only part that is open source. Is this correct? Perhaps that method could work well? I thought GPLV2 was less onerous in this regard, and that case-law had established that a loadable kernel driver didn't necessarily get infected by the GPL virus. IANAL. TINLA. Etc. The last kernel driver I worked on we were planning to open-source as a way of encouraging people to buy our (very closed-source!) chips. Project fell apart before we hit market. Sigh. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Colby- How do the companies write closed-source drivers for the Linux Kernel without running into GPL2 issues? I can only recall that there is a user-land and a kernel-land driver, where the kernel-land is the only part that is open source. Is this correct? Perhaps that method could work well? You can find many opinions either way. But as you mention, the reality on the ground is that commercial outfits often distribute binary-only versions of libraries and drivers, whether the license they're under actually permits that or not. Their argument that providing driver source would disclose proprietary information about their hardware is difficult to refute. Nvidia is one example. I continue to think future legal rulings will invoke interoperability to clarify this. Numerous people want to interoperate with Linux and still maintain their sauce as secret. Building cards that insert into servers is one obvious example. A smaller group of people want to interoperate similarly with GNU radio. Yes there are no lawyers posting here, but my point is these users should be supported in some formal, encouraged way. -Jeff I thought GPLV2 was less onerous in this regard, and that case-law had established that a loadable kernel driver didn't necessarily get infected by the GPL virus. IANAL. TINLA. Etc. The last kernel driver I worked on we were planning to open-source as a way of encouraging people to buy our (very closed-source!) chips. Project fell apart before we hit market. Sigh. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On 26/05/2011 9:55 AM, Michael Dickens wrote: It would be great if you could share with the list example code snippets of how you do the pipes. For example: Where in an online repository one can find such code. I think that's what Jeff was getting at: that we are providing IANAL advice rather than code examples. I, for one, have never actually tried the pipes -- I've just heard that they are possible and that using them does not form a greater work in the GPL sense. - MLD ___ Actually, my SIDSuite code uses this a little bit, in that data recording is handled outside of Gnu Radio. The basic idea is that there's a shell script that sets up the environment (creates the FIFO files, starts the external programs in the background, etc), then the Gnu Radio flow-graph is called. The flow-graphs just use File Source and File Sink with buffering turned off--as far as Gnu Radio is concerned, it's writing to a file, but in fact, it's a FIFO file or named pipe. See: http://www.sbrac.org/files/sidsuite.tar.gz It doesn't do it as much as other code that I've written, but it gives one a flavour for how the pipes are used. The other trick that I use is to use the XMLRPC server stuff that Josh put in GRC--it allows you to set flowgraph variables from an outside program, which is really great! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Hi Alexander - I think Martin Tom covered that GNU Radio is quite capable of being programmed for the basic receiver processing. You might need to play around a bit with your DSP blocks, but otherwise I think GNU Radio's data processing is up to the task. On May 23, 2011, at 3:50 PM, Alexander Chemeris wrote: 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 and TINAL. I think, as has been said, you'll really want to consult a lawyer to figure out how to best meet your needs. GNU Radio is licensed solely under the GPLv3, which is written with the intent that -anything directly- using source or binary becomes part of a greater work and hence would also fall under this or an equivalent license (e.g., if used in a sold product). In the case of GNU Radio, that means any C++ code that links with GNU Radio's libraries, or Python script that makes use of GNU Radio's Python / SWIG files / libraries. To the best of my knowledge, because GNU Radio is not dual-licensed, neither can greater works derived from it. Ettus' UHD code is (will be?) an example of a dual license (GPL for the primary source, or some other license allowing you to do closed source for your needs when you pay to license the code from Ettus); Qt tries to do this dual-license as well -- I don't know how well they succeed, but they do try. IMHO, you have 3 primary choices for keeping your code closed source: (0) Do not use GNU Radio; use some other project that has a less restrictive license. (1) Do not distribute a product or service that uses the code: Nobody will care how you license your code so long as you / your company does not sell or distribute your product -- e.g., if you use it just in house for testing and evaluation, then you can license it however you want. However, I doubt that this is what you're looking for: why develop such a product, but not sell or distribute it? That brings us to: (2) Make sure your code does not -directly- rely on GNU Radio's headers, Python scripts, or compiled libraries: Use currently available GNU Radio blocks as much as you can (or, those written and released by others), and then create a pipe or socket connection to your specific code. Because your code does not rely -directly- on GNU Radio's codebase / libraries, it forms an independent work thus you can license it as you choose. That said, this method is certainly a nuisance and, depending what blocks are available versus what you need, it might also be impractical (never impossible :). I don't know of another way to look at this issue -- maybe someone on this list is more enlightened? That said: Unless you feel strongly that your work truly needs to be proprietary, then why not just create a project on the CGRAN or your preferred area (e.g., github) make your work public -- it will benefit many others in the SDR / DSP world (and, likely, beyond). Good luck, and please do keep the list informed on your project -- it sounds quite interesting! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Michael- Hi Alexander - I think Martin Tom covered that GNU Radio is quite capable of being programmed for the basic receiver processing. You might need to play around a bit with your DSP blocks, but otherwise I think GNU Radio's data processing is up to the task. On May 23, 2011, at 3:50 PM, Alexander Chemeris wrote: 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 and TINAL. I think, as has been said, you'll really want to consult a lawyer to figure out how to best meet your needs. GNU Radio is licensed solely under the GPLv3, which is written with the intent that -anything directly- using source or binary becomes part of a greater work and hence would also fall under this or an equivalent license (e.g., if used in a sold product). In the case of GNU Radio, that means any C++ code that links with GNU Radio's libraries, or Python script that makes use of GNU Radio's Python / SWIG files / libraries. To the best of my knowledge, because GNU Radio is not dual-licensed, neither can greater works derived from it. Ettus' UHD code is (will be?) an example of a dual license (GPL for the primary source, or some other license allowing you to do closed source for your needs when you pay to license the code from Ettus); Qt tries to do this dual-license as well -- I don't know how well they succeed, but they do try. IMHO, you have 3 primary choices for keeping your code closed source: (0) Do not use GNU Radio; use some other project that has a less restrictive license. (1) Do not distribute a product or service that uses the code: Nobody will care how you license your code so long as you / your company does not sell or distribute your product -- e.g., if you use it just in house for testing and evaluation, then you can license it however you want. However, I doubt that this is what you're looking for: why develop such a product, but not sell or distribute it? That brings us to: (2) Make sure your code does not -directly- rely on GNU Radio's headers, Python scripts, or compiled libraries: Use currently available GNU Radio blocks as much as you can (or, those written and released by others), and then create a pipe or socket connection to your specific code. Because your code does not rely -directly- on GNU Radio's codebase / libraries, it forms an independent work thus you can license it as you choose. That said, this method is certainly a nuisance and, depending what blocks are available versus what you need, it might also be impractical (never impossible :). This is where I think licensing discussions tend to go off track. Legal precedents have clearly established requirements for interoperability. In that context, the key point is not what code links to, but where it resides and what shape it takes. Linking based arguments are fuzzy and argued ad infinitum until at least one such case reaches the Supreme Court -- not likely any time soon. If code resides across a network, across a bus (i.e. on a PCIe card inside the GNU radio host server), or some other clearly non-GNU radio location then interoperability becomes the metric. It doesn't matter what header files or libraries (or whether the libraries are static or shared object, etc) were used to create an interface to the code that is physically separate -- in that case, the code is clearly out of the scope of the license. I've mentioned on the forum before the need for ways to insert proprietary code within the GNU radio framework, as have others. For example, is it possible for GNU radio users to insert code blocks into the FPGA data flow, for instance if FPGA Verilog code contained user defined stubs or simple reference examples to serve as a starting point? Could an Nvidia accelerator be used? To me, it's a matter of imagination, creativity, and persistence -- if GNU radio developers believe in the need for proprietary IP within their framework, then it can be done. So far, evidently, they don't believe. Alexander is asking excellent questions and I'm surprised at the tepid response -- he's got like 4 replies so far? He's the prototype GNU radio user who needs to maintain his group's IP, he should be receiving how to's, not INALs. -Jeff I don't know of another way to look at this issue -- maybe someone on this list is more enlightened? That said: Unless you feel strongly that your work truly needs to be proprietary, then why not just create a project on the CGRAN or your preferred area (e.g., github) make your work public -- it will benefit many others in the SDR / DSP world (and, likely, beyond). Good luck, and please do keep the list informed on your project -- it sounds quite interesting! - MLD
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Alexander is asking excellent questions and I'm surprised at the tepid response -- he's got like 4 replies so far? He's the prototype GNU radio user who needs to maintain his group's IP, he should be receiving how to's, not INALs. -Jeff Actually, IANAL is a perfectly-valid response. IP licensing arrangements are complicated and studded with sinkholes and minefields. I've avoided the issue (I hope!) in my proprietary stuff that uses Gnu Radio by doing two things: o minimizing the stuff that I do inside the flow-graph if I can conveniently do it outside o speaking to the flowgraph via named pipes and moving the proprietary and user-goop into non Gnu Radio compiled code. This is probably the safest thing that somebody who isn't a lawyer can do without consulting an (expensive) IPR lawyer. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
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
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Tue, May 24, 2011 at 7:04 AM, Martin Braun martin.br...@kit.edu 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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Hi community, 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. 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. 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? 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? PS I have heavy travel schedule these days and a lot of other duties, so please excuse me is I respond slow. -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
