On May 9, 2011, at 1:59 PM, Marcus D. Leech wrote: > I think you (tangentially) touched on an interesting point. Many users come > to Gnu Radio expecting it to be "A turnkey application to solve my radio > problems". They don't really get that it's a *development* platform for > *developing* SDR-based radio applications.
Good point; one can go search through this list's archive & find many places where someone writes asking how to do some specific task, e.g., CR or DSA -- as if expecting that GNU Radio already has a solution that they can leverage. Clearly there is a perception out there that GNU Radio -is- a generic solution, and then they don't bother to RTFM to figure out that it's more like Octave & that they have to create their application themselves. Better documentation would help, but it will never solve this issue. > I'd also assert that it will *never* be the case that there will be no > circumstances under which you'll have to augment the functionality that GRC > encompasses. I often use GRC for simple tasks -- it's a LOT faster than writing Python scripts, and it "just works" for these tasks. Admittedly, these are simple -- such as reading a file of audio data, adding in gain, and then both displaying a waterfall FFT and piping the data to audio out. I do agree that for any cutting-edge project what you write is true, but if GNU Radio accumulates blocks over time GRC will eventually fit the needs of that 90+% I keep talking about. Of course, that ~10% will always remain, as they are the cutting edge folks. > the "connect the blocks" paradigm is inherently limited in the classes of > problems that can be economically expressed under that paradigm. True, but it's an enormous class. Maybe I'm too limited, but I cannot think of a communication algorithm that can't be implemented graphically in GRC, somehow (or the equivalent, via some combination of a data-flow graph and text command line such as provided by Python). > you can isolate your own functionality behind existing IPC mechanisms, and > thus avoid > binding any of your code to the Gnu Radio libraries. True, but that's OS-dependent and a nuisance. Why not the dual-license approach -- one as GPL and another that allows for local IP (the LGPL would probably suffice)? Again I don't know if the FSF would allow it, but there are plenty of potential end-users who would benefit from this model. - MLD _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio