We have axioma abp lorawan devices in our network. We use chirpstack v4 eu868 with default settings. I see that the devices send uplinks and the first ones adjust the datarate and power. But after approx 9 unconfirmed uplinks from device it set the adr_ack_req_true and that triggers ns to send downlink with new channels 3,4,5. The device does acknowledge this and the next downlink contains channel 6 and 7. These are also acknowledged by device and everything seems ok. But after 7 unconfirmed uplinks the next uplink sets the adr_ack_req:true and channels are sendt again. Is this normal behaviour? We use mac 1.0.2 1sec.
Yes, this is expected behavior from the ChirpStack side.
This was implemented in:
The reason is that as part of the ADR back-off, the end-device might reset its channel-mask / channel configuration to the default channels. There is no explicit signalling from the end-device to the NS that this happened.
See also (1.0.2 specs):
And (1.0.4 specs):
The most simple solution to handle the case where the device has reverted back to the default channels or all channels enabled (e.g. US915), is to assume that this happened, in which case ChirpStack re-sends the additional channels (NewChannelReq) or re-sets the channel-mask (LinkADRReq).
But after 7 unconfirmed uplinks the next uplink sets the adr_ack_req:true and channels are sendt again. Is this normal behaviour? We use mac 1.0.2 1sec.
This however is not normal I believe. See the After ADR_ACK_LIMIT uplinks (ADR_ACK_CNT >=
ADR_ACK_LIMIT) without any downlink response, it sets the ADR acknowledgment request
bit (ADRACKReq). sentence in the first screenshot.
ADR_ACK_LIMIT is defined as 64, thus only after 64 uplinks without receiving any downlink, the ADRACKReq bit must be set.
Then your (brocaar) previous statement “After the device has acknowledged the NewChannelReq mac-commands, the NS will stop sending these commands to your devices” are not valid anymore?
These devices have before migrating to Chirpstack been connected to the NS Firefly from Digimondo which just send the NewChannelReq once if confirmed by the end device.
Any way to configure to turn this off as all the devices do keep all the channels when doing an ADR-backoff
After the device has acknowledged the NewChannelReq mac-commands, the NS will stop sending these commands to your devices
That is true, until the device sets the ADRACKReq bit again.
Please see the discussion why this was implemented in this topic:
Again, the device should only set the ADRACKReq after ADR_ACK_CNT >= ADR_ACK_LIMIT, which means after 64 uplinks without receiving any downlinks, as any received downlink resets ADR_ACK_CNT. Thus not after 7 unconfirmed uplinks as you describe.
1 Like
The device in question is W1 Axioma water meters which has a default Adr_Ack_limit set to 8 as default (set to uplink data 4 times per 24h, none are sent as confirmed), then at the ninth uplink sets the AdrAckReq = true (then get the NewChannelReq again … and again). Any downlink reset the counter correctly.
Actually, I see now that the 64 is a default, thus it is valid to implement a different value. Maybe for this reason it should be possible it should be possible to disable this behavior though a configuration flag. I need to think about this again.