You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to section 5.11 of the LoRaWAN 1.1 specification, the network server can change the ADR_ACK_LIMIT and ADR_ACK_DELAY parameter values in the end-device via an ADRParamSetupReq request. This would seem to imply that the end-device persistently stores the configured values in NVM, otherwise they would be lost on the next reboot.
This is currently not the case in LoRaMac-node, where the ADR_ACK_LIMIT and ADR_ACK_DELAY values are stored in MacCtx (memory) only. Would it make sense to move the two values to NVM and if yes, which parameter group?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
According to section 5.11 of the LoRaWAN 1.1 specification, the network server can change the ADR_ACK_LIMIT and ADR_ACK_DELAY parameter values in the end-device via an ADRParamSetupReq request. This would seem to imply that the end-device persistently stores the configured values in NVM, otherwise they would be lost on the next reboot.
This is currently not the case in LoRaMac-node, where the ADR_ACK_LIMIT and ADR_ACK_DELAY values are stored in MacCtx (memory) only. Would it make sense to move the two values to NVM and if yes, which parameter group?
Beta Was this translation helpful? Give feedback.
All reactions