Packet Communications Test Page

NOTE: Changing the selected GNU Radio version will not change the Table of Contents.

---

This tutorial presents methods to transmit and receive packet data. As was shown in the QPSK and BPSK tutorials, the received bit data stream could be verified by comparing it to the (delayed) transmitted data. However, there was no way to recover the byte alignment of those bits. That is where packet processing comes into play.

Prerequisites

• QPSK Modulation / Demodulation
• BPSK Demodulation
• Polymorphic Types (PMTs)
• Stream Tags
• Message Passing
• Understanding ZMQ Blocks
• Packet Communications

Notes

Version 3.10

The section "Simulating Baseband Packet Using Stream Data (version 3.10)" was created with GNU Radio version 3.10.5.1.

As noted in Porting Existing Flowgraphs to a Newer Version, the PDU-related blocks have been moved from gr-blocks to gr-pdu, which causes a name change of the id.

Also, the Async_CRC32 block has been replaced by CRC_Append and CRC_Check blocks.

Version 3.9+

The current tutorial has been revised and tested with GNU Radio version 3.9.4.0. The 'Polyphase Clock Sync' has been replaced with the Symbol_Sync; and the 'CMA Equalizer' has been replaced with the Linear_Equalizer and Adaptive_Algorithm.

Links to the flowgraphs have been updated to GNU Radio version 3.9.4.0 except where noted.

Version 3.8

• In the "Basic Packet Processing" section, items have been added where a small change is needed or a difference occurs.

Header Format Object

The following blocks:

• Protocol_Formatter,
• Protocol_Formatter_(Async),
• Protocol_Parser,
• Packet_Header_Generator, and
• Packet_Header_Parser

use a "Header Format Object", but there is no block with that name. To create such an object, a Variable block is used. The 'Value' field can be one of several chioces depending on what type of header is needed, such as:

   * digital.header_format_default(access_code, threshold)
   * digital.header_format_crc(len_key, num_key)
   * digital.header_format_counter(access_code, threshold, bps)

See specific examples below.

Simulating Packet Comms Using Messages

Basic Packet Processing

In order to grasp the basics of packet processing, this section presents a transmitter and receiver simulation using standard GNU Radio blocks without any modulation or channel impairments.

Building the flowgraph

Build the following flowgraph using the details given below:

---

This flowgraph can be downloaded from Media:Pkt_7_base.grc.

NOTE: If using GNURadio 3.8, a small change will need to be made: Move the connections coming out of the 'header' and 'payload' ports on the async protocol formatter from the 'print' port of the Message Debug block to the 'print_pdu' port.

Message Strobe

For the Message Strobe to generate a PDU, the Message PMT must be of the form

 pmt.cons(pmt.PMT_NIL,pmt.init_u8vector(9,(71,78,85,32,82,97,100,105,111)))

This specific vector has a length of 9 and the character values of "GNU Radio". It is sent every two seconds.

Async CRC32

The Async CRC32 block computes the CRC of the payload and appends the value to it.

Variable, Id = hdr_format

The Protocol Formatter uses a Format Object to define its parameters. The one used in this example is

 hdr_format digital.header_format_crc(len_key, num_key)

It generates a header with the packet length, packet number, and a 8-bit CRC. No access code is created.

Protocol Formatter (Async)

The entry for the Format Obj. is 'hdr_format'

PDU to Tagged Stream

Converts received PDUs into a tagged stream by adding length tags.

Tagged Stream Mux

The Tagged Stream Mux combines the header and the payload.

Header/Payload Demux

The Header/Payload Demux block synchronizes with the header data and then outputs the payload data.

Protocol Parser

The entry for the Format Obj. is 'hdr_format'

---

Testing

To test the flowgraph, click the "Execute the flowgraph" icon, or press F6. An example of the output is:

Version 3.9+

***** VERBOSE PDU DEBUG PRINT ******
()
pdu length = 4 bytes
pdu vector contents = 
0000: 0d 10 00 3a 
************************************
***** VERBOSE PDU DEBUG PRINT ******
()
pdu length = 13 bytes
pdu vector contents = 
0000: 47 4e 55 20 52 61 64 69 6f 8f aa 09 f1 
************************************

----------------------------------------------------------------------
Tag Debug: 
Input Stream: 00
  Offset: 13  Source: n/a     Key: packet_len   Value: 13
  Offset: 13  Source: n/a     Key: packet_num   Value: 1
----------------------------------------------------------------------
***** VERBOSE PDU DEBUG PRINT ******
((packet_num . 1))
pdu length = 9 bytes
pdu vector contents = 
0000: 47 4e 55 20 52 61 64 69 6f 
************************************

Version 3.8

NOTE: The output in the MESSAGE DEBUG PRINT section will be the actual ASCII text "GNU Radio".

* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 4
contents = 
0000: 0d 10 00 3a 
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 13
contents = 
0000: 47 4e 55 20 52 61 64 69 6f 8f aa 09 f1 
***********************************

----------------------------------------------------------------------
Tag Debug: 
Input Stream: 00
  Offset: 13  Source: n/a     Key: packet_len   Value: 13
  Offset: 13  Source: n/a     Key: packet_num   Value: 1
----------------------------------------------------------------------
******* MESSAGE DEBUG PRINT ********
(((packet_num . 1)) . #[G N U   R a d i o])
************************************

The first PDU DEBUG PRINT is the header data containing the payload length, packet number, and a CRC8 of the header.

The second PDU DEBUG PRINT is the payload including a CRC32 of the data.

The Tag Debug shows the length tag and the packet number tag.

The third PDU/MESSAGE DEBUG PRINT is the received payload ("GNU Radio").

Using Hardware

If you look at https://github.com/duggabe/gr-control you will see that this tutorial follows the same design. If the user were to build two computer installations with this setup, they could send and receive packets to each other.

Conclusions

Based on this tutorial, there are several things which can be concluded:

1. BPSK and QPSK are not well suited for burst transmissions due to the need for the receiver to converge on the actual timing and frequency values. The longer the times between bursts of data, the more the receiver will need to reconverge on the timing and frequency values for the new burst.
2. Since almost all amateur radio communications are half duplex and bursts of data, a more appropriate modulation would be FSK or AFSK. The same packet formatting and recovery would still apply. A proof of concept has been added to https://github.com/duggabe/gr-control with pkt_fsk_xmt.grc and pkt_fsk_rcv.grc.

Further Observations

During the development and testing for this tutorial, the following items were observed:

• The 'Header/Payload Demux' and 'Protocol Parser' blocks seem to work only with the 'digital.header_format_crc' format.
• The 'Correlate Access Code - Tag Stream' block requires the Default Header Format Obj. and expects a 32-bit access code.