LoRa receiver (running example) stops receiving after a random period.

[frasermarlow]

I am working with two Heltec LoRa 32 (v2) boards
Programming on Arduino IDE 1.8.13
heltec.h (ESP32 Dev-Boards library) is version 1.1.0
Running the example found under heltec ESP 32 Dev boards > LoRa> LoraReceiver & LoRaSender (without modification).
Powered via USB from a computer (also tried USB powered from a wall socket and off a 3.7V 650 mAh battery)

The issue I am encountering is that after a seemingly random period of time the receiver board no longer receives the signal. The loop() is still running but no signal is being reported.

A hard reboot of the board works fine and it catches up with the sender almost immediately, but then given enough time will just lose connection again.

I have searched the other posts but can't find something similar reported. Is this a known issue? Any suggestions on how to resolve this? Thanks.

[Cenda608]

I have same problem from beginning, on this Heltec LoRa 32v2 and nodeMCU(atmega328P+Ra-02). Heltec.h is few libraries together. Now I am using standalone libraries and it works great.
For LoRa you can try Sandeepmistry (github.com/sandeepmistry/arduino-LoRa) or Radiolib (github.com/jgromes/RadioLib)
Radiolib is better for me. Small setting example:

#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h> // for OLED
#include <WiFi.h> // for wifi
#include <RadioLib.h> // for LoRa

// OLED
#define OLED_SDA 4
#define OLED_SCL 15
#define OLED_RST 16
#define SCREEN_WIDTH 128 // OLED display width, in pixels
#define SCREEN_HEIGHT 64 // OLED display height, in pixels
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RST);

// LORA
// SX1278 has the following connections:
// NSS pin: 18
// DIO0 pin: 26
// RESET pin: 14
// DIO1 pin: 35
SX1278 radio = new Module(18, 26, 14, 35); // i have SX1278 433MHz

Excuse my english and I am new here.

[krysatpat]

I have the same issue, I had to detect the last time it receive and reinitialize lora after some time.

[fjohannes]

Having the same issue! :/
Will try with standalone libraries now...

[ChangeD20]

Same issue.

It seems it got much better after adding a yield(); after the line with LoRa.parsePacket().

Please share your experience using stand alone library.

Thanks.

[kulaksazov]

I had the same problem with my heltec esp 32 LoRa - at any moment it just stopped taking! There is no such thing with a transmitter.
The problem is solved very easily!
In the loop section, or where the LoRa read loop is, after the end of the loop just put:

// put the radio into receive mode
LoRa.receive();

just to "remind" each time the device that you need to keep taking!
It hasn't stopped yet! At least for me the problem is solved :)
Heltec library version: 1.1.0

[fjohannes]

For me, adding the yield(); after the line with Lora.parsePacket(); did the trick!
It is working flawlessly and reliable for hours since then.
As my receiver also sends a confirmation message back, setting it to LoRa.receive(); mode completely would not be practical.
btw: I did not have to add the yield() to the sender, receiving the (relatively short) confirmation message [horizontal checksum].

[theowlpo]

Hi,
I had the same problem as described above and solved the problem as @fjohannes did, being adding yeld() after the line Lora.parsePacket();

[livioenrico]

I found a solution !!!

Many people have experienced this but until now no one had found a solution:
https://arduino.stackexchange.com/questions/94389/lora-sx1278-stops-receiving-after-a-short-time
sandeepmistry/arduino-LoRa#447
https://stackoverflow.com/questions/63861160/arduino-nano-with-ra-02sx1278-freezes-after-receiving

This is a good workaround, but it wouldn't hurt for SEMTECH to understand why it happens
and also that he would give us the official solution, or fix the defect in his chips.

// ============================================================================
//  Each time the OnReceive callback is called there is a small error chance
//  this could be approximately every 1000, 3000 or sometimes 10000 calls. 
// ----------------------------------------------------------------------------
//  When this happens the DIO0 interrupt pin remains stuck high
//  with a voltage fixed to 3.3V and interrupt receiving no longer works.
// ----------------------------------------------------------------------------
//  To correct this problem we test in the loop() if the DIO0_PIN is HIGH
//  and in this case we redo all the initializations.
// ============================================================================

// ============================================================================
//  RESTART RECEIVER INTERRUPT IF LOCKED
//  This function must be called periodically from the loop()
// ============================================================================
void RestartReceiverInterruptIfLocked()
{
  if (digitalRead(DIO0_PIN) == HIGH)
  {
    RTX_Init();
  }
}

// ============================================================================
//  RTX INIT
// ============================================================================
void RTX_Init()
{
  // ---------------------------------------------- BEGIN
  while (!LoRa.begin(RTX_FREQUENCY))
  { 
    Serial.println("Error initializing LoRa module");
    delay(100);
  }
  // ---------------------------------------------- SETTINGS
  LoRa.setTxPower(17); // do here your additional settings           
  // ---------------------------------------------- REGISTER CALLBACK
  LoRa.onReceive(RTX_OnReceive); 
  // ---------------------------------------------- START RECEIVE 
  LoRa.receive();
}

[livioenrico]

The yield() solution can be applied only if the code works in polling mode:

void loop() {
  // try to parse packet
  int packetSize = LoRa.parsePacket();
  yield();
   . . .
   . . .  and so on. . . 

I do not know if this solution has some effect because working in polling mode my test are always passed without problems. And my test are really long, more than 800 000 TX and RX (ten transmissions per second for 24 hours) without any problem. While doing similar tests please work in isolated room and without antennas.

The locking problem happens only when the code is in interrupt mode (with the DIO0 pin connected) and you register the onReceve() callback in the setup():

  // ---------------------------------------------- REGISTER CALLBACK
  LoRa.onReceive(RTX_OnReceive); 
  // ---------------------------------------------- START RECEIVE 
  LoRa.receive();
   . . .

And in this scenario there is not a parsePacket() call.

---

WHY APPARENTLY THE CALLBACK WORKS OK ?
When using the callback there is a very small error chance, the reception lock could happen approximately every 1000, 3000 or sometimes 10000 calls, So if you do normal transmissions, for example each 30 seconds, you could test without problems for many days. But after a long time your system will surely lock.

[gh-user-source]

This software blows fat cocks, let it die.

…

On Mon, Jul 22, 2024, 2:07 AM Livio Cicala ***@***.***> wrote: The yield() solution can be applied only if the code works in polling mode: void loop() { // try to parse packet int packetSize = LoRa.parsePacket(); yield(); . . . . . . and so on. . . I do not know if this solution has some effect because working in polling mode my test are always passed without problems. And my test are really long, more than 800 000 TX and RX (ten transmissions per second for 24 hours) without any problem. While doing similar tests please work in isolated room and without antennas. But the locking problem happens when the code is in interrupt mode (with the DIO0 pin connected) and you register the onReceve() callback in the setup(): // ---------------------------------------------- REGISTER CALLBACK LoRa.onReceive(RTX_OnReceive); // ---------------------------------------------- START RECEIVE LoRa.receive(); . . . — Reply to this email directly, view it on GitHub <#61 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATMRKOBHWQMCAQODOXJMIHDZNSOT3AVCNFSM6AAAAABLGC54QSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBSGE2TSNBUHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[livioenrico]

What software are you talking about?
If you're talking about Radiolib.h, I tried that the same error happens also with the Sandeep Minstry's LoRa.h library. The error is not in the Arduino libraries but in the SX1278 chip.

Or maybe there is something we should do that Semtech would do better to explain more clearly in the datasheets.
But I believe that Semtech did not notice this event because it happens very rarely.