RAK5205 Join Accepted not received

sergi_jini · August 7, 2021, 4:21pm

Hello,

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
MCU: STM32L151CBU6A
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):

at+get_config=lora:channel
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
Sergi

carlrowan · August 7, 2021, 11:07pm

Hi @sergi_jini ,

Few things you can try.

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

sergi_jini · August 8, 2021, 8:33pm

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
RX2_CHANNEL_FREQUENCY: 869525000, RX2_CHANNEL_DR:0
RX_WINDOW_DURATION: 3000ms
RECEIVE_DELAY_1: 1000ms
RECEIVE_DELAY_2: 2000ms
JOIN_ACCEPT_DELAY_1: 5000ms
JOIN_ACCEPT_DELAY_2: 6000ms
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+set_config=lora:ch_mask:0:8
ERROR: 2
BOOT MODE
at+set_config=lora:ch_mask:0:8
AT not support.

Btw, what should be the MAC version for RAK5205?

sergi_jini · August 8, 2021, 8:52pm

Edit:
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?

carlrowan · August 9, 2021, 5:39am

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?

sergi_jini · August 9, 2021, 9:40am

Hello,

Still getting Error.

at+get_config=lora:channel
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…
at+set_config=lora:ch_mask:9:0
ERROR: 80
[LoRa]:Join retry Cnt:1
at+set_config=lora:ch_mask:11:0
ERROR: 80
[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.

sergi_jini · August 9, 2021, 9:53am

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…
at+get_config=lora:channel
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

carlrowan · August 10, 2021, 6:45am

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.

at+set_config=lora:send_interval:0:0

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.

sergi_jini · August 14, 2021, 7:32am

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)?

Thanks

cstratton · August 15, 2021, 12:19am

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.

carlrowan · August 15, 2021, 9:37am

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.

sergi_jini · August 15, 2021, 9:51am

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.

Br

cstratton · August 15, 2021, 2:12pm

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.