Hi, first thanks for the great software.
I’ve been using your server with some success but have run into issues with confirmed messages.
If sending confirmed messages from the lora-server to an end-device, then if the end-device replies with an ACK faster than around 9 seconds then everything works, but if it takes longer than that then the server doesn’t acknowledge the next message. If the end device is also using confirmed up messages then the server never acknowledges any subsequent message while also attempting to resend the data.
In the LoRa spec the only reference I can find to any times is the ACK_TIMEOUT which seems to only apply to end-devices receiving a frame with the ACK set within that time.
In the details timing section (sect. 18) it says that the end-device may transmit an ACK at “its own discretion” and doesn’t specify a time limit.
I’m just wondering if I’m missing something in the spec or if the server behaves differently, or if possibly there’s a bug in the lora mac stack I’m using (lmic on arduino for reference).
I also did some quick tests on an mDot and had some similar issues.
Also for reference the payload is the same each time.
Here are the results of my basic tests.
Down in this case refers to messages from the server to the end device.
Up refers to messages from the end-device to the server.
Down: Unconfirmed
Up: Unconfirmed
Delay: ~10 sec
Result: Good
Down: Confirmed
Up: Unconfirmed
Delay: ~10 sec
Result: Good
Down: Unconfirmed
Up: Confirmed
Delay: ~10 sec
Result: Bad. Alternates between: receiving data with ACK set, and not receiving any data with ACK not set
Down: Unconfirmed
Up: Confirmed
Delay: ~8.2 sec
Result: Good. Receives data each frame with ACK set
Down: Confirmed
Up: Confirmed
Delay: ~10 sec
Result: Bad. After receiving one frame with data and with ACK set, all following frames have no data and no ACK set, however frames get passed onto application
Down: Confirmed
Up: Confirmed
~8.2 sec delay
Result: Good. Each frame contains data with ACK set