LORA and 2 lopys problem

[monersss]

Hello,
Since I am not getting any feedback on lopy part of the forum i was hoping that maybe someone here will be willing to help me..

The problem I have is as follows:
I am working on connection serial -lopy-lopy-serial.
I need to send an alert to 1 lopy via serial and than forward it to a second lopy via LoRa.
Since I want to be sure that the whole alert has been sent it has to finish with special character \n. It works well till i am using LoRa, where what I am getting on second lopy is my alert but without \n. Could you help me to understand what i am doing wrong?
Computer code is this one:

import os
import serial
import time


ser = serial.Serial("/COM6", 115200, timeout = 10)
alert0 = 'message' + '\n'
alert = alert0.encode('utf-8')
ser.write(bytearray(alert))
        
ser.close()
        
time.sleep(3)

First lopy:

from machine import UART
from network import LoRa
import socket
import pycom
import time

uart = UART(1, baudrate=115200, pins = ('P20', 'P21'), timeout_chars=2000)
lora = LoRa(mode=LoRa.LORA, frequency=863000000)
s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
s.setblocking(False)

while True:
    data = uart.read(1000)
    print ('.')
    if (data is not None) and ('\n' in (data.decode('utf-8'))):
        print(data)
        s.send(data)
    final = s.recv(64)
    print(final)
    time.sleep_ms(1000)

and second lopy, where I receive the alert via LoRa and save it on SD is here:

from network import LoRa
import socket
import pycom
import time

lora = LoRa(mode=LoRa.LORA, frequency=863000000)
s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
s.setblocking(False)

while True:
    data1 = s.recv(64)
    if len(data1) > 0:
        s.send('data here')
        with open('/sd/lora_alert.txt','ab') as f:
            f.write(data1)
    else:
        s.send('no alerts')
    time.sleep(2)

and here i got stuck as what i get on SD is not what I have sent...

[jcaron]

@monersss Raw LoRa is a best effort medium with absolutely no acknowledgements or retransmissions.

If you want to be sure that data has been received, you will need to implement such a strategy. That involves adding frame counters (not absolutely needed in the most basic case, but it’s usually a good idea), sending back ACKs when you have received data, and resending data if you don’t get the ACK.

Note that if your target scenario is not point to point but multiple senders to one receiver, LoRAWAN may be a simpler option as this can be handled by LoRaWAN. However be aware of the limitations on the band.

[monersss]

@crumble I have modified my code, so Lopy stores Lora messages only when sent by me. This way i am sure that only the data i am interested in are stored on second Lopy. What worries me is that if there will be a lot of traffic going on it can overflow my LoRa buffer and my data will not be received. How to avoid this possibility?

thanks in advance

Monika

[monersss]

@crumble thanks I will modify my code according to your instructions, although this does not solve my problem.. I am getting the message i am sending but without \n which i really need at the end of my alert.
This will be also a problem when i will try to do the same while trying to send .jpg. Over serial i will use chunks not to overflow the buffer but when i will be sending it over lora in chunks i need to know when the whole file is transferred by using special character at the end...
Do you know what maybe the reason why i am not getting \n on my second lopy SD? Probably i did some mistake in the code itself...

[crumble]

@monersss

If you receive sometimes garbage, some else is sending on your frequency. You have to use a protocol. Starting with some kind of address followed by the payload. Then you can check if the address belongs to your LoPys. In this case you can write the payload on the SD card. Otherwise you simply drop it.

Let your receiving LoPy switched on for some hours and send nothing from your first one. You may find some strange data in your file, because someone is sending encrypted data on your frequency. Even if the file is empty and no one is sending actualy, someone may do this in the future. So you have to be prepared for this.