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!