[Please move to correct category if this is the wrong one]
Chirpstack V4.12
Using integrated FUOTA service.
Setup a single device in the FUOTA deployment.
Jobs in the deployment always wait for timeout, even all (here 1 device) have already completed the job?
As shown in the logs, the device is marked as “completed” for each job after 1 minute, but the job still waits for 10 minutes timeout before it proceeds.
Hi,
I’ve had similar behaviour.
I’ve noticed that the “timeout” delay depends on the “Expected uplink interval (secs)” setting in the “Device profile” selected when configuring the FUOTA deployment.
Try to match the expected uplink interval with the effective uplink interval of the device.
Hope it helps.
Igor
I found that as well, but still, why does it always wait for that time.
All devices responded already, and it still waits for the timeout.
Hello, I’m using the same V4.12 with the STM32WL-FUOTA Project(with V1 Package for Synch and Fragmentation).
I have a problem with receiving the Fragmentation. Would you kindly share the configuration you used (also, if possible, in the firmware setup) to have these results?
Fragmentation status request: After Fragment enqueue.
Fragmentation redundancy (%): 10
Fragment size: 48(Calculated by ChirpStack).
On the Firmware side, I tried activating/Deactivating “INTEROP_TEST_MODE”, but the results are the same.
Thank you
I am using RUI3 firmware (not released officially) on a RAK3172 from RAKwireless (STM32WLE5).
Can’t help with STM32WL-FUOTA Project.
In CS V4 my FUOTA setup is like this:
Device Profile Application Layer setup is like this:
On the RAK3172 I have to do no special setup, just make sure that the device is sending enough downlinks to .stay within the 64 seconds timeout I defined in the FUOTA session.
Thank you for your reply. I assume you chose DR = 5 because it supports up to 222 Bytes, but is there a reason for choosing this Frequency? also the Fragment Size? Have you tried Package-V2 and it also worked?
I work in the EU868, but maybe some frequencies are better than others for the downlink messages.
Frequency depends on your LoRaWAN region. I am using AS923-3, so my frequency is one of the channels used for AS923-3.
DR5 was chosen for the payload size and speed, it depends if all your devices are in good reception to gateways. You might need to lower DR for larger range.
RUI3 supports only FUOTA V1.
Hi again, responding to your question, as you are using the RAK3172(uses the STM32WL-Package with V1), if you check AN5554(FUOTA Note from ST) on page 10, you’ll find this note:
hence we should develop this callback in the middleware of the FragmentationDone function, but what I would want to ask @brocaar if there is a way to mange with the CS-FUOTA server this property protocol(something like if the End-Node send an uplink message on port 140 with the CRC32) then the server understand that the transfer is complete?
I also want to test the V2 and see how it does.
AN5554(LoRaWAN Firmware update over the air with STM32CubeWL )
Has your FUOTA campaign been completed(the firmware has been swapped to the new one)?
My Node receives all the downlink packets, waits until the timeout, then switches to Class-A, but with the old firmware runs!!.
