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

[Nagajans]

We evaluated the BLE Mesh DFU performance on the nRF52840 and observed that transferring a 342 KB binary took approximately 36 minutes. This aligns closely with the documentation provided on Nordic’s website. We would like to confirm whether the DFU speed for the nRF54 Series remains around ~1 kbps, or if higher throughput can be expected.

[Priyanka]

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

[Nagajans]

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.

[Priyanka]

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.

[Nagajans]

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?

[Priyanka]

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:

1. 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.
2. 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