- This topic has 15 replies, 2 voices, and was last updated 11 months ago by
.
-
Posts
-
-
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. -
-
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-
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. -
-
-
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)… -
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
-
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.
-
-
Hi,
I understand, as you can check here,you must close the opened structure.
Bye Renzo
-
-
-
-
-
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!)
-
-
-
-
- You must be logged in to reply to this topic.
