I am testing using some devices which are using mbed-os 5.13 LoRaWAN stack on chirpstack-docker on US915 band. During the test, I found that sometimes the server would report
UPLINK_FCNT_RETRANSMISSION three times in a row once in a while.
Further check, we realize that the device retries to send the same message on the same frame-counter because it failed to receive the first ACK. We did configure the device to send a confirmed message with 3 retries. Our assumption is confirmed by checking on the gateway live lorawan frames
What did you expect?
I noticed in 2017 on this forum thread [Acks for retransmissions of confirmed uplink] that you decided Chirpstack would not send ACK on a confirmed retry uplink with the same frame-counter.
Would you consider enabling option to send ACK for a retransmission, since it is part of mbed-os LoRaWAN stack?
We also have an existing setup where we use the same device and the same mbed-os 5.13 LoRaWAN stack only this time on 868 band and using loraserver-docker <5233d24>.
Using this setup, we don’t have a problem with uplink retransmission. Is there policy difference between those two versions regarding uplink retransmission?
Step to reproduce
Deploy a chirpstack-docker container (in my case I was using US915 band)
Prepare a device that would periodically send a confirmed uplink with 3 retries if it failed to receive ACK from the server.
Wait until the ‘error’ shows up.