BLE Mesh DFU speed improvements

RE: BLE Mesh DFU speed improvements

Edvin — Mon, 16 Feb 2026 08:06:40 GMT

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

RE: BLE Mesh DFU speed improvements

Jero — Fri, 13 Feb 2026 14:28:12 GMT

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

RE: BLE Mesh DFU speed improvements

Edvin — Fri, 13 Feb 2026 12:29:13 GMT

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