RAK4200 OTAA Join Request for AS923 uses wrong channels and CFList not being used

Issue: Join request is not being initiated on Channel 0 or 1 as per specification

Setup: RAK4200 version:3.2.0.14
at+get_config=lora:status
OK Work Mode: LoRaWAN
Region: AS923
MulticastEnable: false
DutycycleEnable: false
Send_repeat_cnt: 1
Join_mode: OTAA
DevEui: 60C5…1D0A
AppEui: 60C5…4200
AppKey: 60C5…4200
Class: A
Joined Network:true
IsConfirm: unconfirm
AdrEnable: true
EnableRepeaterSupport: false
RX2_CHANNEL_FREQUENCY: 923200000, RX2_CHANNEL_DR:2
RX_WINDOW_DURATION: 3000ms
RECEIVE_DELAY_1: 1000ms
RECEIVE_DELAY_2: 2000ms
JOIN_ACCEPT_DELAY_1: 5000ms
JOIN_ACCEPT_DELAY_2: 6000ms
Current Datarate: 2
Primeval Datarate: 2
ChannelsTxPower: 0
UpLinkCounter: 0
DownLinkCounter: 0
Server: Chirpstack (Private)

Details:
When RAK4200 set to region AS923 does OTAA join request, it is using any of the 8 channels that it has available to it. My understanding is that the Join request should only be done on channel 0 or 1 as per the specification as these are the only guaranteed frequencies under AS923

For example, here is join request at 923.6MHz

Some additional information.

I have checked that Chirpstack is sending the CFList to the RAK4200 with the Join Accept, which it is.

I have also compared this with an Multitech xDot using mbed with the Semtech Lorawan stack.
Before the OTAA join the xDot is showing just the 2 join channels, 923.2Mhz and 923.4Mhz.
After the join accept, the xDot is showing 5 more channels as per the CFList message sent from Chirpstack with the join accept.

With the RAK4200, if I do a at+get=lora:channels before the join, it shows 8 channels already assigned. This is definitely not correct.

Hi @John_NZ Yes, this is a “bug” that all channels are defined. To propper operate you need to close all other channels, only 0 and 1 by the specification should be opened. The dev team will fix this in the next FW release.

@velev, thank you. Also the other channels should be set as per the frequencies in the CFList data (if it exists) in the Join Accept packet, do you know if this is the case already?

@velev I have been checking on whether the RAK4200 stack is honouring the CFList packet.
I have turned off channels 2,3,4,5,6 & 7 and then done a join.
After the join, channels 8,9,10,11 & 12 are turned on and have the channels as per the CFList

For example, after join I see this

at+get_config=lora:channel
**OK * 0,on,923200000,2,5; * 1,on,923400000,2,5; 2,off,923600000,2,5; 3,off,923800000,2,5; 4,off,924000000,2,5; 5,off,924200000,2,5; 6,off,924400000,2,5; 7,off,924600000,2,5; * 8,on,923600000,0,5; * 9,on,922200000,0,5; *10,on,922400000,0,5; 11,on,922600000,0,5; 12,on,922800000,0,5; 13,off,0,0,0; 14,off,0,0,0; 15,off,0,0,0

I then monitored the gateway packets while sending from the RAK4200 module and I do see it cycling through the channels that are turned on.

However, after about 10 or so sends, I see that several sends from the RAK4200 module are not being seen by the gateway.

I then check the channel assignment and I see that channels 2,3,4,5 & 6 have been re-enabled

at+get_config=lora:channel
OK * 0,on,923200000,2,5; * 1,on,923400000,2,5; * 2,on,923600000,2,5; * 3,on,923800000,2,5; * 4,on,924000000,2,5; * 5,on,924200000,2,5; * 6,on,924400000,2,5; 7,off,924600000,2,5; 8,off,923600000,0,5; 9,off,922200000,0,5; 10,off,922400000,0,5; 11,off,922600000,0,5; 12,off,922800000,0,5; 13,off,0,0,0; 14,off,0,0,0; 15,off,0,0,0

Obviously this is the reason I am not seeing the activity on the gateway from this point on for many sends as the gateway is not listening to all the frequencies in channels 3,4,5 & 6

I think that is also a bug with the stack.

Thank you for this feedback. I will inform the dev team of this also. Your input is appreciated.