I am not completely sure if this is a bug, but I recently observed a LinkADRReq downlink command with "f_opts": "AzH/AAEG" which decodes to 03 31 ff 00 01 06. Command 0x03 has 1+2+1 = 4 bytes of parameters, but here we have 5. This is consistent with the outer parameters (FOptsLen iirc), but the trailing 0x06 seems to be in excess. Unfortunately it looks like that this somehow causes problems in the RN2483 LoRaWAN controller on my node (kind of buffer overflow, maybe).
Any comments?
Could 06 be another MAC command? For instance DevStatusReq?
Thank you.
You are right, if I understand the spec correctly: “A single data frame can contain any sequence of MAC commands, either piggybacked in the FOpts field […]”.
Seems the bug is in the RN2483 firmware which misbehaves whenever such a telegram is received.
Which version of the firmware is loaded on the module? And what settings at TTN are you using for the device? (LoRaWAN version, Regional Parameters version)
It’s 1.05, i.e. the latest “official”/supported release. TTN settings are LoRaWAN 1.0.2, EU868 with SF9 for RX2, RP001 Rev.B, OTAA. The error occurs with dynamic ADR mode. If I set that option to disabled, no problem occurs – which is evident because the critical downlink telegram is not generated.
I think we are hitting the same issue. @Kater would you be so king and be more specific on how is the problem with rn2483 demonstrated on your end? In our case the radio becomes completely unresponsive until reset using external pin.
I can confirm, that disabling ADR on RN2483 puts the module into correct state.
Previously:
after sending “mac tx uncnf” a response “ok” was received and packet sent, then the module went into inresponsive state on uart interface (never received the second mac_tx_ok response)
Now with ADR explicitly disabled:
after sending “mac tx uncnf” a response “ok” was received and packet sent, then after about additional 8 seconds the mac_tx_ok is received and all works correctly further on
Only tested with 1.0.5 fw
Are you using 1.0.5 as well? Could you test with older firmware versions?
From memory (would have to search my notes which I have not handy atm): Joining with ADR disabled lets the Stack send a single downlink message, which is ok for the RN2483 radio module. Enabling ADR and having a good connection lets the Stack send a combined downlink message with the additional LinkADRReq command to modify the radio parameters (i.e. a changed spreading factor). The combination of more than one downlink action seems to be the problem for the RN2483.