Is ADR Broken in V3? A migrated device no longer works

TTN V2 to V3 Upgrade Migrating Devices to V3
1

I migrated a (working) device from V2 to V3, changing the key in V2 so the device can’t join the V2 network. It successfully joins V3, but fails to uplink data, with the error in the console “Link ADR rejection received.”

I note in the JSON that two “acks” are true, this leads me to think that the node acknowledged and did not reject the ADR request.

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

Does the V3 implementation use different data rates than V2 did (for the US band plan)?
Is there a packet decoding tool that will enable the decoding of the ADR requests and acks (perhaps the Wireshark decoder is nearly ready)?

The device in question uses the Adafruit Feather M0 LoRa module with code built in the Arduino IDE with the MCCI LoRaWAN LMIC library version 3.1.0 (supports LoRaWAN 1.0.2/1.0.3 Class A devices) and works fine on V2, and while it joins V3, it cannot uplink data successfully, it appears.

The Feather board is just for prototyping. My colleague is porting the functions of this project to a different module based on an ST Micro SOC, using the libraries provided by ST, and is also experiencing ADR issues, though in his case, the module only operates at the slowest data rates, despite being in the same room as the V3 gateway.

Interestingly, the stack enqueues two separate ADR requests, both within the same second (timestamps are identical to the second) and it’s not clear why it doesn’t simply choose to enqueue a single request with the settings it really wants. The first request is:

"data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRReq",
    "data_rate_index": 2,
    "channel_mask": [
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false
    ],
    "channel_mask_control": 7,
    "nb_trans": 1
},

and the second one is:

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

The first request seems to tell the module that it cannot use any frequencies at all, and the second one indicates that half of them are usable. Does this lend any insight?

2

I have the exact same symptoms with mcci-catena/arduino-lmic v4.0.0 in the EU868 region. I originally thought it was a bug since v4.0.0 was released only a few days ago.

Another weird thing I’m experiencing is that the event repeats itself many times in a row.

image

The only workaround I’ve found so far is to disable ADR.

3

I am seeing the Link ADR rejection in AS923 as well.

4

With what device and which LoRaWAN library?

5

How are all your troubling devices defined in V3, which LoRaWAN version are they configured for?

Have you tried if defining a different LoRaWAN version makes any difference here?

6

I am using the semtech loramac-node stack. Device is a custom one, but is based on the Murata CMWX1ZZABZ. I also get the following data in my logs on the console (I removed the identifying information):

name": "ns.mac.link_adr.answer.reject",
  "time": "2021-06-09T01:03:15.318512111Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "...",
        "application_ids": {
          "application_id": "..."
        }
      }
    },
    {
      "device_ids": {
        "device_id": "...",
        "application_ids": {
          "application_id": "..."
        },
        "dev_eui": "...",
        "join_eui": "...",
        "dev_addr": "..."
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRAns",
    "data_rate_index_ack": true,
    "tx_power_index_ack": true
  },
  "correlation_ids": [
   ...
  ],
  "origin": "ip-10-102-14-168.ap-southeast-2.compute.internal",
  "context": {
    "tenant-id": "..."
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ",
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "..."
}

As far as I know the stack supports 1.0.4, and I have tried both the MAC V1.0.2 and V1.0.4 in the TTN console with the same results. I have set the frequency plan to “Asia 923-925MHz” and am using OTAA. There aren’t any “Factory Preset Frequencies” listed, but I’m pretty sure that is for ABP only.

If I look at the raw packet data in my gateway, this is the MAC data which is returned:

        "FHDR": {
            "FCtrl": {
                "DevAddr": "260DD380",
                "ADR": true,
                "ADRACKReq": false,
                "ClassB": false,
                "ACK": false,
                "FOptsLen": 2
            },
            "FCnt": 4,
            "FOpts": [
                {
                    "CID": "LinkADRAns",
                    "PowerACK": true,
                    "DataRateACK": true,
                    "ChanMaskACK": false
                }
            ]
        },

I am however receiving the uplink data fine.

Edit: Also regional parameters is V1.0.2 Rev A

7

Hi,

I think V3 is less flexible about the version of the Regional Parameters in the device setup.

I spent 3 or 4 weeks debugging an OTAA join problem on AU915 with V1.0.2 Rev A using a Heltec CubeCell dev board. It had been working perfectly in V2, but I could not get it to join in V3.

Changing the Regional Parameters to V1.0.2 Rev B fixed the problem. Immediate joins every time.

It might not be a fix for your problem, but trying each of the different regional parameter versions might be something to try.

8

Thanks, that indeed was the issue. I started going through all of the AS923 types (there are a lot of them) and in the end PHY 1.0.2B with the frequency plan “Asia 923MHz with only default channels” no longer has the issue.

9

I’m having the same problem on US915 with MCCI arduino-lmic modified to run on a nucleo-l476rg board with an RFM95W transceiver. I tried changing the Regional Parameters in the end device configuration, but the problem still occurs.
I also had to disable ADR to fix it.

10

The used version of the MCCI LMIC library may be relevant here.

For TTN V3 you possibly may need v3.x or higher (I can’t give you more precise information, I don’t remember the source of the information. 3.x could mean 3.0, 3.1 or even 3.3).

Prior versions handle MAC commands/requests less well (and some possibly not at all), which may play a role in your case.

The issue with customized versions of libraries is that they tend to be not or infrequently updated with changes from their parent library.

11

I’ve been using 3.3.0 to good effect with TTS aka v3 and I can easily fit it in to a ProMini, so there is no reason not to use it.

Not yet tried v4.0.0, big queue of things to check out before that!

12

I have seen far better results with MAC version 1.0.3. I’ll see what else I can learn and will share further.

On a related note: I also heard from a fellow developer that the ADR error also occurs if you choose the wrong country channel plan (in his case, AU versus US).

13

Thank you @jdmedinatobon and @bluejedi for both of your helpful comments and your follow-up @descartes on MCCI LMIC 3.3.0. I have worked with 3.1 quite a bit on V2 but had difficulty with that version on V3. I will try version 3.3.0. I see that version 4.0.0 is now available, if anyone has experience with it (good or bad) I’d love to hear it.

14

@etix Thanks for the heads-up on 4.0.0, I haven’t tried it yet, but it sounds like it may still have issues. I’ll try 3.3.0 and let you know what I find.

15

Just go for v4.0.0. It contains several fixes (documented in the release notes) compared to v3.3.0. (That some issue appears to still exist when using a newer version of the library is not a reason for using an older version where that same issue appears to behave the same).

1 Like
16

Solved with MCCI LMIC 3.3.0 and 4.0.0:

@bluejedi: Thank you. I tried both 3.3.0 and 4.0.0 and both appear to be working (no more ADR rejections!) with a basic example program on V3. Very glad to have a “quick prototyping” platform again, though for production we’re using a different chipset. I’ll try the full application as well, hopefully that has fixed the problem. Your assistance (and that of everyone else who chimed in) is very much appreciated!

Note to moderators: Can the title now be edited to add the word “Solved” or something like that?

17

If you check the icons at bottom of your message you should see option for marking as solved/solution :slight_smile:

1 Like
18

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.