Hello,
I currently implement LoraWan for a measurement transmitter equipped with a LSM100A modem, Firmware Version 1.0.3 (with some bugfixes), LoraWan Version 1.0.4, region EU868.
OTAA works well, but with ABP and ADR I made the following observation:
When I activate the device on ChirpStack v4, during the first several transmissions ADR takes place, resulting in DR5/TXP-1dBm.
When I then repower the device after some transmissions (frame counter are stored in non volatile memory) no ADR takes place: The device stays at DR0/TXP13dBm. Shouldn’t the server initiate another ADR cycle since it is aware of the inappropriate settings?
As workaround I now force a AdrAckRequest after every restart of the transmitter, but I’m not sure if this shouldn’t be handled on server side.
If possible, I would try to avoid ABP as you mention that OTAA is already implemented and working properly. ChirpStack (or any other NS) will not be aware of a power-cycle because there is no explicit notification for this. This might be problematic for settings that have been changed with other mac-commands as well.
E.g. NS changes RX1Delay from default 1 to 3 seconds, and RX1DROffset from default 1 to 3. Then device power-cycles and recovers its frame-counters but does not recover the other settings. The result is that the device will no longer be able to receive any downlinks because the NS will use 3 seconds delay for RX1 (and 4 secs for RX2) + it will use a DR offset.
In case of OTAA, the device would re-activate and re-negotiates all settings.