Want to know the speed of the nrf54 series device firmware update

RE: Want to know the speed of the nrf54 series device firmware update

Priyanka — Fri, 03 Oct 2025 08:36:18 GMT

Hi,

In the case of Thread, there is no single unified way as to how DFU can be done. For example Matter defines it's own Matter OTA way, though customers may implement something proprietary on top of IPv6.

In general the throughput on Thread highly depends on the used communication scheme e.g. UDP/TCP, strategy on confirmation and packet sizes, topology of the network etc.

For basic usages we would say it could be between 8kB to 11kB per second.

-Priyanka

RE: Want to know the speed of the nrf54 series device firmware update

Priyanka — Wed, 01 Oct 2025 10:48:41 GMT

Hi,

Sure. I am checking with the teams and will update you shortly.

-Priyanka

RE: Want to know the speed of the nrf54 series device firmware update

Nagajans — Tue, 30 Sep 2025 12:59:16 GMT

Thank you for the information — it closely matches my practical experiments. Could I also get the same timing calculations for Zigbee and Thread? This data is really important for us to evaluate and compare all three wireless technologies.

RE: Want to know the speed of the nrf54 series device firmware update

Priyanka — Tue, 30 Sep 2025 11:48:11 GMT

Hi,

Bluetooth Mesh prioritizes reliability and scalability over raw throughput. DFU is especially heavy because the firmware is split into many SAR segments that share the primary advertising channels with all other mesh traffic. You can take a look here.
Our samples send chunks back-to-back (no gap between chunks).
With default settings,
I=60 ms (SEG_INT_STEP=0x05),
3 network repeats (NS),
~25 ms effective repeat spacing (NI) (incl. controller randomization),
3 multicast rounds (T) with 250 ms gaps
→ a 15-segment SAR message ≈ 3.08 s.
since,
Total time needed for complete transfer of one SAR message to multicast destination is:
- R * (N - 1 ) * I (time for all rounds) + (R - 1) * T (gap between rounds) + LastT
- = 3 (N - 1) * 60 + 500 + 58 = 180 * (N - 1) + 558 ms. For 15 segment message,
- = 3078 ms
Of course there will be additonal minor delays due to processing of each segment
For DFU transfer let’s assume:
- Block Size of 4KB (default)
- Chunk Size of 15 segments
  - Thus, BLOB data size per Chunk Transfer message = 15 * 12 - 4 - 3 = 173 bytes
  - This gives 23.67 Chunks per block, we will assume 25 chunks per block (extra room will account of additional messages sent for starting the Block Transfer, some re-sending of lost chunk, and other setup).
What that means for a ~550 KB image is that,
- Total Chunks within 550KB firmware = ((550 * 1024) / 4096) * 25 = 3437.5 = ~3436 Chunks (SAR messages)
- total time needed for 550 KB firmware transfer = Total Chunks * Time for one SAR transfer (where each SAR message has 15 segments) = 3436 * 3078 ms = 10576 seconds = 2.94 hours.
- It is important to note that total time required to finish DFU to hundreds of nodes will be marginally higher and not linearly higher. Meaning, if it takes 2 nodes to finish DFU in 2 hours, then for 200 nodes it will take, say, 2.5 hours (and not 400 hours). It is hard to compute this theoretically due to nature of the process which involves automatic retries for lost packets.
You can squeeze ~30% more speed by reducing repeats and spacing—at the cost of higher network load. Instead of the default, you can set:
- CONFIG_BT_MESH_NETWORK_TRANSMIT_COUNT=1
- CONFIG_BT_MESH_RELAY_RETRANSMIT_COUNT=1
- CONFIG_BT_MESH_SAR_TX_SEG_INT_STEP=0x03
Also, DFU is supported in the nRF Mesh iOS app (recommended).
[quote user="Nagajans"]Is there a way to issue all these commands from a smartphone instead of using shell commands?[/quote]If you really want to do that, then use Device Manager App and connect to the distributor node (make sure to pair the device first using nRF Mesh App) ... then switch to Device Manager App. That app has a freeform text box mode where customers can manually type those commands and they will be sent to the device. That is really cumbersome though. nRF Mesh iOS app does similar things in the background automatically using Mesh messages and users don't have to type much.

RE: Want to know the speed of the nrf54 series device firmware update

Nagajans — Tue, 30 Sep 2025 07:06:57 GMT

Okay, I understand. Is there a way to issue all these commands from a smartphone instead of using shell commands?

RE: Want to know the speed of the nrf54 series device firmware update

Priyanka — Tue, 30 Sep 2025 06:22:55 GMT

Broadcast updates will be slow by design. Because it won't matter much if they are updating 10 devices or 100 device, Total time required will be more-or-less the same. It is designed on purpose to support update of hundreds of devices with predictability and without loss of many packets.

-Priyanka

RE: Want to know the speed of the nrf54 series device firmware update

Nagajans — Mon, 29 Sep 2025 14:57:51 GMT

I tested broadcasting with a multicast address, but it seems to take longer compared to updating a single device, since the Distributor waits for responses from each target. Is there a way to perform the update without requiring responses, to make the process faster?

RE: Want to know the speed of the nrf54 series device firmware update

Priyanka — Mon, 29 Sep 2025 13:16:55 GMT

[quote user="Nagajans"]I tried using multicast by subscribing all targets to the group address 0xC000.[/quote]

That's correct. Make sure you have subscribed Firmware Update Server, and BLOB Transfer Server model instances on the target devices. It is necessary to configure both for subscriptions.

[quote user="Nagajans"]I then added this group address to the receiver target list in the distributor. [/quote]

You cannot add group address to target list. The target list is still the unicast addresses for the target. The DFU start command becomes different when you want to use the group address. So,

For Unicast DFU transfer, you will use something like this (if your appkey index is 0 and slot index is 0):

mesh models dfd start 0 0

For Multicast DFU transfer, you will use something like this (if your appkey index is 0 and slot index is 0, groupcast address of 0xC000):

mesh models dfd start 0 0 0xC000

Also, you can try using iOS nRF Mesh app to evaluate this (mesh DFU including group transfer). We recently added this feature to iOS mobile app, we don't have exact documentation yet explaining this, but it should be possible to evaluate this on your own by experimenting. It will alleviate a lot of hassle in trying to configure publish/subscribe settings and setting up of the transfer.

-Priyanka

RE: Want to know the speed of the nrf54 series device firmware update

Nagajans — Mon, 29 Sep 2025 11:00:07 GMT

I tried using multicast by subscribing all targets to the group address 0xC000. I then added this group address to the receiver target list in the distributor. After starting the DFU process, it did not work. Am I missing something in this procedure?

RE: Want to know the speed of the nrf54 series device firmware update

Priyanka — Mon, 29 Sep 2025 07:05:36 GMT

This is what I heard from the internal experts:

"Wondering why do they need even faster DFU timing than default timing of unicast (i.e. one to one) mesh DFU transfer? Is customer's ultimate goal is to upgrade just one or two nodes (using unicast DFU) or do hundreds of nodes simultaneously (using multicast DFU) in parallel? Also, is it acceptable for their use-case to have a performance bottleneck (or missed messages) for other command and control mesh messages (such as turning the FAN on or off, or getting temperature reading from the sensor, etc.) when multicast or unicast mesh DFU is in progress?"

-Priyanka

RE: Want to know the speed of the nrf54 series device firmware update

Nagajans — Tue, 23 Sep 2025 13:31:25 GMT

I’m using the default distributor and target sample code without any modifications to the configuration. If I change the default value to 500 or 1000 in the distributor code, will it improve the transmission speed? Alternatively, could you guide me on how to configure the settings to achieve higher transmission speeds?

config BT_MESH_TX_BLOB_CHUNK_SEND_INTERVAL
int "BLOB Client chunk send interval"
default 0
range 0 2147483647

RE: Want to know the speed of the nrf54 series device firmware update

Priyanka — Tue, 23 Sep 2025 12:22:22 GMT

Hi,

Please note that Mesh DFU will be significantly lower compared to peer to peer DFU because Mesh DFU is designed to operate on several nodes in the network at the same time, in background when mesh network is live and operation. This is what I hear from the internal team:

"Bluetooth Mesh DFU is designed to happen in the background. Ideally, our recommendation is to choose as slower speed as their use-case can tolerate. The slower DFU is better for continued network operation (to control the lights for examples) compared to faster DFU operation. Default for sending chunks is to send them as soon as possible once previous chunk has finished sending. Note that each chunk is many bytes long and therefore results in SAR transaction at the transport layer. This means:

For unicast transfer: New chunk message will be sent once previous chunk message has finished. Meaning, previous SAR transfer has finished. The SAR transfer for unicast sending finishes once lower transport receives the full blockack for SAR message, or it fails to receive complete block ack after completing max number of retries.
For multicast transfer: New chunk message will be sent once previous chunk message has finished. Meaning, previous SAR transfer has finished. The SAR transfer for multicast sending finishes once preset number of retries to send all segments are complete.

So, likely customer has evaluated with default settings and they default max trasnfer speed that mesh DFU can achieve for given default SAR related Kconfig options. If network traffic during the DFU is not a concern for their use-case, they can use default settings.

Ideally, it is recommended to keep network traffic low, and keep a gap of 0.5 to 1 second between each DFU Chunk by configuring this setting."

-Priyanka

RE: Want to know the speed of the nrf54 series device firmware update

Nagajans — Tue, 23 Sep 2025 11:56:18 GMT

oh ok, then I observed about 88 kbps throughput during DFU transfer from a smartphone to the nRF52840. To achieve speeds closer to 400 kbps, which specific controller part number would be appropriate?

Given that the nRF54 series uses a multi-core architecture, the bottlenecks present in the nRF52 series should be eliminated. Does this mean we can expect significantly higher transmission speeds with the nRF54 series compared to the nRF52 series?

RE: Want to know the speed of the nrf54 series device firmware update

Priyanka — Tue, 23 Sep 2025 11:37:25 GMT

Please not that it's 50kilo bytes per second, i.e. approx. 400kbps. The nRF connect and DM apps are also displaying the speed in kB/s not kbps when doing dfu with SMP.

Also, for point to point on the 52 series, you may be bottlenecked by the flash memory (each 4k page erase takes about 90 ms during which the CPU will be halted). RRAM allows overwrite without erase.

RE: Want to know the speed of the nrf54 series device firmware update

Nagajans — Tue, 23 Sep 2025 09:34:39 GMT

I tested a point-to-point connection between a smartphone and the nRF52840, and the transmission speed reached up to 11 kbps. Could you please verify and provide clarification on the transmission speeds for both the nRF52 and nRF54 DK boards? This information is very important for our evaluation.

RE: Want to know the speed of the nrf54 series device firmware update

Priyanka — Tue, 23 Sep 2025 09:14:13 GMT

Hi Nagarajan,

The standard throughput over BLE from Mobile app can reach even 50k. I am verifying internally whether for mesh this throughput is significantly lower ?

Regards,

Priyanka