Hi,  I have implemented the LoRa_sender.ino and LoRa_receiver.ino, as per the eBook “Learning ESP32 using Arduino IDE”.  I did change the loop-through timing to be every 1 minute instead of every 10 seconds.  I let this run and find that after ~ 2 hours, the receiver hangs – stops.  I power-cycled the receiver and it starts recording packets in the time expected for 1 per minute, showing the the sender has not failed. I am not using the serial port – just a battery and the display on the receiver. I find this happens even when I change ESP32s.  (both units have good antennas and are within a few feet of each other).

I don’t see any such problem in the blog, and see that others have successfully used LoRa over weeks.

Is there any links to blogs or whatever that could help identify this problem ?

When I used the serial port, I modified the parsePacket() function in LoRa.cpp (in the arduino-LoRa library) to print just as it enters parsePacket(), and then after it checks the interrupt register.  When it hangs, it has not gotten to parsePacket(), and the last thing printed out is the RSSI.  Did the LoRa receiver just stop?

Any help is appreciated.  Thanks  (it’s very frustrating that there isn’t an equivalent to the try/except method to identify when something like this happens).

Hi Joe.
 
I remember that I had another reader with the same problem.
 
What he did was add a command to automatically restart the ESP32 receiver every hour. This doesn’t solve the issue, is just a workaround. However, accordingly to that reader, that solved the problem and the receiver didn’t miss any more packets.
 
Regards,
Sara

Thanks Sara.  I had tried that re-setup in a more complicated code I developed in desperation but it didn’t work.  HOWEVER, with the simple sender-receiver code of the eBook, it works and ran 12 hours without hanging!  Since the situation is in a remote area without internet and minimal batteries, I had to implement a counter in the loop() , which I timed to figure how many loops before it should reset.  For anyone interested, it takes 5 million loops to get to 5 minutes. I had the sender outputting a packet every 1 minute, and the receiver code reset after ~5 minutes. 
 
This was the code I put in loop() (where ctrToReset1 was declared as int ctrToReset1 = 0; before any functions):
 
ctrToReset1++;
if(ctrToReset1 == 5000000){     // 5,000,000 ~ 5 min
   Serial.print(“ctrToReset reached max – resetting LoRa receiver .. “);
   if (!LoRa.begin(915E6)) { //915E6 for North America
      Serial.println(“Starting LoRa failed!”);
       while (1);
   }
   Serial.println(“LoRa Initialized OK!”);
   ctrToReset1 = 0;
}
 
I intend to figure out why the parsePacket() function is always returning 0 (i.e. why the interrupts are not staying cleared to allow the packetLength variable to be anything but 0).  More on this later.

Ok.
Thanks for sharing.
Let us know your findings later on.
Regards,
Sara

Hi Sara … well, in my 4 day remote mountain experiment with 3 senders (each with 5 sensors) and 1 receiver, the receiver hung after 4 hours. It was programed to send send packets every 1/2 hour and resetting every 1/2 hour (it worked fine for 24+ hours when sending packets every 3, 5 or 7 minutes from the 3, and resetting every 5 minutes – but too much data and battery use for a long-term run).  That was a one-time shot at doing a remote sense project and I can’t easily “try again”, but eventually will.  So, I’m now trying to understand why it hung.

I have 2 questions that I’m hoping can be answered:
1) The receiver code I used was taken from the eBook, and not the examples in the LoRa library.  In the eBook, there is code that reads the packet after confirmation via the interrupts that a packet was received.  This code is:

String LoRaData = LoRa.readString();
Serial.print(LoRaData);

I know this works because I’ve seen the LoRaData on the Serial Monitor ….. BUT, there is no readString() function in the LoRa.h or LoRa.cpp files !!  (there is the parsePacket(), available() and a read() … but no readString() )  I looked everywhere – stdin, wire, SPI …everywhere, but no where is a readString() defined.  What am I missing?  It does work, so it is clearly compiled somehow without errors…. does anyone know where it is defined?  This is critical to know since there is a variable _packetIndex initialized as 0; that needs to be incremented while reading the FiFo.  It is incremented in the LoRa.read() function (and makes total sense), but how is it incremented in this mysterious LoRa.readString() function?  (could this cause a hang? — the example code in the LoRa library uses the read() function by the way – where did the readString() come from?)

2) in the eBook code, there is a call to parsePacket(), but the argument is blank.  In the LoRa.cpp library code, this function takes an argument:  int LoRaClass::parsePacket(int size) .  size is later tested for >0.  My question is: if no argument is given in a call, what is the argument taken as ?  (in what I found on the web, one should never call a function expecting an argument with no argument … this is critical since it determines whether the mode is implicit or explicit header mode.  … so I’m a bit confused; could this cause a hang?).

Both these questions probably don’t answer why the receiver hung,  but I need to understand everything 100% to debug it. Thanks for any help.  (BTW, the code for the receiver is unnecessarily complex and meant for product design engineers – I will provide a much simpler version for hobbiests once I figure out what’s going on in this multi-sender experiment; no wifi — just LoRa communcations in remote mountain environment)

I found readString() in the stream.cpp, which, from the web,  has the LoRa class as a child, inheriting all the Stream class stuff. …. so, it’s pretty well hidden but there.  … and is why it works (so, not a suspect in the “hanging” of the receiver issue).  Also, I determined that the argument passed in parsePacket(), where it expects a size is a 0, so the check in that function for size is ok (another cause for the “hanging” of the receiver eliminated).
 
the receiver code loops constantly through the parsePacket() code and could hang if a CRC error is generated – the system will then never get out of the RxSingle mode (in which it can’t write to registers, meaning it can’t clear the CRC interrupt) … but resetting the chip every 1/2 hour should have put the system back into Standby mode and clears all interrupts. … a puzzle.  I’ll have to build another 4 boxes and see if I can catch the hang somehow. … if you can leave this unanswered, I’d appreciate it. 

Hi Joe.
Thanks for sharing your findings.
We’ll leave this issue open so that you can keep adding your findings.
Regards,
Sara

Hi Sara …. I have finally resolved (to my satisfaction) the cause of the LoRa modem hanging.  I have written up the finding here: https://github.com/jamargevicius/LoRa-Modem-with-ESP32  along with code I re-wrote that doesn’t use the LoRa.h library.  The bottom line is that in my case, the hanging was caused by hardware issues: glitches on the modem reset line when the ESP32 wakes up, and brown-out levels of voltage being applied to the ESP32 by lithium batteries.  I don’t plan to do more on this, so you can finally close this.  Thanks! — JoeM

Hi.
Thank you so much for taking the time to describe your experience in such detail.
That will surely be useful for our readers. Thank you.
Just for clarification, your URL contains some extra characters. The following URL works:

• https://github.com/jamargevicius/LoRa-Modem-with-ESP32

Thanks once again.
I’ll mark this issue as resolved. If you need further help, you just need to open a new question in our forum.
Regards,
Sara