GNU Radio Companion - Packet Encoder/Decoder

How to Packetize (encode) transmitted bytes into frames, then decode to extract back the original bytes

Prepared by Dr. Aaron Scher
[email protected]
Oregon Institute of Technology

Back to My collection of GNU radio companion flow graphs
Back to Aaron's home page.

(Last updated: Oct 2015)

Download file: packet_encoder_decoder.grc.

Flow Graph:

Encoder/Decoder

Below is the result of the simulation. The file source is cat_in.png (picture of a cat). The picture was successfully transferred. In this simulation the payload is set to 4 (bytes). This means the encoder takes in four bytes at a time, and these bytes get wrapped into a packet with a header, access code, and preamble, and the packet is sent on to the next block. I found that if I set the payload length to something less than 4, the entire picture does not transfer (I only get a partical cat at the output!). I'm exactly not sure why this is. If I set the payload length to something greater than 4, the transfer still works (and it goes faster).

FM Radio

Here is the result of a second simulation. The source file is a regular .txt file with the phrase "Hello World!". The file source properties are set to repeat (Repeat = "Yes"):

2PAM modulator

Notes

You can leave the preamble and access code fields blank in the packet encoder and packet decoder blocks, and default values will be chosen automatically.
If you create your own access codes (like I do in this example), the packet encoder and packet decoder codes must match perfectly for the decoder to pass the data (this is obvious).
If you create your own access codes, you must choose long codes. I experimented with different access code lengths and the encoder/decoder blocks just don't work for short codes. I don't know the magic number of bits you need for the access codes, but if it is not working for you, try a longer code!
I included a scope in the flow graph above to confirm that the File Source was indeed sending the correct bits. For example, I created a source text file, wich included just the letter "h". Then I observed that, indeed, the file was sending the expected ASCII 1's and 0's pattern for the letter "h".