RAK7204 on TTN stack v3 - ADR trouble

End Devices (Nodes)
1

I have a RAK7204 too, given to me to debug/fix (was initially flashed with the wrong firmware).

It’s running on TTNv3 now, but not very well.
I enabled OTAA and ADR on the node, but I see a lot of downlinks, I think basically an ADR request for every uplink (uplink count is now 279, downlink count is 259)

The console logs a “Link ADR rejection received” message.

{
  "name": "ns.mac.link_adr.answer.reject",
  "time": "2021-05-15T07:23:42.104557837Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "rak7204",
        "application_ids": {
          "application_id": "rak7204-bertrik"
        },
        "dev_eui": "323833355F387902",
        "join_eui": "70B3D57ED003881B",
        "dev_addr": "260B940C"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRAns",
    "data_rate_index_ack": true,
    "tx_power_index_ack": true
  },
  "correlation_ids": [
    "ns:uplink:01F5QEHKYET09JDE6Z7V8X3ZFY",
    "pba:conn:up:01F4S0S1VDKJV6PHSBWY4PYEWG",
    "pba:uplink:01F5QEHKXR80ESJWRY0VYZ5B2X",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01F5QEHKYEFY3RY6G3390GDW0X"
  ],
  "origin": "ip-10-100-5-72.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01F5QEHM4RDW9A913J8XS3ASSJ"
}

I’m not completely sure what part of the message causes it to be marked as “ADR rejection”. Apparently data rate is ACKed, tx power is ACKed, then only perhaps the channel mask is not ACKed (this doesn’t become clear from the JSON interpretation).

I configured this node as a LoRaWAN version 1.0.2 device, according to
https://www.thethingsnetwork.org/docs/devices/rak7204/rak7204/
Further, I configured it as PHY v1.0.2 REV A (not completely sure about that) and frequency plan: SF9 for RX2 (recommended setting)

I will try to investigate what is happening exactly. Has anyone looked into this before?

2

Are you using confirmed uplinks?

3

I am using OTAA, with ADR, EU settings. Uplinks are unconfirmed.
Used the same settings as described in RAKwireless Documentation Center

I see that there is a newer firmware version, I’ll flash that and see if there’s any change.

4

Hi, This is NoriAbe from Japan.

I have the same problem on Dragino LoRa Mini Dev (EN) and Multitech Conduit AEP (GW).

What does the message mean?

5

I was planning to see if the newer firmware version would give a different result, but now I can’t even flash a newer firmware version. I find the tools for this a bit “wonky”, they just get stuck with no new firmware being flashed or a clear message about either flash progress or flash error. The device does not work anymore as a LoRaWAN device. I might try again completely from the start, first flashing the bootloader again (need to figure out the boot pin settings again) then the newer firmware on top of that. Haven’t really gotten to that.

I think I do have seen a ADR response with the channel mask ack fields present for other devices. I’m reasonably sure now that the ADR response is the reason for the odd behaviour. For some fields in the JSON shown in the TTN v3 console, if the value is “0” or “false”, the fields and its value are simply omitted.

6

Results do tend to vary :unamused:

I find my ST Link gets plenty of exercise on my Mac but once I have a stable device with a recent firmware I can usually use the download tool on Windows with a reasonable degree of reliability.

Yes, this is a “Very Important Feature” of TTS that won’t be changed even though it requires everyone who parses the JSON coming from TTS to account for missing fields.

7

Since yesterday, after abt 1600 uploads my RAK7204 V3.1.0.12 (TTS CE, OTAA,ADR) shows the same behaviour. Every upload is followed by a download:
“rx1_delay”: 5,
“rx1_data_rate_index”: 5,
“rx1_frequency”: “867700000”,
“rx2_data_rate_index”: 3,
“rx2_frequency”: “869525000”,
“priority”: “HIGHEST”,
“frequency_plan_id”: “EU_863_870_TTN”

I will observe this and if it doesn’t stop I will reset the RAK7204.

1 Like
8

After a “RESET” of my RAK7204 this behaviour stopped. Perhaps there is a relationship between the fast draining of the battery and these downloads?

9

After some considerable effort, I was able to finally flash the RAK7204 again. I used the “old” bootloader, with the “old” firmware updater to install the most recent firmware (v3.0.0.12.H). I could not make it work with the newer updater, I think either the update instructions are invalid, or the most recent updater is incompatible with the most recent version of the bootloader.

The point of this was to see if the LoRaWAN behaviour I saw before persists with the most recent version of the firmware too.

In the console I’m still seeing “Link ADR rejection received”.

The link ADR request looks like this:

“data”: {
“@type”: “type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRReq”,
“data_rate_index”: 5,
“tx_power_index”: 1,
“channel_mask”: [
true,
true,
true,
true,
true,
true,
true,
true,
false,
false,
false,
false,
false,
false,
false,
false
],
“nb_trans”: 1
},

The link ADR response looks like this:

“data”: {
“@type”: “type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRAns”,
“data_rate_index_ack”: true,
“tx_power_index_ack”: true
},

(there is no channel mask ack, so that means it’s implicitly FALSE).

So it appears that it is the channel mask that is rejected by the device.