Hello, I am trying to switch my device from Class A to Class C. It periodically uploads its status to the server. Server sometimes sends a downlink. Downlink must be confirmed.
My questions are marked bold below. Unfortunately I am not able to understand the GO code and would appreciate if someone shares his experience.
After enqueueing Class C downlink, Chirpstack will try to send it immediately through the last best gateway, used for uplink. What is the actual frequency of checking downlink queue?
If it is confirmed downlink and If ack is not received, Chirpstack will try again until the timeout, specified in device profile is expired. How often will Chirpstack retry? For example, my timeout is 10 seconds, how many times Chirpstack will try to send confirmed downlink?
If downlink queue already has an item that is being sent and new item is added, what will happen with the old item? Will it be deleted from the queue?
Unfortunately, I am also not familiar with Golang. If nobody can give you good answers, why don’t you try making some experiments?
If the downlink queue is not locked (i.e. not in range of any RX1 slot), I understood that it will be sent immediately - thus there is virtually no delay.
I don’t know, but perhaps you can try it out? Perhaps you could schedule a downlink and switch off your node? I got this feeling it will not retry on its own, but it will create an event about the downlink having timed out.
Thank you for your answer.
Yes, I am doing experiments to answer my questions, but would be good to get some information shared by people, who had already done it. I will also share my results.
I think what you suggested in not the right way. If node is switched off, it’s session would become invalid and it would have to join again. In this case retry from Chirpstack would be useless. I am interested in case, when node is still in waiting mode but Gateway is busy or network is down for some time. Will Chirpstack retry?
If you just switch off the node after it joined, Chirpstack is unaware that the node is actually switched off. It will have to assume that the node simply did not receive the downlink because of network reasons. So I think you would be able to observe Chirpstack’s retransmission policy this way, as downlinks will still be successfully triggered with the gateway.
What is the actual frequency of checking downlink queue?
For Class-C, the RX2 frequency is used for Class-C.
How often will Chirpstack retry? For example, my timeout is 10 seconds, how many times Chirpstack will try to send confirmed downlink?
ChirStack will not retry. It sends the downlink once and it waits until the timeout. If it expires, an ack event with acknowledged: false is published.
If downlink queue already has an item that is being sent and new item is added, what will happen with the old item? Will it be deleted from the queue?
A confirmed downlink which has not been acknowledged and has not yet timed-out, will block the sending of the next queue items. As soon as a pending downlink has been acknowledged or timed-out (whichever comes first), is will be removed from the queue and the next item will be scheduled. So you can keep adding items to the queue
@brocaar thank you for information.
One more question.
If the message queue is cleared by an API call, what will happen with the item, which is waiting for confirmation?
Hi,
I am facing some issue regarding the DOWNLINK data.
The Sensor is connecting with the Server.
Able to send the Data from Sensor to the Server(UPLINK).
Then trying to receive the data from the Server to Sensor,
But found that, the Downlink is not working.,
Also the frame count is not incrementing.
My Chirpstack version is 3.16.2.
Can you please tell me, how to resolve the issue(Downlink Data)
Quick response will be appreciated,
please do response.
