Hi Brocaar,
looking at the lora-app-server code (/internal/api/application_server.go) it seems that when there is an ack in an uplink message the lora-app-server fetch a pending request from the sql DB using DEVUI.
My question is : if there is more than 1 frame stored as confirmed for a given DEVUI, how can be fetched the corresponding frame?
From my understanding it is always take the first one stored in the DB…am I wrong?
There is only one frame that can be confirmed by a node. In the current implementation, when LoRa Server does not receive an ACK for a confirmed downlink payload, it will resend this payload until it has been acknowledged. So the ACK is always related the frame with status pending: true. The other frames are in the queue to be transmitted.
Thabk you, but…
What is the frequency of retrasmitting ?
What is the maximum number of repetiions?
It re-transmits the pending confirmed downlink on each uplink that does not contain the expected acknowledgement.
Hello, I have some follow up concerns regarding the topic.
When downlink is enqueued it is assigned with FCnt (because it is used during payload encryption, and payloads in queue are stored as encrypted). What happens when after sending this downlink there is no ACK in following uplink? How is it supposed to be resent, as in queue there is already encrypted payload assigned to “used” FCnt.
As I observe when downlink is not acknowledged it is removed from queue with log:
“device-queue item discarded due to timeout”
Could you please share some explanation?
I must admit we still use old 0.23.2 version of loraserver and 0.16.1 of lora-app-server, but similiar problems with downlinks have been observed on the most recent version as well.
This is something you need to implement in your application. When the uplink frame is not acknowledged, you get a negative ACK notification (through one of the available integrations). It is up to your application to decide if you want to re-schedule this frame or not.