BLE Mesh DFU speed improvements

[Jero]

Hello!
We are trying to integrate Mesh DFU into our project, so we performed some preliminary tests using three nRF52840 DK boards. The results are somewhat discouraging, as the 332315B update currently takes over one hour to complete. We know that it's due to be slow because we are using Mesh, but any improvement would be very valuable.

The setup is as follows:

• Used unmodified samples for the distributor and target.
• One nRF52840 DK acts as the distributor.
• Two nRF52840 DKs act as targets.
• Using nRFConnectSDK 2.8.0
• The firmware is uploaded to the distributor using the nRF Connect Device Manager app.
  
• We follow the procedure described here, and the commands are sent through the RTT Mesh shell.

The results attached show the average chunk send time:

/cfs-file/__key/communityserver-discussions-components-files/4/mesh_5F00_dfu_5F00_target_5F00_log.txt

As you can see in the image, it's around 650ms per chunk.

Additional tests we have performed include:

• Setting CONFIG_BT_MESH_TX_SEG_MAX=32, which made the process slower.
• Enabling CONFIG_BT_CTLR_PHY_2M=y, which appears to have no noticeable effect.

We would like to know if there are any ways to improve the overall update speed. It could be either through configs or any other change you can think of.

Thanks!

[Edvin]

Hello,

Unfortunately, the DFU over the network protocols (Bluetooth Mesh, Zigbee and Thread) are known to be slow. 

In this case, the throughput in Bluetooth Mesh is, as you see, slow. While it would theoretically be possible to increase it somewhat, this is not something that we want, because it would start to truncate the network, reducing the performance and experience of using the devices in the network. 

As you said, the good thing about a Mesh DFU is that the application will run almost the entire time (apart from the application image swap), and the user will not even notice that there was an ongoing DFU (perhaps apart from starting the process).

I assume that the reason you ask is because you are using DFU actively in your development, and you want to test new FWs on the fly. If that is the case, you should consider adding a DFU over BLE approach, which is significantly quicker. The throughput over BLE in general is a lot faster than it is over Bluetooth Mesh.

Best regards,

Edvin

[Jero]

Hi Edvin,

Thanks for the quick answer!

We are actually already using DFU over BLE. We are just evaluating Mesh DFU, with sights on having a more streamlined firmware update process when the devices are deployed, with as little human interaction as possible.

That being said, I think we can live with updates taking this long, but then again, it would be nice if they were shorter :).

Thanks again! We will try tweaking stuff around until we strike a balance between reliability and speed.

Of course, if you have any more recommendations, they are very welcome! 

Our best, 

Jero

[Edvin]

My recommendation is actually to not tweak anything to make it faster. It is done the way it is by design. I am not sure what sort of product you are developing, or what sort of devices that will be present in your network. But as I mentioned, the reason the speed is set as low as it is is because:

1: In general, the throughput in these networks are low

2: If you increase it, you risk blocking other traffic on the network, causing other issues. 

Since there is usually no rush in actually performing a DFU, as long as the application is running as normal in the background, it rarely matters if the DFU takes 45 seconds or 1 hour, after it is started. No human interaction is required after the process is started.

Best regards,

Edvin