mesh dfu impressions

[AndyM]

Hello

I built the mesh distributor and mesh target samples from  Zephyr 2.6.1 SDK on 2 nRF52840 dev boards

Provisioned them as described in the docs, loaded a DFU image on the distributor using mcumgr over BLE and ran the update 

Here are some comments and questions

1. It's SLOW. The DFU image size is 330K and it took 30 minutes to download it. There were only 2 nodes on the mesh network, the target and the distributor, sitting next to each other. The network I'm evaluating this for  has over hundred nodes spread over a very large territory and my DFU images are larger, about 415K. 

Any suggestions to speed up the process? Is mesh DFU even feasible in my situation?

2. The JSON messages returned from mesh models dfd receivers-get  command on the distributor are too  cryptic

{ 0": { "blob_addr": 0x0004, "phase": 2, "status": 0, "blob_status": 0, "progress": 50, "img_idx": 0 }

Would be nice to see some descriptive information, on the phase and progress i.e "phase: BT_MESH_DFD_PHASE_TRANSFER_ACTIVE"

and "status : 50 out of 83" or percentage of bytes transferred.

3. Some documentation recommends using a VERSION file when building a DFU image with this format
VERSION_MAJOR = 2
VERSION_MINOR = 1
PATCHLEVEL = 0
VERSION_TWEAK = 7
EXTRAVERSION =

However in the mesh dfu sample a config item is used

CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION="1.0.0+0"

Which is the preferred method?

Thank you

[Elfving]

Hello,

1. It's SLOW. The DFU image size is 330K and it took 30 minutes to download it. There were only 2 nodes on the mesh network, the target and the distributor, sitting next to each other. The network I'm evaluating this for  has over hundred nodes spread over a very large territory and my DFU images are larger, about 415K. 

First of all, no matter what you do a Mesh DFU will generally be slow, compared to eg. a normal BLE DFU. I acctually remember as an example that a DFU of 420kB could take two hours. This is due to Mesh not really being designed for high throughput applications. This will also be the case if you want to send any large file accross the Mesh network. Though in situations where you have a large network that is continously online then this is often not considered a problem.

Another thing to note is that it is hard to say anything about how much slower anything will be in a larger network. How long it takes for something to spread over this large network of yours won't be proportional to how long it took for it to spread to 2 nodes, since the first node will spread the DFU package to all nodes that are close to it, not just the second node. And this will then continue for the next node in line.

Is mesh DFU even feasible in my situation?

Sure it is. And if you are doing BLE Mesh, then I don't really see what other practical options you have. But if your network is indeed big, and span a wide area, then Mesh DFU sounds perfect to me, since you won't have to deal with any one individual node. One operation will handle the entire network, no matter how large of an area you have, or how many nodes there are.

Any suggestions to speed up the process?

There are some things that you can do to increase the performance, though it would either way take some time. The mesh node is limited to an average message rate of less than 10Hz. And there might be other things you want to keep in mind and optimize for when configuring the network, not just throughput.

2. The JSON messages returned from mesh models dfd receivers-get  command on the distributor are too  cryptic

Noted.

3. Some documentation recommends using a VERSION file when building a DFU image with this format

My understanding is that both can be used, but using a version file is recommended and considered more flexible. CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION is however easier, for demonstration purposes.

Regards,

Elfving

[AndyM]

Thank you very much for your feedback