"Device Profile" and expected ADR behavior

Hello. I’m replacing TTN and the default RAK 7244P (on an RPI) software with chirpstack. All is going reasonably well so far except for an issue (seemingly) having to do with ADR.

I have 2 devices based on Seeed lora-e5, running source version 2.4 of lorawan (LoraWAN 1.03/RP1.03) from ST. In Chirpstack, I’ve created an application and a device-profile for these 2 devices, specifying min and max DRs of 0 and standard ADR. For testing I have one device quite near (-49db DR3/SF7) and another 1/4 mile away with an rssi of -109, using the same, ADR-assigned DR3/SF7. Using the old GW and TTN, the remote device ended up DR0/SF12. When I use only the remote device (i.e. power off closer device), it gets assigned SF10, but never SF12. In this mode (SF10), I’m getting lots of “frame received with invalid CRC” messages. i realize that based on the spec, SF10 should work, but I’d like to force SF12 - preferably without modifying endpoint firmware.

My question is this:
Is it normal for all device of a given “Device-class” to be treated as a unit in terms of ADR?. And if so is the recommended workaround to create device-profiles “per device?”

Thanks in advance for any insight you can provide.

Please note that the ADR algorithm never decreases the data-rate of the device, it only increases the data-rate if possible. To force devices on SF12, you might want to implement a custom ADR algorithm and use that as a plugin.

1 Like