Stuck at Joining... process

[akapong-tkc]

Hi There,

I've some problems about configure this library into out customize board.
Serial Monitor always show Joining... but logs in Chirpstack show status JoinAccept already.
and I've debug to show on Serial Monitor it's shown that In LORA_join_Accept function the Message_Status always return TIMEOUT even I've uncommented delay(900); on join function.

I've developed with these environments.

• Board : Customize board with ESP32.
• Board Library : ttgo-lora32-v1.
• LoRa Module : SX1276. ( Connected DIO pin only DIO0 or I've to connect DIO1 and DIO2 too ? )
• Frequency : AS923
• Device Class : Class C
• Code Editor : PlatformIO on VSCode
• I've use code in example : Class-C-ABP but change to OTAA

So can you suggest anything ? Thanks for your kindly support

[akapong-tkc]

This is the code that i use.

#include <lorawan.h>
 
const char *devEui = "**********";
const char *appEui = "**********";
const char *appKey = "**********";  

const unsigned long interval = 60000;    // 10 s interval to send message
unsigned long previousMillis = 0;  // will store last time message sent
unsigned int counter = 0;     // message counter

char myStr[50];
char outStr[255];
byte recvStatus = 0;

const sRFM_pins RFM_pins = {
  .CS = 18,
  .RST = 14,
  .DIO0 = 2,
};

void setup() {
  // Setup loraid access
  Serial.begin(115200);
  delay(5000);
  Serial.println("Start..");
  if(!lora.init()){
    Serial.println("RFM95 not detected");
    delay(5000);
    return;
  }

  // Set LoRaWAN Class change CLASS_A or CLASS_C
  lora.setDeviceClass(CLASS_C);

  lora.setDataRate(SF9BW125);

  // set channel to random 
  lora.setChannel(MULTI);

  // Put OTAA Key and DevAddress here
  lora.setDevEUI(devEui);
  lora.setAppEUI(appEui);
  lora.setAppKey(appKey);

  // Join procedure
  bool isJoined; 
  do { 
    Serial.println("Joining...");
    isJoined = lora.join(); 
    //wait for 10s to try again
    delay(10000);
  }while(!isJoined);

  Serial.println("Joined to network");
}

void loop() {
  
  // Check interval overflow
  if(millis() - previousMillis > interval) {
    previousMillis = millis(); 

    sprintf(myStr, "Counter-%d", counter); 

    Serial.print("Sending: ");
    Serial.println(myStr);
    
    lora.sendUplink(myStr, strlen(myStr), 0, 1);
    counter++;
  }

  recvStatus = lora.readData(outStr);
  if(recvStatus) {
    Serial.print("====>> ");
    Serial.println(outStr);
  }
  
  // Check Lora RX
  lora.update();
}

[Eric286]

Dear @akapong-tkc !
Thank you for contacting us.

You appear to be utilizing only these pins, as I can see. And that may be the most probable error for which you are having this behavior

const sRFM_pins RFM_pins = { .CS = 18, .RST = 14, .DIO0 = 2, };

Utilizing all DIOs as demonstrated in all the examples is essential.

const sRFM_pins RFM_pins = { .CS = 20, .RST = 9, .DIO0 = 0, .DIO1 = 1, .DIO2 = 2, .DIO5 = 15, };

Another possible error would be the selection of the subband.

For this we are going to need to change a file called Config.h, which is located in the src \ arduino-rfm \ Config.h folder.
In this file we are going to comment line 23 and we are going to uncomment line 22 or in case your gateway is working with another subband please uncomment that line.

In the same way I am going to try for my part to see what other possible error may be occurring to you, if I require more information I will let you know.

Have a nice day
Kind regards!
Electronic Cats Support Team.

[akapong-tkc]

Hi there,

Thank you for your suggestions.

First, I've change the code about pin as below,

const sRFM_pins RFM_pins = {
  .CS = 18,  .RST = 14, .DIO0 = 2, .DIO1 = 4, .DIO2 = 4, .DIO5 = 4,
};

Noted: Our PCB Board schematic connected only LoRa DIO0 into ESP32 IO2 but we've manual wired LoRa DIO1 into ESP32 IO4 (purple line) as image below.

The problem still occurs as the same. Or I've to manual wired LoRa DIO2 and DIO5 to ESP32 IO too ?

---

Second, About subband.
Actually, I've edited Config.h to use AS_923 frequency band already.
So if I edited subband as your suggestion will be not affect anything because I use AS_923 not US_915/AU_915 , Am I right ?

//Uncomment for debug
//#define DEBUG

// To define your LoRaWAN frequency band here
#define AS_923
//#define AS_923_2
//#define EU_868
//#define US_915
//#define AU_915

// Define max payload size used for this node
#define MAX_UPLINK_PAYLOAD_SIZE 220
#define MAX_DOWNLINK_PAYLOAD_SIZE 220

#if !defined(AS_923) && !defined(AS_923_2) && !defined(EU_868) && !defined(US_915) && !defined(AU_915)
#define US_915  // Define default Region
#endif

#ifdef US_915
//Select the subband you're working on
// make sure your gateway is working with the selected subband
//#define SUBND_0     // 902.3 - 903.7 Mhz
#define SUBND_1     // 903.9 - 905.3 Mhz
//#define SUBND_2     // 905.5 - 906.9 Mhz
//#define SUBND_3     // 907.1 - 908.5 Mhz
//#define SUBND_4     // 908.7 - 910.1 Mhz
//#define SUBND_5     // 910.3 - 911.7 Mhz
//#define SUBND_6     // 911.9 - 913.3 Mhz
//#define SUBND_7     // 913.5 - 914.9 Mhz
#endif

#ifdef AU_915
//Select the subband you're working on
// make sure your gateway is working with the selected subband
#define SUBND_0     // 915.2 - 916.6 Mhz
//#define SUBND_1     // 916.8 - 918.2 Mhz
//#define SUBND_2     // 918.4 - 919.8 Mhz
//#define SUBND_3     // 920.0 - 921.4 Mhz
//#define SUBND_4     // 921.6 - 923.0 Mhz
//#define SUBND_5     // 923.2 - 924.6 Mhz
//#define SUBND_6     // 924.8 - 926.2 Mhz
//#define SUBND_7     // 926.4 - 927.8 Mhz
#endif

Thanks for your kindly support

---

#1st-Edited : We've manual wired LoRa DIO2 to ESP32 IO32 and LoRa DIO5 to ESP32 IO15 still stuck at Joining...

const sRFM_pins RFM_pins = {
  .CS = 18, .RST = 14, .DIO0 = 2, .DIO1 = 4,  .DIO2 = 32,  .DIO5 = 15, 
};

[Eric286]

Hello @akapong-tkc

Sorry for the delayed response.

I was about to say that you shouldn't connect the DIO pins to the same output, but I noticed that you adjusted it and changed the DIO pins to a separate pin.

Continuing the troubleshooting process, you might be able to resolve the issue by adding a 100ms delay to LORA Cycle after it polls DIO0.

do{ if(digitalRead(RFM_pins.DIO0)) //Poll Rx done for getting message { LORA_Receive_Data(Data_Rx, Session_Data, OTAA_Data, Message_Rx, LoRa_Settings); } delay(100) ; // add delay to stop reboot }while(millis() - prevTime < Receive_Delay_1);

In addition, read Lorawan-Arduino-Rfm.cpp: Join (157-176).

Six seconds have been set aside as a timeout.

According to the LoRaWAN standard, JOIN ACCEPT DELAY1 should be 5 seconds and JOIN ACCEPT DELAY2 should be 6 seconds.

So it would appear that we are doing everything according to the regulations, but what about join request and response timings and processing times (gateway bridge to network server to application server and back)?
It's possible that the join accept arrives beyond the predetermined timeout of 6 seconds.

We may add a first timeout since it is certain that we will never receive the join answer before 5 seconds.
Any figure between one and three seconds must be secure.

A 900 ms delay is at line 167. You can also fix your issue by uncommenting that line. More time can be added, reducing the number of loops (line 170).

Please let me know about the tests that we run so that I am aware of what you have attempted and can better assist you.

Kind regards!
Electronic Cats Support Team.

[akapong-tkc]

Hi there,

Thank you very much for your advices.
By the way, I've tried to edit some codes as your advice.
The result still same as before.

I found that In LoraMac.cpp function LORA_join_Accept at line 569
Message_Status = RFM_Single_Receive(LoRa_Settings);
This line also get status TIMEOUT but I didn't sure cause of it, Can you suggest any ?
Noted: In Dragino Gateway Lora Log always show that joinAccept within 5 seconds.

Please let me know, If you want any information to find a solutions.

[akapong-tkc]

Problem still didn't solve, Any new suggestions ?

Merry X'Mas & Happy New Year
Thank you.

[ReYlaN38]

I had the same issue with an arduino, to fix it, i wired dio1 to an digital pin. it looks like dio1 si needed for the lorawan join process. i didn't wired dio2 and dio3.
On your picture, it looks like the esp output is wired to ground too. maybe check with another pin. the ones on the top looks unconnected

[akapong-tkc]

@ReYlaN38 I've connected DIO1 already, but error still as the same. All pins on ESP32 connected. By the way, I've changed to use LMIC library working fine on Device Class A (The library does not support Class C). but I still find code and compatible with Class C Device

[Eric286]

Hello @akapong-tkc

Do you think you could check the continuity of the wires with a multimeter and that they are not touching each other please?

In addition to the suggestion that I gave you to increase the time, how much did you increase it and in what parts?

Kind regards!
Electronic Cats Support Team.

[negis02]

Hi, I running tests with this lib code with esp32 and STM32 custom boards on helium network. All works ok, just while ago have same issue - was not enough strong signal from helium hotspots to receive back "Join Accept", by traveling close to hot spot locations - joined from first try.
My parameters:
Board : Customize board with ESP32 and STMF103.
Board Library : doit esp32 devkit v1 and stm32 bluepill.
LoRa Module : SX1276. ( Connected DIO and DI1 pins)
Frequency : EU868
Device Class : Class C and Class A
Code Editor : Arduino IDE 2.0.3
I've use code in example : heavy modified Example of OTAA device

and i insted of lora.setDataRate(SF9BW125); using
lora.setDataRate(0); //SF12BW125

and after joined i shangint to:
lora.setDataRate(5); //SF7BW125
all enum there: https://github.com/ElectronicCats/Beelan-LoRaWAN/blob/82d6886281c5115f25d7091e8847fbe94e2a5b9e/src/arduino-rfm/Struct.h
and sending with all power, because i using for mapper purposes:
lora.setTxPower(30,PA_BOOST_PIN);

[Eric286]

Hello @negis02

We appreciate you sharing all of the information with us; Thank you for letting us know which option you choose. Let's hope akapong-tkc finds it useful.

Best Regards.
Electronic Cats Support Team.

[Eric286]

Dear @ReYlaN38

Your request has been on hold for the past seven days and is currently awaiting your feedback.

Did your issue behave differently or were tests still able to be run?

Best Regards.
Electronic Cats Support Team.

[Eric286]

Dear @ReYlaN38

We shall now close this issue because of the time that has passed.
You can always reopen it.
In case you have any problems or comments, do not hesitate to contact us again.
Have an amazing day!
Kind regards!
Support Team.