Lora radio 433 module corrupting long packets, even with provided example


(easy reproducer at the end)

I am using a Lora Radio with a Seeeduino Lotus.

I have good results in terms of range, but the longer packets are systematically corrupted.

Anything sent that is over around 110 bytes is “correctly” received, but some bytes are missing.

For a (shortened) example, if I send
0x01 0x02 0x03 0x04
I receive
0x01 0x02 0x04 0x00

(See the missing 0x03 in the toy example - In my case this starts happening about one of two bytes after byte ~110), so then I always have about 30 bytes 0x00 at the end of the packets.

The packet obviously passes CRC checks (else I would not receive it on the other end), and Modem config does not change a thing.

I believe this could be linked to the use of SofwareSerial lib used to transmit data to the RFM9x chip. Could it be that the clock jitter or precision is not good enough and that the serial signalling to the RFM9x becomes off, thereby making it skip bytes and ultimately fill the end of the packet with zeroes ?

Anyone saw this behavior before? Any hint how it can be improved ?

In between I will stick to shorter packets, and that should work, but I am far from reaching the max packet payload size of 251 bytes (excluding the lib header) that should normally be useable.

Use the provided rf95_client example, replace the data array in the loop() function with a 251 bytes long string:
uint8_t data[] = "Hello World! def0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789";

What we see in the rf95_client is now
Hello World! def0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789bdf03569ace02468ace02458abef13579bdf13579bde13478ace02468ace023689:face_with_raised_eyebrow: :thinking:

Thanks in advance for any help, and let me know if something is unclear


Just tried using HarwareSerial instead (as version 2.0 of the library supports it), but I have the same behaviour …