12 April 2022 at 01:26 #20167
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.
Attachments:You must be logged in to view attached files.
12 April 2022 at 02:11 #20169
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);
12 April 2022 at 02:25 #20170
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
12 April 2022 at 16:35 #20171
12 April 2022 at 17:03 #20177
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.
12 April 2022 at 17:09 #20179Renzo MischiantiKeymaster
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.
12 April 2022 at 18:21 #20181
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.
19 April 2022 at 22:50 #20264Renzo MischiantiKeymaster
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?
25 April 2022 at 23:27 #20548
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.
- You must be logged in to reply to this topic.