I am trying to use nodes (STM32WL) in Class-B to receive commands from the server periodically and the node responds to these commands with a regular Class-A uplink. If another message is queued, it is sent in the reception windows of the response Class-A link, as usual. If the node receives another message, it will respond to it starting another Class-A link, with other reception windows, with another command, with and other response in Class-A, with other… a loop to flush the queue (if any problem occurred), definitively.
In this application, and if some messages are queued, a Class-B message can trig that the node can receive multiple messages and flush the queue. That is good and that is what I looking for.
I queue a message with ACK=true (I am using MQTT) and other messages are previously queue (for example, 5 previous messages), the network server assigns the next ping-slot free after the last package that is queued (the message will be sent in the 6th “128-seg” cycle).
If any communication problems occur in a Class-A link (node Not received ACK, retransmission, CRC invalid, whatever…) and the queue will not be completely flushed (for example, only 5 of 6 messages are sent correctly, the last one remains in the queue), the remained messages don’t refresh them Class-B ping-slot delivery time (the 6th message will still wait for 5 “128-seg cycles” before it will be sent in the 6th cycle as it was assigned when the message is created and queued).
The message is sent in his original scheduler ping-slot and the networks-server didn´t release or use the ping-slot that other sent messages left empty (the 6th message waited for 6 cycles to be sent instead it could be sent in the first slot free after the last Class-A link).
This “NON-Refresh” of queued Class-B messages causes that some messages to get delayed a lot and inefficient use of ping-slots, schedulers and time resources.
Would you investigate this issue and find a way to update the delivery time slot of Class-B messages dynamically, please?
Thanks you, @brocaar, for your fabulous LoRa stack.
Yes, there are some optimizations that can be made to the queuing. I’m currently working on reworking some parts of ChirpStack which will hopefully solve some common issues + improving the maintainability (nothing public yet). I’m not sure if I can include this directly, but else it would be a good improvement to make afterwards. In any case, please create your request here: https://github.com/brocaar/chirpstack-network-server.
I have created a new issue in the GitHub repository:
Unfortunately, I think that I can’t propose a request because I haven’t coded in Go before.
I have tried to refresh the queue using the API functions. I copy the queue locally, flush the queue, and put the messages in the queue again. This procedure refreshes the queue and re-assigns the free ping-slots to the messages, but sometimes fails and generates duplicated messages in the queue. I will try to investigate more this way.