GNURadio PER encoder/decoder

GNU Radio
1

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
thishttp://gnuradio.org/cgit/eb-oot.git/tree/vrt-ctrl/common/libasn1c
http://gnuradio.org/cgit/eb-oot.git/tree/vrt-ctrl/common/libasn1cshould
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

2

On Thu, Aug 2, 2012 at 5:44 AM, Alkis G. [email protected] wrote:

-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

3

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

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”.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

4

On Sun, Aug 12, 2012 at 01:28:03PM -0400, Marcus D. Leech wrote:

“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”.

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 B.
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

5

On 02/08/12 10:44, Alkis G. wrote:

thinking of compiling them down to C and then use the encoder/decoder
for the Tx/Rx directions.

Hi Alkis,

There’s asn1c as well, the most up to date I’ve found is at
GitHub - vlm/asn1c: The ASN.1 Compiler. I used it recently to handle PER and XER
encoding/decoding.

My 2 cents.

Chris

-Alkis

This body part will be downloaded on demand.

–
Christian G.,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/

6

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 B. (CEL)
[email protected] wrote:

is developing an increasingly-well-deserved reputation as
modular) and the scheduler, as well as the richness of core blocks
Radio structure just fine.
Kaiserstrae 12

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
Doug G.
[email protected]