Packet Encoder-Decoder

GNU Radio
1

Hi,
In the followning basic setup:
File Source (Byte) ----> Packet Encoder (Byte) -----> File Sink (byte)

My input file is just a “Hello World” message
If the Repeat property of my file source is set to “No” the File Sink
remains empty Why? Do I have buffering issues?
If I set Repeat=“yes” file sink seems to work, But when I insert a
Packet
Decoder:

File Source ----> Packet Encoder ----->Packet Decoder -----> File Sink

The output file is empty again!

Thanks

2

I am seeing the same problem here while running some tests.
Anyone else has any thoughts?

Running gnuradio 3.7.5, installed with the build-gnuradio script on
Ubuntu
14.04.

Gnuradio

On Tue, Oct 7, 2014 at 6:18 AM, Thanasis B.
[email protected]

3

Hi Thanasis,

  1. The flow you showed could not have worked because Packet Decoder
    takes unpacked bytes. The graph should be:

File Source -> Encoder -> Packed-to-Unpacked -> Decoder -> File Sink

  1. The payload length defaults to 512 if you leave it at 0, so a short
    file won’t fill a packet.

Encoder:
1 Sample/Symbol, 1 Bit/Symbol, Payload length 1

Packed-to-Unpacked:
1 Bit/Chunk, MSB

That worked for me.

General question for others … the encoder/decoder are part of GRC and
haven’t had any substantial work in a long time. Is this code meant to
be used, or should people look at other blocks, or gr-mac?

  • Jeff
4

On Wed, Oct 8, 2014 at 7:25 PM, Jeff L. [email protected] wrote:

Encoder:

  • Jeff

Yes, the encoder/decoder pair are quite old and meant as examples as
much
as anything; definitely not the definitive way to do this.

gr-mac is a good place to look for alternatives. I really hope to see us
fix up some of the gr-mac code and merge as much as possible back into
GNU
Radio. And when I say fix up, I mean that they way they’ve done stuff
inside there was based off the legacy code they pulled it from, so
there’s
some mix of stream, stream tags, and pdu stuff in there that could be
smoothed out. But they were solving the general problem of getting the
mac
to work. I’d love to see things cleaned up a bit now.

Tom

5

Jeff, Tom,

The packet framer/deframer is mostly identical to the stream-based one
in
GNU Radio proper. It’s not a bad starting point, but a more general
implementation that could be configured for a variety of applications,
codes, and frame formats would be very interesting. I think this would
be
a substantial project that could probably stand on its own. GSoC?

As far as gr-mac is concerned, I’m happy to put in some time and accept
contributions on the project so we can get it merged. Is this
task-force
worthy? Something we should just discuss on another mailing list
thread?
Or is there a better way to proceed?

-John

6

Thank you Jeff!
Indeed, it works!
I really appreciate your help.

Thanasis

2014-10-09 18:21 GMT+03:00 John M. [email protected]:

7

On Thu, Oct 9, 2014 at 11:21 AM, John M.
<[email protected]

wrote:

worthy? Something we should just discuss on another mailing list thread?
Or is there a better way to proceed?

-John

There are two things that I see going on here. First is going through
the
set of blocks that make gr-mac work, see which ones overlap and can be
brought easily into GNU Radio. Along with this, we can follow the full
data
path to make sure we’re using the different data domains properly. IIRC,
there’s at least one part where it uses the old-style message queues
(because of legacy blocks being used here). Finding and correcting this
should be pretty straight-forward.

The second thing is to identify the changes we want to make to the block
functionality like you’re talking about. Added configurations,
capabilities, etc. That’s probably better served after we go through the
first stage.

This really feels like something we could accomplish during a hackfest
with
three or four of us.

Tom