[george_santiago]

Hi Renzo
About that post, the total byte size of the message would be something like:

+ 3 bytes - CHAN, ADH, ADL of Recipient
+ X bytes - Payload Message (Ex: size_of(strutc))
+ 1 bytes - RSSI (If enabled)

Does cryptography (CRYPT_H + CRYPT_L + KeeLoq method used in the library) not influence the final size of the message?
Thanks

[george_santiago]

Hi Renzo
Thanks for the answer.

In ESP32, we have ESP.restart() method
So isn’t there an equivalent ( E220.restart() ) for the E220?
I want to implement a routine like this just in case.
Ex:
If the endpoint(ESP32) does not receive a message from the Gateway within 60 minutes, then:

E220.restart();
delay(100);
ESP.restart();

Thanks

[george_santiago]

Would using the digitalRead() function help?

Think of something like:
1) Check the status of pins M0 and M1 with digitalRead(). If the pins return HIGHT then make the configuration changes on the E220. Otherwise, print warning and do not make changes.

digitalRead() will not guarantee correct return as it will know the state of the MCU pin. But maybe this could help with the memory leak.

If the M0 and M1 pins are disconnected (floating), do they have an internal resistor (pullup or pulldown)?

2) Another issue would be to not allow messages to be sent when M0 and M1 pins are HIGHT. When M0 and M1 are in HIGHT, the E220 does not send messages, correct? If so, it would be interesting to issue a printout with a warning (“Cannot send messages. Pins M0 and M1 at HIGHT level”).

[george_santiago]

I had loop reset (Watchdog triggering) issues with the NodeMCU (esp8266) when sending a message with the LoRa_E220::sendMessage function. The message was sent, but the last character of the String was truncated. Then the ESP8266 restarted because of the Watchdog.
Found out this was caused by not connecting the AUX pin to a GPIO. After connecting AUX from E220, ESP8266 stopped resetting.

My current builder setup:

#include <SoftwareSerial.h>
SoftwareSerial mySerial(D5, D6); // Arduino RX <-- e220 TX, Arduino TX --> e220 RX
//LoRa_E220 e220ttl(&mySerial, D0); // AUX M0 M1 . // Se não incluir o AUX no MCU, provoca WatchDOG.
LoRa_E220 e220ttl(&mySerial, D0, D7, D8); // AUX M0 M1 . // Se não incluir o AUX no MCU, provoca WatchDOG

[george_santiago]

In the file ‘LoRa_E220.cpp’ change lines 831 and 850:

LoRa_E220.cpp#L831
in:
byte size = message.length(); // sizeof(message.c_str())+1;
to:
byte size = message.length() + 1; // sizeof(message.c_str())+1;

LoRa_E220.cpp#L850
in:
byte size = message.length(); // sizeof(message.c_str())+1;
to:
byte size = message.length() + 1; // sizeof(message.c_str())+1;

Please let us know if the message was sent and received correctly after these changes.

[george_santiago]

OBS: I am using RSSI Enabled
#define ENABLE_RSSI true

[george_santiago]

Hi Renzo

I had a similar problem and I think I found the source of the bug.
The bug occurs when using a String type variable for the message. The Sender does not send the last character of the String.
Ex: When sending “101”, the Sender sends “10”, that is, it does not send the last character.
Ex:

static int msg = 100;
msg++;
String msg_sent = String(msg);
Serial.print("Sent Message: ");
Serial.println(msg_sent);
ResponseStatus rs = e220ttl.sendMessage(msg_sent);

I think the bug is on line 831:
LoRa_E220.cpp#L831

At the moment:
byte size = message.length(); // sizeof(message.c_str())+1;

I changed it to:
byte size = message.length() + 1; // sizeof(message.c_str())+1;

Everything worked fine.

There are other parts of the code that may need fixing. (I haven’t tested yet)
Ex:Line 850:
LoRa_E220.cpp#L850

ResponseStatus LoRa_E220::sendFixedMessage(byte ADDH, byte ADDL, byte CHAN, const String message){
	byte size = message.length(); // sizeof(message.c_str())+1;

[Author]

Posts