Link ADR Rejection received

Issue: ADR command from TTN is getting rejected by RAK 4200

Setup: Gateway RAK 7258.
LoraWan Specification 1.0.2,
Regional Parameters version: RP001 Regional Parameters 1.0.2

Server: TTN

Details: We have a product with the RAK4200 installed. Customer has queried having devices use SF12 for better range performance when product is install further away so I have been investigating why the ADR isnt working.

ADR enabled on the module and network server, but every ADR command gets rejected by the module.

LinkADRReq from gateway:

{
“MHDR”: {
“MType”: “Unconfirmed Data Down”,
“RFU”: 0,
“Major”: 0
},
“MACPayload”: {
“FHDR”: {
“DevAddr”: “260BB54C”,
“FCtrl”: {
“ADR”: true,
“RFU”: 0,
“FPending”: false,
“ACK”: false,
“FOptsLen”: 5
},
“FCnt”: 19,
“FOpts”: [
{
“CID”: “LinkADRReq”,
“DataRate”: 5,
“TXPower”: 1,
“ChMask”: “0x3f00”,
“ChMaskCntl”: 0,
“NbTrans”: 1
}
]
}
},
“MIC”: “234F4A3B”
}

LinkADRAns from gateway:
{
“MHDR”: {
“MType”: “Unconfirmed Data Up”,
“RFU”: 0,
“Major”: 0
},
“MACPayload”: {
“FHDR”: {
“DevAddr”: “260BB54C”,
“FCtrl”: {
“ADR”: true,
“ADRACKReq”: false,
“ClassB”: false,
“ACK”: false,
“FOptsLen”: 2
},
“FCnt”: 42,
“FOpts”: [
{
“CID”: “LinkADRAns”,
“PowerACK”: true,
“DataRateACK”: true,
“ChanMaskACK”: false
}
]
},
“FPort”: 2,
“FRMPayload”: "02 F6 4E 2A 27 8D 2E 3B 3B DF 78 43 "
},
“MIC”: “4C04BA53”
}

Link ADR rejection received from TTN:

{
“name”: “ns.mac.link_adr.answer.reject”,
“time”: “2023-05-23T14:49:59.797819751Z”,
“identifiers”: [
{
“device_ids”: {
“device_id”: “rak-4200-dev-board”,
“application_ids”: {
“application_id”: “neptune-production-v3”
},
“dev_eui”: “60C5A8FFFE7543F0”,
“join_eui”: “AC1F09FFF8684200”,
“dev_addr”: “260BB54C”
}
}
],
“data”: {
@type”: “type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRAns”,
“data_rate_index_ack”: true,
“tx_power_index_ack”: true
},
“correlation_ids”: [
“gs:conn:01H03BPW86AF3NC1QH592GKVDQ”,
“gs:up:host:01H03BPW8DCXBT04EKS8QGXK3E”,
“gs:uplink:01H14HD81BC704SMXZX22EWCE6”,
“ns:uplink:01H14HD81C5DKBR39H40TPQHZE”,
“rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H14HD81BEF6PXEKVC2RE7ZWG”
],
“origin”: “ip-10-100-12-132.eu-west-1.compute.internal”,
“context”: {
“tenant-id”: “CgN0dG4=”
},
“visibility”: {
“rights”: [
“RIGHT_APPLICATION_TRAFFIC_READ”
]
},
“unique_id”: “01H14HD87NHJCJC1XBWJX0NCVC”
}

What i think is the Link ADR request from TTN:
{
“name”: “ns.down.data.schedule.attempt”,
“time”: “2023-05-23T14:49:00.721178935Z”,
“identifiers”: [
{
“device_ids”: {
“device_id”: “rak-4200-dev-board”,
“application_ids”: {
“application_id”: “neptune-production-v3”
},
“dev_eui”: “60C5A8FFFE7543F0”,
“join_eui”: “AC1F09FFF8684200”,
“dev_addr”: “260BB54C”
}
}
],
“data”: {
@type”: “type.googleapis.com/ttn.lorawan.v3.DownlinkMessage”,
“raw_payload”: “YEy1CyaFEQADUT8AAU8Rx5w=”,
“payload”: {
“m_hdr”: {
“m_type”: “UNCONFIRMED_DOWN”
},
“mic”: “TxHHnA==”,
“mac_payload”: {
“f_hdr”: {
“dev_addr”: “260BB54C”,
“f_ctrl”: {
“adr”: true
},
“f_cnt”: 17,
“f_opts”: “A1E/AAE=”
},
“full_f_cnt”: 17
}
},
“request”: {
“downlink_paths”: [
{
“uplink_token”: “ChkKFwoLYW1jLWdhdGV3YXkSCKwfCf/+BQk/EJzh0rgNGgwI3KSzowYQ/tG8lAEg4MLHxoLp+gE=”
}
],
“rx1_delay”: 5,
“rx1_data_rate”: {
“lora”: {
“bandwidth”: 125000,
“spreading_factor”: 12,
“coding_rate”: “4/5”
}
},
“rx1_frequency”: “867300000”,
“rx2_data_rate”: {
“lora”: {
“bandwidth”: 125000,
“spreading_factor”: 12,
“coding_rate”: “4/5”
}
},
“rx2_frequency”: “869525000”,
“priority”: “HIGHEST”,
“frequency_plan_id”: “EU_863_870”
},
“correlation_ids”: [
“gs:conn:01H03BPW86AF3NC1QH592GKVDQ”,
“gs:up:host:01H03BPW8DCXBT04EKS8QGXK3E”,
“gs:uplink:01H14HBE4Q6RRDTNF0YX3CK080”,
“ns:downlink:01H14HBEHHABKBCJ79CP5QM2W8”,
“ns:transmission:01H14HBEHHSPRB6QEBXBP271C5”,
“ns:uplink:01H14HBE4RB72D6VZKCEMAQX96”,
“rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H14HBE4RGR2N43JY1SNY7GC7”
]
},
“correlation_ids”: [
“gs:conn:01H03BPW86AF3NC1QH592GKVDQ”,
“gs:up:host:01H03BPW8DCXBT04EKS8QGXK3E”,
“gs:uplink:01H14HBE4Q6RRDTNF0YX3CK080”,
“ns:downlink:01H14HBEHHABKBCJ79CP5QM2W8”,
“ns:transmission:01H14HBEHHSPRB6QEBXBP271C5”,
“ns:uplink:01H14HBE4RB72D6VZKCEMAQX96”,
“rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H14HBE4RGR2N43JY1SNY7GC7”
],
“origin”: “ip-10-100-5-56.eu-west-1.compute.internal”,
“context”: {
“tenant-id”: “CgN0dG4=”
},
“visibility”: {
“rights”: [
“RIGHT_APPLICATION_TRAFFIC_READ”
]
},
“unique_id”: “01H14HBEHHXNPD5QZYDDVK2WMT”
}

Welcome to RAK forum @swAlphaMicro ,

Can you confirm if the RAK4200 has the latest firmware and the ADR is configured to the module? Also, SF12 cannot be forced by the user if the ADR is enabled (it will be based on SNR value).

Hi Carl,

Thanks for the response. The RAK4200 is using V3.2.0.14.beta4. AdrEnable is confirmed as true.

I have a device set at SF7 and am trying to enable the ADR to increase this value by putting the device further away from the closest gateway but I am still getting the same “Link ADR rejection received”.

Hi @swAlphaMicro ,

It might be a good idea to update the firmware to 3.2.0.16.

I can’t think of other things why it will be rejected. Can you confirm if the LoRaWAN version of your LNS is 1.0.2? RAK4200 doesn’t support v1.0.3.

I’m getting this error on a rack7289?

“ADRACKReq”: false,
“ClassB”: false,
“ACK”: false,

need some help

my end device is as923 and my gateway is on 923 setting 1.

I believe end device is v1.0.3

I’m in Australia on ttn on 915-928 plan

Welcome to RAK forum @TommyAUC ,

Maybe you can create a new topic if your situation is not specific to LinkADR. Also on that new topic, please share more info on the errors you encounter.

Having false class B, ADRack and ACK are not actually errors. In addition, what device do you use and what LNS? Screenshots are always helpful.