TL;DR: ABP devices with ADR turned off in the console (for things like TTN Mapping) will need to explicitly set the DR before each uplink. Or you can use a CLI command to tell the Network Server what you want the device to run at.
If you turn off ADR on the console for a device, the stack will send a request to the device to move to the mac-state.desired-parameters.adr-data-rate-index which, if you’ve not set this using the CLI, will be zero aka DR0 aka SF12.
TTS dev staff are aware of the consequential impact for devices that have been set to run without ADR if you are not controlling it via the CLI or the device is not setting it before each uplink and are looking at a solution that will allow anyone turning off ADR in the console to set the desired rate.
So if you have firmware that sets a data rate, it should do so before each uplink. Or you should use the CLI command to set the desired rate. The second is preferable as it means the NS will not schedule a downlink to adjust it.
ttn-lw-cli end-devices set application-id device-id --mac-state.desired-parameters.adr-data-rate-index DATA_RATE_X where X is the DR you want. See ttn-lw-cli end-devices set | The Things Stack for LoRaWAN for details. The parameter mac-state.desired-parameters.adr-data-rate-index is new to the CLI and the docs haven’t yet caught up but it does appear in Adaptive Data Rate | The Things Stack for LoRaWAN
If you are using Blind ADR (as per the Semtech white paper), for now you will get an ADR request when the device uses the scheduled lower DR. Again, the TTS devs are aware of this and we hope to see a “turn off anything ADR” option to facilitate this.
However, I’m told that the OTAA Join Accept structure & MAC channel commands come with some ADR & power settings and it is not in the specification to not set them - so understanding this from the OTAA angle is work in progress for me - but as there are a whole pile of other facilities built in for things like LinkCheck, which you can adjust if you want, both on the console or in the firmware, slotting all this together until further options are available on the console & CLI seems make-work.
Much of the above is linked to the Advanced MAC settings for current & desired - this allows devices with firmware that are in the supply chain or the back of an installers car to start up with what they have and then be tuned on an individual level. If they restart (which they may do, rarely of course) and don’t have the current settings saved, they can be moved to the preferences you have set automagically.
This has many benefits if you have a clutch of devices in an area where one channel is being hammered by the local pirate radio station or if the wet string that connects the internet (aka mobile) is slow, you can adjust things to suit a deployment.