Transfer large data with ble-bcast-mesh

RE: Transfer large data with ble-bcast-mesh

David Edwin — Mon, 12 Jun 2017 08:13:31 GMT

For the nRF51822/422, there is more current used in RX ( no DC DC - 0.4 mA more) in 2Mbps as compared to 1Mbps. The TX current differences are marginal and only the on-air time is a significant factor.

In the nRF52832, the RX for 2Mbps is 1.2mA (no DCD-DC) more as compared to the RX in 1Mbps. The TX current differences are marginal and only the on-air time is a significant factor.

1Mbps is the default setting.

RE: Transfer large data with ble-bcast-mesh

Matt — Fri, 09 Jun 2017 16:15:09 GMT

Any drastic increase on power consumption for the 2Mbit mode? I assume the 1Mbit mode is the default setting correct?

RE: Transfer large data with ble-bcast-mesh

David Edwin — Fri, 09 Jun 2017 13:50:41 GMT

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.

RE: Transfer large data with ble-bcast-mesh

Matt — Fri, 09 Jun 2017 13:25:42 GMT

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.

RE: Transfer large data with ble-bcast-mesh

David Edwin — Fri, 09 Jun 2017 12:05:35 GMT

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.

RE: Transfer large data with ble-bcast-mesh

hberg — Fri, 09 Jun 2017 10:58:23 GMT

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.

RE: Transfer large data with ble-bcast-mesh

David Edwin — Fri, 09 Jun 2017 10:31:36 GMT

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.