Does anyone know about the latest efforts by the Alliance to standardize FOTA and Multicasting? We have heard that both are being actively discussed and may even be released in the next few months.
We are currently using the Lora Server for all our experimental setups and have been very happy with the results so far. However, our applications (AMI) requires FOTA for LoRa to be a viable alternative to existing technologies.
Hopefully this is an area the Project can take up sometime in the near future. Maybe it is already on the way
Iāve just merged multicast support into the master branch of LoRa Server. Support for multicast support for LoRa App Server will be merged later today or tomorrow into the master branch
This will be the first ābuilding blockā to also work on support FUOTA. If one of you is interested in testing multicast support, please let me know.
Hi, is this included in the last docker images release or I need to run it from sources? I am currently using your docker-compose install method.
I have xDot and mDot modules which has a FOTA firmware example but waiting for the required external SPI Flash memory chips āAT45DB161E-SSHD-Tā to start testing.
Hi brocaar,
Iām working on a work project that would benefit from multicast (rather than peer-peer).
Is it possible to use/send multicast from a node (mDot) to other mDots? Iām guessing this would not work with channel hopping, unless a multi-channel gateway was used?
I think the only way for nodes to multicast is to have multi-channel gateways all connected through some network/backbone?
Looking forward to hearing back
Multicast is from network-server to multiple devices. Device to devices is not standardized. Or you could send from a device to the end-application (uplink) and then let the application schedule a multicast downlink.
Do you believe that the code could be modified to allow node -> node multicast?
Do you think (there is any chance) the above could be done without scheduling (instant/real-time)?
I tried to compile the example using mbed-os 5.7 (5.7.7), but ātimeSinceLastFragā was not defined, so I commented-out the conditional definition:
//#ifdef FOTA
int32_t timeSinceLastFrag();
//#endif
and it worked.
We (Arm) have published the latest version of the firmware update client for Mbed OS, which is on-spec with the now ratified LoRa Alliance specs. In addition Iāve added a script that uses loraserver for an actual update: https://github.com/armmbed/mbed-os-example-lorawan-fuota
(Although only now I see that @brocaar already implemented the multicast spec, so someone should fix my script ).
Since the first time Iāve seen this, Iāve had to wonder how this is feasible on lorawan, considering the duty cycle restrictions that exist. It just would take a long time with large delta changes of the binary.
I had a thought of doing this by just entering a plain lora mode and simply broadcasting segments.
@txf, Letās take SF9, 125 KHz on EU868. Delta update size of 8K, 5% packet loss. Max payload size is 110 bytes with 595 ms. Tpacket. This gives 82 packets required (10% redundancy packets used) for a total of 48 seconds transmission. Duty cycle at 869.525 MHz is 10%, measured per hour, so well within the 6 minute limit. Add some prioritization in the mix for the downlink queue to not avoid missing RX2 windows, and youāre maybe looking at 2 minutes for sending the update. During this time thereās no transmission from the end-devices that are updated, so no duty cycle limitations in place there. Other bands (US915) have even less issues, can use dedicated update band, and only need to adhere to 400 ms. dwell time between packets.
I had a thought of doing this by just entering a plain lora mode and simply broadcasting segments.
Which is very similar to what weāre doing. Weāre also broadcasting, and as fast as possible, but with additional security features and forward error correction in place. Also in a standardized manner, which is important if you want to deploy this on other networks.
Now that ARM has implemented this feature in their Mbed stack, Iām looking forward to finally integrate FUOTA into LoRa App Server. Iām looking forward to feedback on how you think you would use this feature.
So far, Iām thinking of adding support for the following options:
Upgrade an individual device. E.g. you would click on the device within the web-interface and upload the new firmware which would trigger a FUOTA process for this device only.
Upgrade all devices within an application. E.g. you would click on an application and upload the new firmware. This would then trigger a FUOTA profess for all devices within the given application.
Awesome, Iām trying to use multicast to update groups of end devices, but I need delta update due to my large firmware. Could delta updates be considered in the LoraServer FUOTA? Like, one way to send all the firmware in case of critical failure, and another way to send only the patch.
I believe LoRa App Server should not be aware of what it is sending, e.g. a full update, delta update, ā¦ This is application specific and also depends on what the application and / or bootloader of the device supports. So in short, yes, you would be able to use the FUOTA to do delta updates, given that your device supports this
