Chirpstack FUOTA Server deletes MC-Group before queue finished

Hello,
I’m using the (new) chirpstack-fuota-server project and succeeded wiring it up together with the remaining Chirpstack Stack (based on docker). When doing an FUOTA test, everything works fine until the stepEnqueue(), where the fragments are queued to the Multicast Group. This still completes, but right after enqueuing the final fragment, the server continues to the next step stepFragSessionStatus(), where it waits for the MC-Groups devices to respond to the FragSessionStatusReq command. But at this time, not even a third of all enqueued fragments/packets have been transmitted to the gateways by the network server. So, stepFragSessionStatus() times out and deletes the MC-Group (complaining about not getting a response from all devices) even though there are still a lot of queued and not transmitted fragments left.
Furthermore, the network server pushes the packets (50B, SF12, BW125kHz) in a 2-seconds-cadence, although each of these packets has an airtime of 2.7s, hence causing collisions/drops in the gateway.
How can I control the schedule-time for the fragment-packets, to A) prevent drops and B) to comply with duty-cycle regulations (10%)?
Plus: why isn’t the FUOTA-process wainting for the enqueued MC-items to be processed and fully transmitted?

Thanks!

1 Like

After digging further into the code, I realized that I missed that the FUOTA process actually is waiting. The value of MulticastTimeout as a power of two is the maximum value in seconds to wait (the timeout of the MC session). But actually don’t like the concept, that the application layer has to deal with MAC layer details.

I currently see no feasible option to config/control the multicast-downlink timing in the network server (except by customizing its code).

Please note that this value is also sent to the device, and that the device will terminate the multicast-session after this timeout. Personally I think it makes sense, because you want to avoid that the device stays forever in multicast-mode.