discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
Date: Wed, 15 Feb 2012 20:07:54 -0500

On Wed, Feb 15, 2012 at 11:52 AM, George Nychis <address@hidden> wrote:
A bit late on this conversation... I just noticed it after I posted an update for CGRAN.

GNU Radio has been largely successful in the academic community, because it provides us the flexibility to perform the style of research we need.  Ultimately though, the limitations of the framework that were put in place to achieve this flexibility, I believe hurt the ability of GNU Radio to support more high-end applications.  I'm not talking about the lack of someone coming around to do it, I'm talking about the lack of GNU Radio and USRP to support many of the current wireless standards today.  This is going to be slightly biased in my area of research... but, what would be a great app?  Show interoperability of GNU Radio and 802.11, ZigBee, DECT, RFID (thanks Michael), NFC, Bluetooth, etc.

To me, pushing GNU Radio to the next level has never been about building the next set of applications on what is currently supported, but really pushing the platform to the next level.  Being able to support low latency applications, support wide ranges of MAC protocols, different PHYs.  This opens up the ability to build so much more and new on GNU Radio.  

I can't express how many times I've gotten personal e-mails about my MAC work and about projects on GNU Radio of people wanting to do some pretty cool things and I'm just like... "well, the architecture just doesn't support that."  For example, meta-data between blocks IMO was something brain-dead that should have been in GNU Radio 7 years ago which would have really enabled new things to be done with the framework.  Instead, it took 7 years for stream tags ;)  This is functionality that pushes the frame and the architecture, that is the kind of stuff that I think will push the platform.

So to me, it's not about having the next demodulation block, it's about what is going to happen to the architecture and the framework to support an 802.11, a ZigBee, DECT, RFID, NFC, Bluetooth, Xbox controller... things that people want to play with and showcase the capabilities of the radio.  

I think what "we" should be doing is taking what is "hot" in the radio world, and asking whether or not it can be supported by GNU Radio and the USRP.  I really think that GNU Radio needs to get passed its major application being simple streaming or demodulation and really push packet radio.  Two way low latency communication.  Networks, I suppose.  

To me, I go "well, in 6 years GNU Radio really hasn't changed" ... has it?  Yeah, block details, new blocks, the amount of bandwidth from the USRP, but like, what has fundamentally pushed the limitations of the system?  

Just my 10 cents!  I am unbelievably grateful for GNU Radio and the USRP.  They truly transformed my view of the RF world, the radio, and have given me invaluable experience that I would have never gotten on any other platform.  The community itself is great, and I've been happy to be a part of it (in and out) for the past 6 years.  That's the reassuring part that I'm on your side, these are just my thoughts on where I wish GNU Radio & USRP would go :)


Those are fair points, George, but just keep an eye on what's been happening lately. Yep, we've introduced stream tags, I just included more control over latency between GR blocks, and we're about to merge in support for Volk to drastically increase the compute power of the system. And take a look at the presentations from the last GNU Radio conference, specifically the event scheduler. All of this is pushing in the direction of supporting packet communications.

Also, keep in mind that without input from users, developers, and would-be users, we develop either in the black-box of our own wants and desires. We respond to those who comes to us with ideas for what's really needed.

Tom


 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]