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.
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
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.
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
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?
Nagajans said:I tried using multicast by subscribing all targets to the group address0xC000.
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.
Nagajans said:I then added this group address to the receiver target list in the distributor.
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
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?
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
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
Okay, I understand. Is there a way to issue all these commands from a smartphone instead of using shell commands?
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).
I=60 ms (SEG_INT_STEP=0x05), 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
Nagajans said:Is there a way to issue all these commands from a smartphone instead of using shell commands?
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.
Hi,
Sure. I am checking with the teams and will update you shortly.
-Priyanka
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