RAK5205 Join Accepted not received


My RAK5205 stopped working today. I had some issues with GPS fix while moving, so I tried to change GPS parameters via AT and after reset I noticed that RAK5205 was no longer receiving downlink join accepted. So now it is stuck in loop of Join request/accept

server: Chirpstack on VPS
Gateway: RPI + RAK2287
Bootloader version: v3.0.2
Firmware version: v3.0.0.14.H.R
Frequency plan: 868Mhz

I have other nodes which work fine.

Here is some output from the RAK5205 terminal:

===============Device Status List================
Board Core: RAK811
LoRa chip: SX1276

Battery Voltage:3.791 V

gps_timeout: 100s
gps_format:GPS take six decimal places
GPS data:
No signal with Satellite.

LIS3DH sensor data:ACC_X: -861mg, ACC_Y: 14mg, ACC_Z: -449mg

BME680 sensor data:
Humidity:43.837 %RH
Temperature:35.57 degree
Pressure:987.27 hPa
Gas_resistance: 45819 ohms
===================List End======================

Here are the channels activated(default):

OK * 0,on,868100000,0,5; * 1,on,868300000,0,5; * 2,on,868500000,0,5; 3,off,0,0,0; 4,off,0,0,0; 5,off,0,0,0; 6,off,0,0,0; 7,off,0,0,0; * 8,on,867100000,0,5; * 9,on,867300000,0,5; *10,on,867500000,0,5; *11,on,867700000,0,5; *12,on,867900000,0,5; 13,off,0,0,0; 14,off,0,0,0; 15,off,0,0,0

I have read on another topic to disable all except of 0,1 and 2, but that is not optimal solution as I need to use all the available channels.

Appreciate your help

Thank you

Hi @sergi_jini ,

Few things you can try.

  1. Can you register again the device on chirpstack as a different device? With different DEVEUI and APPKEY?
  2. Can you disable other channels except 0,1 and 2? Once you joined successfully, other channels should be enabled automatically.

Hello @carlrowan,

I deleted the node and created new one in chirpstack with different DevEUI and APPKEY. Then provisioned same in the RAK5205 and restarted device

OK Work Mode: LoRaWAN
Region: EU868
Send_interval: 20s
Auto send status: true
Send_interval work at sleep
MulticastEnable: false
DutycycleEnable: false
Send_repeat_cnt: 1
Join_mode: OTAA
DevEui: 65333D077596F676
AppEui: 65333D077596F676
AppKey: CA077980A64BA9D7B534A52A0BEC875B
Class: A
Joined Network:false
IsConfirm: confirm
AdrEnable: true
EnableRepeaterSupport: false
Current Datarate: 5
Primeval Datarate: 5
ChannelsTxPower: 0
UpLinkCounter: 0
DownLinkCounter: 0

Device is still in Join loop

I also noticed the tag * timing:“DELAY” in JoinAccept - is this a clue for the root cause?

I have also tried disabling the channels you asked, but no success (I tried from boot mode just in case)

AT not support.

Btw, what should be the MAC version for RAK5205?

I want to mention also that I have installed the RAK5205_v3.0.0.14.H.R Boot+App.hex from RAKwireless Downloads because flashing bootloader (withSTM32CubeProgrammer) and then firmware separately (via RAK Device Firmware Upgrade Tool) did not work for me. Perhaps this RAK5205_v3.0.0.14.H.R Boot+App.hex is faulty and does not listens to RX properly?

Hi @sergi_jini ,

To disable the channels, you should use at+set_config=lora:ch_mask:8:0

MAC version is 1.0.2.

If you upload this RAK5205_v3.0.0.14.H.R Boot+App.hex via STM32CubeProgrammer, it already contains the application FW so it should we working already. No need to upload another one via RAK DFU Tool.

Btw, what is the gateway you are using? Is the chirpstack built-in? In local server or cloud?

I am not sure on what timing: "DELAY" means. But it is still coming from ChirpStack. The issue can arise from the interface of Chirpstack to Gateway. Or Gateway to Device. Or can be on those individual components ChirpStack, Gateway or Device.

Do you have other device that can successfully join to the ChirpStack you are using?


Still getting Error.

OK * 0,on,868100000,0,5; * 1,on,868300000,0,5; * 2,on,868500000,0,5; 3,off,0,0,0; 4,off,0,0,0; 5,off,0,0,0; 6,off,0,0,0; 7,off,0,0,0; 8,off,867100000,0,5; * 9,on,867300000,0,5; *10,on,867500000,0,5; *11,on,867700000,0,5; *12,on,867900000,0,5; 13,off,0,0,0; 14,off,0,0,0; 15,off,0,0,0
OTAA Join Start…
[LoRa]:Join retry Cnt:1
[LoRa]:Join retry Cnt:2

yes I have other nodes which are working fine. Even this RAK5205 worked fine until few days ago it started to behave like this. I have reinstalled bootloader / firmware several times already.
Note that I can only install bootloader+firmware hex - 1 file (I am aware it contains boths and no need for anything else)

I am not able to install separately bootloader (only bootloader) and then firmware (there are separate bin files available as well) - because it is stuck at firmware install stage.

Ok. Seems you cannot change the channel config if Join is ongoing.
Eventually I was able to disable all but 0,1,2

LIS3DH init OK.
OTAA Join Start…
OK * 0,on,868100000,0,5; * 1,on,868300000,0,5; * 2,on,868500000,0,5; 3,off,0,0,0; 4,off,0,0,0; 5,off,0,0,0; 6,off,0,0,0; 7,off,0,0,0; 8,off,867100000,0,5; 9,off,867300000,0,5; 10,off,867500000,0,5; 11,off,867700000,0,5; 12,off,867900000,0,5; 13,off,0,0,0; 14,off,0,0,0; 15,off,0,0,0
[LoRa]:Join retry Cnt:1

MAC is set to 1.0.2/A


But still same issue

On device side:

OTAA Join Start…
[LoRa]:Join retry Cnt:1
[LoRa]:Join retry Cnt:2
[LoRa]:Join retry Cnt:3
[LoRa]:Join retry Cnt:4
[LoRa]:Join retry Cnt:5

You are right @sergi_jini . I forgot to tell you that you need to disable the automatic sending so you can configure the modes easily.


Btw, I am not really sure what’s happening. Can you try to disable the automatic sending then assume that the module is a RAK811 and just manually connect it to TheThingStack like on this guide? You will manually try to issue at+join request.

Hello Carlrowan,

Sorry I was traveling, could not reply.
I have moved to another city and device has joined here successfully. Might be the issue with the distance/coverage with the other gateway (~4km)?


Quite possibly, the one of your screenshots that has such information seems to show SF7 was used, which is the shortest range mode. It would have been useful to expand some of the uplink signal reports and see both what spreading factor was used, and what the RSSI and SNR of the node at the gateway were. If that was marginal, it’s quite possible the return message didn’t get back to the node.

1 Like

Hi @sergi_jini

As @cstratton said, if you moved at 4km, that can be a factor. Though I am thinking why you were able to send the uplink but not the RX join downlink.

I mean I was away from Gateway by 4km. I was not moving while trying to Join.
Now I am in another sity with more gateways around and Joined successfully.


1 Like

That’s why it would have been interesting to see the RSSI & SNR of one of the join request uplinks. If it was at all marginal, it wouldn’t be surprising that the response - especially at SF7 - might not get through. The gateway’s receiver may simply be better, or the node may be in a noisy local environment, have a noisy power supply, etc.

The appropriate spreading factor to use for join requests is something of a dilemma. Probably a scheme should make at least some attempt using the slower, longer range high spreading factors up to the limit of whatever applicable radio regulations permit - eg, SF12 in some places, SF10 in others where there are packet duration limits.