Transfer large data with ble-bcast-mesh

[hberg]

Hello,

i'm currently looking into ble-bcast-mesh with the goal to transfer a large amount of data (up to 1kB) from one node to another. ble-bast-mesh is working (as far as i understand it) by broadcasting data in handles to the whole network, until all nodes have the same data for a specific handle. ble-bcast-mesh can handle multiple handles at the same time.

The data should be acknowledge by the reciving node. The maximum number of nodes is about 10.

How would be the workflow for transfering a large amount of data? I see two possibilities:

1. Splitting the data in chunks to different handles
2. Splitting the data in chunks and using only one handle, sending chunk after chunk (waiting for ACK before sending another chunk)

Has anyone used ble-bcast-mesh for large data? What is the right option for this use-case?

Edit: I did some thinking, and maybe this could be a solution:

I use three handles:

• Handle 0x00: Defines the state of the mesh network
• Handle 0x01: Transfers payload
• Handle 0x02: Acknowledge

If node a wants to communicate with node b, it creates a logical channel. It does it by setting the state-handle 0x00 to a specific payload with src-address, dst-address, and other bits. When after some time node a doesnt receive an update on handle 0x00, the network now has census that node a communicates with node b.

When node a now sets data to handle 0x01, it gets propagated to the whole network. Because the state-handle 0x00 has information about the transfer (src/dst), node b knows the data is for him.

After receiving the data, node b sends zero-payload to handle 0x02. node a receives the handle (with new version), and knows the data has been received by node b. Now the next payload can be sent to node b.

If all data has been sent, node a changes the state-handle 0x00 to an idle state. Now the next node can start a transfer, if needed.

Can this work?

Best regards, hberg

[David Edwin]

1Kbyte of data does not appear to be an issue. Using multiple handles (a group of handles per node) will be the fastest. Building a sliding window scheme for acks so you do not set a lot of ACKs will be good i.e. you ack only a block of packets. We have also seen the "nacks" can also be useful i.e. send an ack for a block, but also use it to list missing packets in the block. The DFU for the mesh uses a scheme of "nacks".

In addition, you can stop the propagation of the data with some auto discovery of the location of the nodes and their neighbors, you will improve bandwidth even more. Make sure you size the RAM correctly so that all the handles you are using will remain in the cache

I think your scheme will work, but appears slower to me as it will allow only one transaction on the mesh at a time. I think an improved scheme can be devised with multiple handles and the comments above.

[David Edwin]

You will need to experiment a bit on the number of handles per node, perhaps you can start with 5. The ACKs will give you the reliability. Make sure the cache size is large enough is have all the handles in the RAM.