RE: How to create robust BLE transmission and messages between an embedded device and mobile app for large amounts of data? (General design question)

Edvin — Mon, 30 Sep 2024 22:09:10 GMT

Hello,

I am sorry for the late reply.

Ok, let us try to figure this out. Just in case we want to point at some API, what SDK do you intend to use? The nRF5 SDK (which is the "old" SDK used while the nRF52 series was launched. It works, but is in maintenance mode), or do you want to use the new nRF Connect SDK ("NCS", which is our "current" SDK). Regardless of what SDK you are using, the BLE stack and protocol is the same, so let's try to answer your questions:

[quote user=""]What if the app disconnects during the measurement?[/quote]

Let us save this for later.

[quote user=""]Packet formatting[/quote]

This depends on your needs. How much data are we talking in a total measurement? And how often is this being sent? If you need a high throughput, chunking the samples together in bigger packets and using a large MTU is preferable, as it gives a larger payload/header ratio. This allows for up to the 1.3MBPS payload throughput, which is the maximum allowed by the current BLE specification.

[quote user=""]Acknowledgement[/quote]

All packets in BLE are acknowledged, or retransmitted until they are. So this is not really the intention for indications. Notifications should be more than fine for data transfer. Indications, which are application controlled acknowledgment, as you said, are intended for other mechanisms, such as in a doorlock, you can confirm that the door is locked (and not for example jammed) before you send the application acknowledgement back to the central. Using indications instead of notifications gives a significant decrease in throughput.

[quote user=""]Error checking and handling[/quote]

That is correct. The CRC is checked by the BLE stack before the AKC is sent, so you can know that all data that is acked is also correct.

[quote user=""]Data reconstruction[/quote]

You are guaranteed that the packets will enter the receiver's application the same order that they were queued in the transmitter's application. However, if you'd like, you can add some sequence numbering if you want to know how much data is left. I imagine this can replace the need for a "more data" characteristic, which may take up bandwidth, e.g. by saying that the first byte or two describes how much data is left of the transfer.

[quote user=""]What if the app disconnects during the measurement?[/quote]

So back to this. I chose to save it for last since it is the question that complicates all of the questions, really. In general, BLE is a lossless protocol. This doesn't mean that you don't have packet loss, because you certainly do. But the protocol guarantees that all queued packets are transmitted, "and it will die trying". So in this case, "die" means disconnect. As long as you queue a packet, and the link is still connected after the supervision timeout period, the packet has been delivered. If the packet was not received within this period, it means that the devices has not received a packet with the correct CRC within this period, and the link is considered disconnected.

So what is the source of your disconnect? Dead battery? The devices are moving too far apart? An increase in RF noise? Depending on the reason, you may or may not want to introduce saving data to flash. If you don't think power loss is a likely issue, then I wouldn't bother saving data to flash, as long as you are able to store a large enough buffer in RAM. However, if you experience a disconnect, you may want to keep track of what data that is actually sent and ACKed. For this, we have callbacks that you can use to determine what packets that was successfully ACKed (what API and callbacks depends on your SDK). If the issue is that they have a poor connection, I would try to increase the supervision timeout, since this will make them try to communicate for longer before disconnecting the link. The disadvantage of this is that it takes longer for the disconnection to happen and your app to "know", but the advantage is that all your queued packets are still queued, and you don't have to deal with the disconnect/connect handling, and figure out what packets that wasn't ACKed.

Really, it depends on the consequences of your partially transmitted measurements. What is the impact of a disconnect? Can you do another measurement, and throw away the old one?

Hopefully this gives the answer to some of your questions. Perhaps you can elaborate a bit more on the consequences of a partially received measurement? It is possible to store the data in flash, but if the consequences aren't that high, the application structure is way easier if you don't need to think about this.

Best regards,

Edvin