Packet Communications: Difference between revisions
No edit summary |
|||
Line 1: | Line 1: | ||
<b>NOTE: This document is being revised. The previous version can be found in [[Packet_Communications_Test_Page]].</b> | |||
<b>NOTE:</b> | <br> | ||
< | |||
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. | 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. | ||
Line 14: | Line 13: | ||
* [[Understanding_ZMQ_Blocks|'''Understanding ZMQ Blocks''']] | * [[Understanding_ZMQ_Blocks|'''Understanding ZMQ Blocks''']] | ||
* [https://www.gnuradio.org/doc/doxygen/page_packet_comms.html '''Packet Communications'''] Note: the flowgraphs referenced in this document are contained in [https://github.com/gnuradio/gnuradio/tree/main/gr-digital/examples/packet gr-digital/examples/packet]. | * [https://www.gnuradio.org/doc/doxygen/page_packet_comms.html '''Packet Communications'''] Note: the flowgraphs referenced in this document are contained in [https://github.com/gnuradio/gnuradio/tree/main/gr-digital/examples/packet gr-digital/examples/packet]. | ||
== Header Format Object == | == Header Format Object == | ||
Line 32: | Line 27: | ||
* digital.header_format_counter(access_code, threshold, bps) | * digital.header_format_counter(access_code, threshold, bps) | ||
== Using Header Format Default and Correlate Access Code == | |||
== | |||
=== Building the flowgraph === | |||
Build the following flowgraph using the details given below: | Build the following flowgraph using the details given below: | ||
[[File: | [[File:Str_pkt_11_fg.png|800px]] | ||
<hr> | <hr> | ||
This flowgraph can be downloaded from [[Media:Str_pkt_11.grc]]. | |||
This flowgraph can be downloaded from [[Media: | |||
; File Source | ; File Source | ||
Line 398: | Line 53: | ||
The entry for the Format Obj. is 'hdr_format' | The entry for the Format Obj. is 'hdr_format' | ||
; | ; Correlate Access Code - Tag Stream | ||
The | The Access Code is a ''string'' with the 32 bit value. | ||
<hr> | <hr> | ||
=== Testing === | |||
The success of this methodology is based on the input file being padded to a multiple of 'packet_len' bytes so that the last few bytes of the source file are not lost in a partial unprocessed packet. To create a padded file for input to the flowgraph, the following Python program can be used: | The success of this methodology is based on the input file being padded to a multiple of 'packet_len' bytes so that the last few bytes of the source file are not lost in a partial unprocessed packet. To create a padded file for input to the flowgraph, the following Python program can be used: | ||
Line 463: | Line 118: | ||
<hr> | <hr> | ||
== Using an alternate File Source block == | |||
There is an Out-of-Tree (OOT) module which reads a text or binary file and produces a stream output with 'packet_len' tags for GNU Radio. Functionally it replaces a 'File Source' block and a 'Stream to Tagged Stream' block. The advantage of this block is that when the input file size is not an exact multiple of the selected packet length, the remainder at the end of the file is not lost in the 'Stream to Tagged Stream' buffer. This precludes the need for a pre-processor such as the text padding program above. | There is an Out-of-Tree (OOT) module which reads a text or binary file and produces a stream output with 'packet_len' tags for GNU Radio. Functionally it replaces a 'File Source' block and a 'Stream to Tagged Stream' block. The advantage of this block is that when the input file size is not an exact multiple of the selected packet length, the remainder at the end of the file is not lost in the 'Stream to Tagged Stream' buffer. This precludes the need for a pre-processor such as the text padding program above. | ||
Line 522: | Line 143: | ||
[[Category:Tutorials]] | [[Category:Tutorials]] | ||
Revision as of 18:42, 27 January 2025
NOTE: This document is being revised. The previous version can be found in Packet_Communications_Test_Page.
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 Note: the flowgraphs referenced in this document are contained in gr-digital/examples/packet.
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)
Using Header Format Default and Correlate Access Code
Building the flowgraph
Build the following flowgraph using the details given below:
This flowgraph can be downloaded from Media:Str_pkt_11.grc.
- File Source
The File Source reads a padded text file and outputs to a stream.
- Stream to Tagged Stream
Converts a regular stream into a tagged stream by adding length tags in regular intervals.
- Stream CRC32
The Stream CRC32 block computes the CRC of the payload and appends the value to it.
- Protocol Formatter
The entry for the Format Obj. is 'hdr_format'
- Correlate Access Code - Tag Stream
The Access Code is a string with the 32 bit value.
Testing
The success of this methodology is based on the input file being padded to a multiple of 'packet_len' bytes so that the last few bytes of the source file are not lost in a partial unprocessed packet. To create a padded file for input to the flowgraph, the following Python program can be used:
#!/usr/bin/python3 # -*- coding: utf-8 -*- # Padded_File_Source.py import os.path import sys Pkt_len = 252 _debug = 1 # set to zero to turn off diagnostics if (len(sys.argv) < 2): print ('Usage: python3 Padded_File_Source.py <input file>') print ('Number of arguments=', len(sys.argv)) print ('Argument List:', str(sys.argv)) exit (1) # test if file exists fn = sys.argv[1] if (_debug): print (fn) if not(os.path.exists(fn)): print('The input file does not exist') exit (1) # open input file f_in = open (fn, 'r') # open output file f_out = open ("padded.txt", 'w') while True: buff = f_in.read (Pkt_len) b_len = len(buff) if (_debug): print (b_len) if b_len == 0: print ('End of file') break while (b_len < Pkt_len): buff += ' ' b_len += 1 # write output f_out.write (buff) f_in.close() f_out.close()
Note that the 'Pkt_len' in the Python program and the 'packet_len' value in the flowgraph 'Stream to Tagged Stream' block must be the same. The output of the Python program is a file named "padded.txt".
To test the flowgraph:
- Run the Python program to produce a padded text file.
- Execute the flowgraph.
- Examine the output file "output.txt". The output file will be the same as the original file, but will have trailing spaces at the end as a result of the padding.
Using an alternate File Source block
There is an Out-of-Tree (OOT) module which reads a text or binary file and produces a stream output with 'packet_len' tags for GNU Radio. Functionally it replaces a 'File Source' block and a 'Stream to Tagged Stream' block. The advantage of this block is that when the input file size is not an exact multiple of the selected packet length, the remainder at the end of the file is not lost in the 'Stream to Tagged Stream' buffer. This precludes the need for a pre-processor such as the text padding program above.
The module is in gr-File_Source_to_Tagged_Stream. It contains build instructions and an example flowgraph.
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:
- 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.
- 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
andpkt_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.