We are currently testing the RAK3172 module for our Lora end devices. We have ensured that adaptive data rate is turned off on the device and set the data rate to 1 using AT commands. As soon as we join the Lora network and check the data rate, we can see that it has been set back to 0. I would only expect this behavior if ADR is turned on. We are using the RAK wisGATE edge 2 gateway as a Basics station and AWS IoT core for lorawan as the Lora Network server. Changing the data rate after the join allows us to send the packet sizes we need to, but I am curious as to why the data rate would change after joining the Lora network when ADR is turned off.
To a large extent, OTAA is practically linked to ADR, and in the US915 it’s at least briefly forced.
Typically when a node does an OTAA join, the server tells the node exactly which uplink channels it’s actually allowed to use. In some LoRaWAN regions that’s done with the CFlist in the join accept, but there are too many possible US915 channels for that to fit.
Instead, channels in US915 (and probably some others as well) have to be configured by multiple downlink MAC commands, and it turns out that the command that can configure a channel list also has to specify a datarate - in fact, the name of the MAC command is LinkADRReq. Even if you don’t want ADR, a few of these have to be sent after any join to configure the node’s channel map, and regardless if helpful or not, the message format has to specify a data rate.
You could I guess open a ticket with the AWS arguing that the datarate they command should be different, but realistically, if you want to operate in the unusual case of OTAA without ADR, you probably just need to explicitly set the data rate - I might even do it before every transmission if I really wanted to be sure.
Thank you for the reply Chris. We are in US915. I have compared the Join Accept packets that I get for the RAK3172 module to the Join Accept packets I get for a different module and the packets look very different. I am not sure why that would be, I am going to have to dig into this one a bit more to see what configurations I am using. It is not the end of the world for us to explicitly set the data rates, I was just curious why this is happening on this module but not others we have tested.
The DR is not being set in the join accept, but rather in the distinct downlinks that follow which have the LinkADRReq commands (typically at least 2, often in the same downlink) that are intended to configure the channel map, but also of necessity must also set some data rate.
I guess you could make an argument to the AWS IoT team that if a LinkADRReq needs to be sent and is going to be attached to a packet which had the ADR header bit off, then they should fill in the DR for SF that was actually used in that uplink.
But it tends to be easier (and more lastingly reliable) to make your own code do what you want than to get other people to make their code do it, even when you can make a sound argument that your way is the right one.