Manage message exchanges on the LoRa network

published: 16 October 2020 / updated 16 October 2020

So far we have detailed the transmission and reception of LoRa messages.

To make a reliable transmission, it is essential to set up a real protocol.

Protocols

When you make a phone call, you engage protocols: dialing, waiting, picking up, dialogue...

Without a protocol, transmitting messages over the air can be random in terms of expected results.

LoRa transmissions do not support a specific protocol. It is up to the programmer to implement these protocols. We will detail the different scenarios and possible solutions.

In the rest of our article, the transmitter that emits the first command will be the BOSS transmitter. The transmitter that receives and processes the command will be the DEPUTY transmitter.

Unanswered emission

Daniel has a portal. He wishes to remotely control the opening. He will therefore ask for its opening using a LoRa transmitter. His BOSS (his remote control) will transmit to the LoRa receiver which controls the portal: DOOR open.

The transmission can fail for various reasons: distance, radio interference, etc...

The CHEF does not expect any response from DEPUTY.

When Daniel is closer to his gate, all he has to do is repeat the request to open.

We are typically in the simplest protocol. BOSS emits and does not expect any response.

This protocol can be used in many situations:

an automatic measurement recorder. It transmits its measurements periodically. It is without importance if measurements are lost...
remote control with visible result immediately: lighting of lamps, closing of blinds, etc...

Emission with reply

Daniel has a warehouse located 2000 meters from his house. This warehouse is also used by his brother. Daniel has put a sensor on the gate which allows to know if this gate is closed or open.

With its LoRa BOSS transmitter, it can transmit a DOOR? command.

The deputy communicator is programmed to respond opened or closed.

In this video, it is this protocol which is implemented, even if it is not in FORTH language:

In this video, the confirmation LED for the requested action takes a moment to activate. This is due to the LoRa transmission delay.

As a reminder, the LoRa network owes its reliability and robustness to this slow transmission. The transmission speed can be improved by acting on the AT+PARAMETERS command:
The LORA REYAX RYLR896 transmitter

If you increase the data rate to 5469 bps, the reliability of this transmission is guaranteed only for a few hundred meters.

Collision management or lack of response

A collision can occur when two transmissions are performed at the same time on the same frequency. The transmitter receiving the message will not be able to analyze and decode the frame received. It will therefore not be able to respond to the sender.

The other case is the lack of response:

or because the DEPUTY is too far from the BOSS /li>
or because the BOSS does not receive the response sent by the DEPUTY

In this case, if there is no response, the message is repeated.

But as a precaution, we will limit these repetitions.

We create a TRrepeat variable:

\ count number transmission 
0 variable TRrepeat

We integrate the management of these repetitions during the transmission of a message:

3 constant maxTR    \ max transmission 
: hello 
    TRrepeat @  maxTR < 
    if 
        1 TRrepeat +!   \ increment number sending 
        11 .ATsend" This is our fisrt LoRa Transmission!" 
        cr  
    then 
  ;

Here, a maximum of three transmissions is allowed. We can adjust this number of transmissions by adjusting the constant maxTR.

The content of the TRrepeat variable is reset to zero on each reception of a response:

You can decide to burn the recipient of the messages if there is too much repeated unanswered messages.

Here is the FORTH code of a trClosed response sent by DEPUTY:

: trClosed ( ---) 
    RCVaddr .ATsend" closed" cr 
  ; 
: trOpened ( ---) 
    RCVaddr .ATsend" opened" cr 
  ;

In the code of trClosed we use the value stored in RCVaddr which is the address of the BOSS.

The DEPUTY transmitter can thus manage the messages of several transmitters having different addresses.

NOTE: except in very exceptional circumstances, a DEPUTY module does not manage the repetition of transmission, because it is not he who initiated the transmission.