LoRa - Firebeetle-ESP32 & LoRa TEL0125

Hi, since you are using the official example and the initialization sometimes fails before the frequency setting is executed, maybe is to check the hardware communication between the FireBeetle and the LoRa module.

This does not necessarily mean that the board is damaged. It may be caused by a loose connection, an unstable pin contact, power supply, or SPI communication issue.

Could you please try swapping the two TEL0125 modules between the two FireBeetle boards?

Please check whether the initialization problem:

* follows the TEL0125 module, or
* remains on the same FireBeetle board.

Please also reseat the module and check the 3.3V, GND, MISO, MOSI, SCK, CS, and RESET connections. MISO is especially important, because activity on MOSI only shows that the FireBeetle is sending commands, but it does not confirm that the LoRa module is replying correctly.

This test should help us determine whether the issue is related to the LoRa module, the FireBeetle board, or the connection between them.
 

Hi,

I have done as you suggested, I switched out the TEL0125 modules between the two FireBeetle43-ESP32s, and I have also checked the connections for MOSI, MISO, SCK, CS and RESET, and they are all good on both sets.

In > 90% of cases, the sendTest does not initialize correctly and I get a continuous stream of “Starting LoRa failed” messages.  If I keep pushing the reset button on the CPU, finally, if I am lucky, I get it to start correctly.

In 100% of cases, the receiveTest does not initialize correctly and I get a continuous stream of “Starting LoRa failed” messages.

This leads me to believe that lora.init does not work correctly. 

I am disappointed that there is no support from DFRobot.  I am using DFRobot compnents with a DFRobot library!!!

Alternatively, the modules are defective, but I would hope (an it would seem unlikely) that two ESP32s and two TEL0125s are defective

Thank you for your patience.

Based on the current symptoms—initialization occasionally succeeding and CRC errors appearing afterward—we currently suspect an unstable SPI response, especially on the MISO or CS path, rather than the frequency setting.

The `lora.init()` function fails when it cannot read the expected SX1276 version value `0x12` from register `0x42`.

Could you please upload the following diagnostic sketch to one FireBeetle with the TEL0125 connected?

* If all readings are `0x12`, the SPI hardware connection is working and we should next check the library version or Arduino environment.
* If the readings are always `0x00`, the module may not be responding, or MISO/RESET may be held low.
* If the readings are always `0xFF`, MISO may be floating or CS may not be selecting the LoRa module.
* If the readings change randomly, the most likely cause is an unstable SPI connection, poor pin contact, or unstable power.

#include <SPI.h>

static const uint8_t PIN_SCK  = 18;
static const uint8_t PIN_MISO = 19;
static const uint8_t PIN_MOSI = 23;
static const uint8_t PIN_CS   = 27;  // D4
static const uint8_t PIN_RST  = 25;  // D2

uint8_t readRegister(uint8_t address)
{
   SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));

   digitalWrite(PIN_CS, LOW);
   SPI.transfer(address & 0x7F);
   uint8_t value = SPI.transfer(0x00);
   digitalWrite(PIN_CS, HIGH);

   SPI.endTransaction();
   return value;
}

void resetLoRa()
{
   digitalWrite(PIN_RST, LOW);
   delay(20);
   digitalWrite(PIN_RST, HIGH);
   delay(100);
}

void setup()
{
   Serial.begin(115200);
   delay(1000);

   pinMode(PIN_CS, OUTPUT);
   digitalWrite(PIN_CS, HIGH);

   pinMode(PIN_RST, OUTPUT);

   SPI.begin(PIN_SCK, PIN_MISO, PIN_MOSI, PIN_CS);
   resetLoRa();

   Serial.println("Reading SX1276 RegVersion...");
   Serial.println("Expected value: 0x12");

   for (int i = 0; i < 20; i++) {
       uint8_t version = readRegister(0x42);

       Serial.print(i + 1);
       Serial.print(": 0x");

       if (version < 0x10) {
           Serial.print("0");
       }

       Serial.println(version, HEX);
       delay(200);
   }
}

void loop()
{
}
 

Hi,

Thank you for your response and your suggested sketch.  I ran the sketch on both sets of ESP32/TEL0125 and in both cases the code executed repeatedly giving the expected correct results as shown below:

The conclusion is therefore that both board sets are functioning correctly.  I retried the sendTest sketch provided by DFRobot in the Github on both sets of boards and it executes as expected.  However, the receiveTest sketch does not, and it hangs in the while loop with the lora.init failing, meaning that it is not reading 0x12 from the version register.  What is really puzzling is that the code in sendTest and receiveTest is identical up to that point in each of the sketches

Hi, what an unusual result XD.

At the point where `lora.init()` is called, the sender and receiver sketches are effectively executing the same initialization procedure.

Since the standalone SPI test reads 0x12 correctly on both hardware sets, and sendTest initializes correctly on both hardware sets,

the current result suggests that the two sketches may not actually be compiled under exactly the same conditions. Possible causes include a different board selection, a different copy of the DFRobot_LoRa library, different expansion of the D4/D2 pin definitions, or a stale upload...lots possible.

So maybe try modify sendTest as receiveTest can solve problem?

1. Open the `sendTest` sketch that currently initializes successfully.
2. Keep its `setup()` code unchanged up to and including the successful `lora.init()`.
3. After initialization, add:

lora.setPayloadLength(11);
lora.rxInit();

4. Replace its `loop()` with the receive loop from `receiveTest`.

Actually there was a topic before which problem is "a different copy of the library", but his borad is esp32 S3 AI cam, maybe same as this.

we all have good patience and good luck to you with this solution:)
 

Hi,

Thank you for the reply.

Regarding my note about the connection of RESET, I made a mistake, I do have RESET connected to D2.

The sketches provided by DFRobot have the following code:

void setup()

{

  Serial.begin(115200);

  Serial.println();

  pinMode(LED_BUILTIN, OUTPUT);

  Serial.println("Receiver Test");

  while(!lora.init()) {

    Serial.println("Starting LoRa failed!");

    delay(2000);

  }

lora.setPayloadLength(RX_LEN); // max len is 254

//lora.setFrequency(433000000); // for 433mhz module

lora.rxInit();

}

So, this is the way that lora.init() is coded in both SendTest and ReceiveTest, what do you suggest?  Thank you for the suggestion regarding coding setting the frequency to 868MHz, I will uncomment the line that sets to 433MHz.

I saw a note somewhere that an extra connection needs to be made on the receive TEL0125 connecting DIO0 to D7 on the ESP32, is this required?

Kind regards

The additional DIO0-to-D7 connection is not required when using these DFRobot examples. The library checks the interrupt status through SPI with lora.waitIrq(), and both side set 868000000 should be work, any other message can you share with us? Terminal output, Serial monitor, or other information?