Setting ADR in RN2903

Devices
#1

Hi, we are using rn2903 module with the last firmware (rev. 1.0.3). When sending the configuration parameters, one of them is “mac set adr off” the module reponds “ok”, but the first message that arrives at the server comes with “adr :false” and the following with “adr: true”. Should I configure the adr every time you send a message?.

Also, to what lorawan specification (1.0.0/1.0.1/1.0.2/1.1.0) and regional parameters revision (A or B) does the latest firmware (1.0.3) comply? To which does the 0.9.8 firmware version comply?

regards.

#2

I believe what you’re experiencing is a bug that I reported in May to Microchip. The device has ADR turned off in the beginning (and 72 channels enabled by default). After the first uplink, LoRa Server will re-configure the active uplink channels on the device (e.g. 0-7). The RN firmware then does not only re-configure the channels, but automagically turns on ADR.

Microchip support case 00226470:

Following the LoRaWAN specs, a node for the US band should start with all channels enabled. In case the network is operating in hybrid mode (e.g. only channel 0-7 are used), the node will hit one of the active channels eventually, after which the network can turn on the appropriate channels on the node, but issuing one or multiple LinkADRReq mac-commands (the same mac-command which is used for adaptive data-rate).

When turning off ADR (mac set adr off) and performing the OTAA as described above, I’m able to join the node in a couple attempts. I validated that ADR is still turned off. Now I send a couple of uplink data frames, so that my network-server can reply with the LinkADRReq to reconfigure the channels on the node.

When this LinkADRReq is received, the channels active on my network are indeed the only channels that are turned on on the RN2903A node. However, suddenly ADR is also turned on on the node.

This should not happen, as this indicated to the network that it is able to control the data-rate of the node, which should only happen on static devices. Channel re-configuration through LinkADRReq should always work regarding ADR on or off.

sys reset
RN2903 0.9.8 Feb 14 2017 20:17:03
mac set adr off
ok
mac get adr
off
mac get ch status 8
on
mac join otaa
ok
denied
mac join otaa
ok
denied
mac join otaa
ok
denied
mac join otaa
ok
accepted
mac get adr
off
mac get ch status 8
on
mac tx uncnf 1 AA
ok
mac_tx_ok
mac tx uncnf 1 AA
ok
mac_tx_ok
mac tx uncnf 1 AA
ok
mac_tx_ok
mac tx uncnf 1 AA
ok
mac_tx_ok
mac tx uncnf 1 AA
ok
mac_tx_ok
mac tx uncnf 1 AA
ok
mac_tx_ok
mac tx uncnf 1 AA
ok
mac_tx_ok
mac tx uncnf 1 AA
ok
mac_tx_ok
mac get ch status 8
off
mac get adr
on

This case has been opened May 5th 2017 and is still open without any updates :frowning:

I’m not 100% sure, but I believe that Microchip once mentioned to me that they implemented the LoRaWAN 1.0.1 specification (rev A). For now this does not make any difference in LoRa Server. The information is collected, but there is no different behavior. However it is going to make a difference when LoRaWAN 1.1 is implemented in LoRa Server.

1 Like
#3

Thank you @brocaar . Can i share this response in TTN for same question?
Setting ADR in RN2903node in TTN
.Regards.

#4

Yes, of course you can share this :slight_smile:

#5

Hi All,

We have the same problem. Did the microchip answer the questions? Has anyone managed to solve it? We are using firmware 1.0.3 AU.

Thanks.

#6

No, they didn’t. I suggest you also report this as an issue to them. The more people that complain about this, the better :slight_smile:

1 Like
#7

Ok I’ll do it! Thank you!

#8

Hello @brocaar ,

I came cross your post here. I wonder if there is any way to fix the DR in server configuration for each channel supported? I could not find anywhere in the documents mentioning DR. I believe the ADR and DR problems for Microchip RN2903 is somehow related. The server will not only reset the ADR but the DR as well.

Thanks. I hope this is the right place to post this question.

#9

No this is not possible.

#10

They’ve since released v1.0.5 which fixes the ADR issue but I cannot get join to reliably work now. Reverting back to 1.0.3.