Home › Forums › The libraries hosted on the site › EByte LoRa e220 UART devices LLCC68 › module hang-up e220
- This topic has 16 replies, 2 voices, and was last updated 4 months, 1 week ago by
L33t331.
-
AuthorPosts
-
-
16 January 2024 at 12:50 #29287
Hi, I’m not really friends with English, but I think you’ll understand me.
I purchased three e220-900t22d modules to replace nrf24, because nrf does not work at temperatures below -6 degrees according to tests, it cannot send messages, and this is critical for me, because temperatures sometimes reach -40.
And so I took the modules for the test, both are on esp 32, 915 frequency, serial 2, aux is connected, resistors are installed on tx,rx,aux, everything is as per the documentation, m0,m1 to gnd.
The settings that I changed from the standard ones:
-RSI_AMBIENT_NOISE_ENABLED
-RSSI_ENABLED
-LBT_ENABLED
That is, I didn’t have any problems with the setup and everything else, thanks by the way for the library and a detailed description of everything!And so let’s move on to the problem.
one esp 32,lora,ds18b20 module stands on the balcony and sends an array of data: temperature, minimum, maximum, operating time, etc.
The other module is in a room with an oled screen, there is a maximum of two meters and a wall between them, there are no problems in data transmission, they communicate with each other in the period from 8-16 seconds to each other and vice versa send messages, it already works at -18 degrees, which is great.The problem itself is that the modules hang for the second time at 17 o’clock, (yesterday and today) today – exactly 17 hours of work came from the balcony module, while the esp32 themselves do not hang, they continue to work and count the time, etc., the module freezes, the values “nan” come to the module and it no longer accepts messages.
-I come home from work and see that messages have not been received for 7 hours (a timer is prescribed), and there is an indication of esp operation, the last working time of the module from the balcony received by radio is 17 hours., I assume that the serial2 buffer is overloaded, because after restarting the room module, messages start coming from another, and it came that the working time of the balcony is 24 hours, which is correct and means that the balcony did not hang, just the room did not accept information, after restarting the room data to the room – they come, but they do not go to the balcony, after restarting the balcony, the data begins to reach the balcony. -
16 January 2024 at 13:11 #29288
an important clarification, I only rebooted the esp, via the reset button, without resetting the power.
maybe I should try using one of these commands once every half hour:
-serial 2.flush or
-LoRa_E220:: flush or
-LoRa_E220:: cleanUARTBuffer or
-LoRa_220::reset ?? -
18 January 2024 at 15:11 #29293
Hi L33t331,
It seems to be a memory leak problem; try to examine the memory usage and give me feedback.
Check also the power supply, but It isn’t probably.
Bye Renzo-
18 January 2024 at 15:21 #29295
Hello, friend! I had the same assumptions about memory, but for some reason I discarded them, thinking that it was definitely not memory.
now the module is stuck for 18 hours of operation, the data does not reach it, the past value is = nan.
and there are two manual commands:
lora.begin – re-initialization
of serial2.flush.
if they don’t help, I’ll watch the memory.
do I understand correctly that you are talking about free esp memory? tell me the command to watch it, and I won’t make a mistake, I’ll display this value on the OLED screen, and leave the modules on for a day again. -
18 January 2024 at 17:30 #29298
After a minute of operation, after each received message from another module, 52-104 bytes disappear in memory, I read ESP.getFreeHeap().
I’ll leave the module running for a day.
-
-
18 January 2024 at 17:38 #29299
Look at the photo of this after 10 minutes of work, we have the following:
-start – the amount of memory at the beginning of work.
-now – is the current amount of memory.
-diff – is the difference between the last measurement and the current one.
-loss – is the difference between start (initial) and now (current) memory.
Now the loss is twice as much (2144 bytes)…-
This reply was modified 1 year, 4 months ago by
L33t331.
Attachments:
You must be logged in to view attached files. -
This reply was modified 1 year, 4 months ago by
-
19 January 2024 at 08:52 #29302
Yes, there is a memory leak. You must discover which part of the code generates that.
Normally I’m going to add a lot a Serial.print to examine every part of the code.But, when you program, also in the embedded env, It’s a best practice to encapsulate every functionality in functions because when the function ends, It works, and every variable inside is released.
Bye Renzo
-
19 January 2024 at 15:15 #29304
Hello, this piece of code for getting the structure has a problem with a leak, I can’t share anything, I’ve tried a lot, what I know, I’ve run out of ideas, maybe you can help me?
I assume that the error is in the library, because the leak occurs even if the module that should send messages is turned off.if (e220ttl.available()>1) {
#ifdef ENABLE_RSSI
rsc = e220ttl.receiveMessageRSSI(sizeof(Message));
#else
rsc = e220ttl.receiveMessage(sizeof(Message));
#endif
if (rsc.status.code!=1){
}else{
Message message = *(Message*) rsc.data;
#ifdef ENABLE_RSSI
Serial.print(“RSSI: “); Serial.print(rsc.rssi, DEC);
#endif
}
}—–but!!!!!!—–
When receiving STRING – there are no such problems! no leakage, regardless of module settings, leakage only on struct.if (e220ttl.available()>1) {
// read the String message
#ifdef ENABLE_RSSI
rscc = e220ttl.receiveMessageRSSI();
#else
rscc = e220ttl.receiveMessage();
#endif
if (rscc.status.code!=1){
Serial.println(rscc.status.getResponseDescription());
}else{
Serial.println(rscc.data);
#ifdef ENABLE_RSSI
Serial.print(“RSSI: “); Serial.println(rscc.rssi, DEC);
#endif
}
}All code is taken from examples.
-
-
19 January 2024 at 17:20 #29305
Hi,
I understand, as you can check here,you must close the opened structure.
Bye Renzo
-
19 January 2024 at 17:35 #29306
Do you mean rsc.close();?
-
-
19 January 2024 at 18:28 #29307
Yes the close of the structure.
-
22 January 2024 at 15:18 #29324
Hi, you were right, the problem is gone.
50 hours of running time without problems.
Thanks, good luck!
-
-
22 January 2024 at 15:45 #29326
Ahh! perfect.
Would you like to share your project? It’s very interesting.
Bye Renzo-
22 January 2024 at 15:52 #29327
There is nothing particularly interesting there, sending structures and output to oled.
For now, I’m just testing how it will work for 7 days without any problems – I’ll share it!
I am currently working on a small filter, otherwise noise in the data sometimes arrives.
I also want to test the declared operating temperatures in the climate chamber (including up to -40 degrees) while searching for this camera in my city, as soon as I collect all the information, I can unsubscribe and share!)
-
-
22 January 2024 at 16:01 #29328
It’s interesting if you want, I can change your role as an Author, and I’d be happy if you want to write an article about that on the site.
Keep in touch, Renzo-
7 January 2025 at 19:46 #32020
Hi, I completely forgot to unsubscribe, I did a test where the ds18b20 was attached to the Lora module, I filled it with a special coolant and at this temperature (-54 degrees Celsius) it received and sent data to another module, in particular, it transmitted this temperature to another sensor, while the factory declared it to -40 Yes, even though it was short-lived, but still. Let’s say the nrf24 modules no longer work below -6 degrees Celsius due to the fact that these modules are clocked from external quartz on the board and they are very sensitive, they need good quartz, and since there is no temperature compensation in them, they simply stop working)))
Check video: Video youtube
-
-
22 January 2024 at 16:46 #29329
I will try to find time for this, my friend, and I also need time for all these tests)
-
-
AuthorPosts
- You must be logged in to reply to this topic.