Bug when sending number with LoRa_E220 sendMessage?

[George]

Hi Renzo

Thanks for this fantastic library!

I started using the LoRa E220 library.

The first test I did was to send sequential numbers every 2 seconds between a sender -> receiver.

I identified that from 1 to 9, there were packet losses (ex: the receiver did not receive the numbers 3, 5, 7) and after 10, the receiver could only read the first number (Ex: When sending 23, only 2 .If you send 115, it only reaches the receiver 11).

When analyzing the library code, I saw this code snippet byte size = message.length(); // sizeof(message.c_str())+1; (line 829 of the ResponseStatus function LoRa_E220::sendMessage(const String message)).
By changing the code to byte size = message.length() + 1;, there is no more data loss(!!!), and the bug that lost the final number has been fixed (!!!).

However, a new bug appeared. The receiver no longer receives the RSSI value.

code:

[George]

Update: The bug is not worked around with the suggestion below. See the next posts.
I got around the “bug” by concatenating a space at the end of the message. There is no data loss and the receiver receives the complete numbers.

String msg_txt = String(msg_num) + String(" ");
ResponseStatus rs = e220ttl.sendMessage(msg_txt);

[George]

NOTE: When compiling the code in VSCode + Platformio, this warning appears:

Building in release mode
Compiling .pio\build\nodemcuv2\src\main.cpp.o
Compiling .pio\build\nodemcuv2\lib14b\EByte_LoRa_E220\LoRa_E220.cpp.o
.pio\libdeps\nodemcuv2\EByte_LoRa_E220\LoRa_E220.cpp: In member function 'void LoRa_E220::writeProgramCommand(PROGRAM_COMMAND, REGISTER_ADDRESS, PACKET_LENGHT)':
.pio\libdeps\nodemcuv2\EByte_LoRa_E220\LoRa_E220.cpp:552:12: warning: unused variable 'size' [-Wunused-variable]
  552 |    uint8_t size = this->serialDef.stream->write(CMD, 3);
      |            ^~~~
Archiving .pio\build\nodemcuv2\lib14b\libEByte_LoRa_E220.a
Linking .pio\build\nodemcuv2\firmware.elf
Retrieving maximum program size .pio\build\nodemcuv2\firmware.elf

[George]

Update:
The above mentioned strategy of using String msg_txt = String(msg_num) + String(" "); did not fix the RSSI bug. It just froze the RSSI number at a certain value.
See attached image:

[George]

If you do not activate “#define ENABLE_RSSI true” the modules do not communicate correctly. There is a lot of data loss in sending and receiving.
When I activate “#define ENABLE_RSSI true”, the modules communicate correctly, but there are the bugs reported in the posts above.

[Renzo Mischianti]

Hi George,
this week I can’t explore these problems.
But I check all when return.

For the RSSI remember to activate It in the device configuration.

Try to use a structure to check if the problem persists.

Bye Renzo

[George]

Thank you very much, Renzo

I bought EBYTE 220 modules. I started testing with their fantastic library.

If I identify something “strange”, I will open a post here on the forum.

I’m not a professional programmer (I know R Language and I’m a beginner in C/C++). But I will try to test and send feedback.

I sent an email to EBYTE with the suggestion that they finance/sponsor the development of their library.

Thank you very much.

[Renzo Mischianti]

Hi George,
I try to replicate the problem with an example sketch but for me work all correctly.

I use an Arduino Nano 33 IoT and an STM32F103 without RSSI enabled and It seems all ok and I try with RSSI enabled and the same sketch with RSSI enabled and all It’s ok.

Can you help me to find the problem?

Bye Renzo

[George]

Hi Renzo

I’m traveling now. Next Sunday (01/05), I will perform more tests and send the results.

Thank you very much for your attention and for the development of the library.

[Author]

Posts