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.

[hberg]

One transfer at a time is no problem, there are only about 10 devices and the data transfer is sporadic, but must absolutely be reliable. Each device should also be able to talk to each other. Because each device is on its on, i must implement some kind of discovery to detect what nodes are on the mesh (still figuring out).

Can you tell me how many handles can be used in parallel efficiently? I think i will implement my scheme, but with multiple handles for data transfer like you advised.

Thank you.

[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.

[Matt]

I have also been using a similar scheme to transfer "long" message in my mesh network (N52832) with (a) the message pay load increased from 23 bytes to 112 bytes [there is another thread showing how to do this] and (b) using 2 handles in this fashion:

handle 1 for node A send message to node B, and node B returns ACKs to node A; handle 2 for node B sends message to node A, and node A returns ACKs to node B;

My mesh network is kind of "puny" right now, comprising only 6 nodes, and my application also involves sending sporadic messages, so I cannot say for sure this scheme will work under extreme message volume condition.

[David Edwin]

Yes, increasing the packet size will also improve your bandwidth but will increase the probability of collisions. However you can also switch to 2Mbit mode for the radio which will reduce the on air time needed and reduce the probability of collisions. However larger packets will be a net positive on bandwidth even in 1Mbit mode.