Add Reliable Communications To Hermes Messaging Application (ARQ)

[kb1lqd]

Summary

Add an error detection and correction functionality to the Hermes messaging application (i.e. automatic repeat-request: ARQ). This addition should ensure that packets/messages that are corrupted or lost in transmission are detected and resent.

130 is the prior version of Hermes

Problem Explanation

Data sent over the unreliable Hermes application is simple transmitted and vulnerable to corruption or complete loss of data. This is acceptable for small amounts of data or human readable text but is not acceptable for large data transfers where 100% reliable transmission is expected or the data transmission is timed-out. Adding an error detection and correction functionality will address this issue.

Environment

Software

• Use of the Hermes Flask based messaging application

Hardware

Standard Faraday digital radios.

Supporting Information

• https://github.com/FaradayRF/Faraday-Software/pull/133
• https://en.wikipedia.org/wiki/Automatic_repeat_request
• https://www.ibr.cs.tu-bs.de/courses/ws0910/pcn/Documents/Communication_Networks-Fundamentals_Concepts_and_Key_Architectures.pdf

[kb1lqd]

General Planning

• Create threaded timer class for ARQ timing needs
• Create class object containing transmitter state machine options for ARQ
• Create class object containing receiver state machine options for ARQ

[kb1lqd]

I created a simple state machine as shown below:

[kb1lqd]

ARQ Threaded timer module is working in testing! It is working through a transmission waiting for ACK to be received and times out if not after max retry count.

Prompt output below shows debug prints for STATE and 500ms intervals for the state machine logic runstate() function.

Commit: 7b5ef4c7dec0bba8ebc93a117ce551387b85a283

START
START
NEXT DATA
TX
Transmitting:  this 
GET ACK 0.500999927521
GET ACK 1.00099992752
GET ACK 1.50099992752
GET ACK 2.00099992752
GET ACK 2.50099992752
GET ACK 3.00199985504
Retry 0
TX
Transmitting:  this 
GET ACK 0.5
GET ACK 1.0
GET ACK 1.50099992752
GET ACK 2.00099992752
GET ACK 2.50099992752
GET ACK 3.00099992752
Retry 1
TX
Transmitting:  this 
GET ACK 0.5
GET ACK 1.0
GET ACK 1.5
GET ACK 2.00100016594
GET ACK 2.50200009346
GET ACK 3.00200009346
Retry 2
TX
Transmitting:  this 
GET ACK 0.5
GET ACK 1.00100016594
GET ACK 1.50100016594
GET ACK 2.00100016594
GET ACK 2.50100016594
GET ACK 3.00100016594
Retry 3
TX
Transmitting:  this 
GET ACK 0.5
GET ACK 1.0
GET ACK 1.5
GET ACK 2.0
GET ACK 2.5
GET ACK 3.0
GET ACK 3.5
Retry 4
TIMED OUT!

Process finished with exit code 0

When running the code again but this time setting the ACK Receiver flag True after 4 seconds (one timeout) the program never reset the flag.

START
START
NEXT DATA
TX
Transmitting:  this 
GET ACK 0.5
GET ACK 1.0
GET ACK 1.5
GET ACK 2.00100016594
GET ACK 2.50100016594
NEXT DATA
TX
Transmitting:  is
GET ACK 0.5
NEXT DATA
TX
Transmitting:   a
GET ACK 0.5
NEXT DATA
TX
Transmitting:   test
GET ACK 0.501000165939
NEXT DATA
TX
Transmitting:  .
GET ACK 0.500999927521
NEXT DATA

Below is a GIF of dca115005a750ec6527cb0c513aff0f73ac0fa42 in action!

[kb1lqd]

I got a really basic and kinda kludgy ARQ transmit and receive implementation using actual RF units together using HERMES Flask program. It needs a lot of cleaning but the logic is there in ARQ. I think I need to tie in the ARQ in the background to the state machines of Hermes instead of out front.

Below you can see the TX and RX units tranmitting basic data (single words) for testing. TX transmits data and the RX transmits an ACK when data received. The TX is seen not receiving the ACK occasionally and retries transmission and eventually all data is transfered successfully.

This is REAL RF.

Note: By test implementation this is super slow on purpose!

[kb1lqd]

Irrelevent due to https://github.com/FaradayRF/Faraday-Software/pull/236 but will likely do something like this in the future.