Re: [Discuss-gnuradio] GNURadio PER encoder/decoder

[Douglas Geiger]

To add my $0.02:
 I generally agree with Martin on this one. I think the generic
question, i.e. should GNURadio entertain things outside traditional
'signal-processing/RF comms/digital comms/etc.' is: absolutely. If
someone wants to use the GNURadio flowgraph structure to build a
better mousetrap, go for it. If they feel that the structure breaks
down at some point and need to pass it off via source/sink to some
external process, then they should be free to go that way as well. The
bigger issue, which I think Marcus was aiming at, is what blocks
belong in the mainline distribution of GNURadio. With the
restructuring (gr-digital/etc.) perhaps there could be some structure
that allowed higher layer processing blocks (which may/may not include
ASN.1-style parsing), but perhaps that sort of thing should be
encouraged to exist out-of-tree. But my main point is that I don't
think we should limit ourselves to merely being a radio-signal
processing engine (or even a generic signal-processing engine: since
obviously people are doing signal processing that is not radio-related
with the framework). So - my suggestion would be to throw those things
over to CGRAN (or Github, if that's your preference), but still to do
everything we can to encourage that sort of thing. After all, the
important thing here is that although the signal processing flowgraph
may be the most interesting piece (at least to most of us here), it is
the complete application that people want: not just a piece of a
complete solution.

 Doug

On Mon, Aug 13, 2012 at 3:44 AM, Martin Braun (CEL)
<address@hidden> wrote:
> On Sun, Aug 12, 2012 at 01:28:03PM -0400, Marcus D. Leech wrote:
>> <rant>
>> [...]
>> Where do we draw the line as to what consitutes a "reasonable" thing
>> to be done inside the Gnu Radio framework, and something that
>>   is best done elsewhere?  Modern operating systems, like Linux have
>> a rich palette of IPC mechanisms that are specifically designed to
>>   facilitate functional decomposition, and yet I continue to see
>> people wanting to stuff everything into the Gnu Radio framework.
>> Gnu Radio
>>   is developing an increasingly-well-deserved reputation as
>> "bloatware", precisely because we tend to entertain the notion that
>> "if it starts
>>   or ends as a radio(-like) signal, then we're your one-stop-shop".
>> </rant>
>
> Yay, a rant leading to a discussion! What a fabulous way to return back
> to work.
>
> GNU Radio, as we all know, is really not that specific to baseband
> processing. Its main assets are the block structure (which makes it
> modular) and the scheduler, as well as the richness of core blocks
> (including gr-digital, gr-filter etc.).
>
> Adding blocks (in particular, to your own module) therefore does not
> make it bloated: the core stays lean and mean, and the fringes become
> more diverse.
>
> So, I'm all for it (by 'it' I mean writing whatever you want in GNU
> Radio). At some point, a developer will realize that the
> block-and-stream structure really won't help, and that's when you
> connect something else via IPC. But a packet encoder might suit the GNU
> Radio structure just fine.
>
> 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
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Doug Geiger
address@hidden