FORUM

Corrupted messages from time to time

LoRa Basics™
#1

I am working on an agricultural automation project and as a part of it right now I am testing simplex Lora communication between 2 ESP32 with RA-02 units: one as sender and the second one as receiver. I am using the default configuration of the RA-02, I’m sending a message every second, the emitter and receiver are side by side on my desk, RSSI is -26 and SNR 9. Everything runs quite well, but from time to time the receiver gets a corrupt message (201 times in 25900 messages) and deserialization library gives an error. After the error, communication continues till next error.

I am quite experienced with ESP32 but I am new to Lora and probably I am missing something basic, but … any idea about what should I do to avoid these communication errors ? Any hint ?

Thanks and best regards

Joan

#2

Some errors in packets are inevitable, external RF noise sources etc.

LoRa devices can do CRC checks on packets, but you need to have the rejection of packets which fail a CRC check enabled in your software.

There is also the issue of ‘phantom packets’ which are generated internally by the LoRa receiver device, your LoRa library might not detect and reject these.

If you want reliable comms you really need to add your own error checking in your packet structure so that you can reject the almost inevitable erros.

#3

1- Thanks for yor reply. I’m new on this and I don’t know how many errors on the payload can be considered “normal” as you point out. Right now in my particular case the error rate is around 1%. Should I consider this “normal” ?
2- Something that I wonder is what does it happen if the receiver starts receiving when the emitter has already been emitting for a while. Could this explain errors on the payload ?
3- The 1% error rate does not convey a big problem for me because the errors are detected in my particular case by the deserialization routine. I simply discard the message and wait for a new one. Anyway I plan to add some CRC or checksum in the future.

#4

You need to plan for some messages being missed or corrupt, that the nature of RF communications.