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

[Marcus D. Leech]

> On Thu, Aug 2, 2012 at 5:44 AM, Alkis Gian<address@hidden>  wrote:
> > Hello all,
> >
> > I would like to know if GNURadio has a built-in ASN.1 PER encoder/decoder
> > module, or we have to implement it.
> >
> > It seems that this  should do the trick, but I would like to know if this is
> > the correct approach. My DSRC protocol is described using ASN.1 messages and
> > this is why I was thinking of compiling them down to C and then use the
> > encoder/decoder for the Tx/Rx directions.
> >
> > -Alkis
> Alkis,
>
> Yes, I think you'll have to implement it yourself. The work on the VRT
> stuff in the eb-oot branch might be useful, but I don't think the
> effort on ASN.1 was actually completed. I could be wrong, but you're
> best bet would be to lift any code from there any apply it as you
> need.
>
> Tom
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<rant>
OK, so I've said this before, and I'll say it again.   What do protocol 
decoders have to do with signal processing?  Which is really what
  Gnu Radio is all about.  The modern tendency to "stuff everything 
possible" into a single, "does everything" "framework" nauseates me.
  It used to be that modularity, and architectural separation were 
considered good things.  Gnu Radio was developed on an OS with
  a long and proud history of discrete modules handling different parts 
of a workflow, using paradigms that were appropriate to that
  particular part of the workflow.

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>

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org