nRF51 UAart Example data loss over bluetooth interface

RE: nRF51 UAart Example data loss over bluetooth interface

GlennEngel — Wed, 10 Feb 2016 15:38:06 GMT

Thanks for the explanation. It would seem that if guaranteed delivery of all data is required, some sort of application buffer needs to be maintained along with an acknowledged receipt to retire the leading portion of the buffered data. Sort of like TCP/IP.

RE: nRF51 UAart Example data loss over bluetooth interface

Kenneth — Wed, 10 Feb 2016 09:14:12 GMT

While you are in a connection yes, however when you disconnect no, this is because when you transmit the packet over BLE, it's not until next connection interval that the peripheral know if the packet was received or not.

RE: nRF51 UAart Example data loss over bluetooth interface

awneil — Wed, 10 Feb 2016 08:59:08 GMT

Is there no indication or feedback from the SoftDevice as to which packets were (or were not) successfully transferred end-to-end?

RE: nRF51 UAart Example data loss over bluetooth interface

Kenneth — Tue, 09 Feb 2016 17:25:12 GMT

Updated the answer to reflect this.

RE: nRF51 UAart Example data loss over bluetooth interface

awneil — Tue, 09 Feb 2016 13:49:54 GMT

The fact that the application can't rely upon data not being lost during a disconnection means that it just can't rely upon data not being lost at all!

RE: nRF51 UAart Example data loss over bluetooth interface

Kenneth — Tue, 09 Feb 2016 11:58:12 GMT

It depends on how you look at it, while in a connection all data is reliable, they are sent in the order they are written and application doesn't need to take any steps to ensure data is successfully transmitted. Once you are disconnected that of course stops.

RE: nRF51 UAart Example data loss over bluetooth interface

awneil — Tue, 09 Feb 2016 11:52:40 GMT

So the answer to the original question, "Is there a way for the client to know if it needs to resend some of it's queued data", is: "NO"

RE: nRF51 UAart Example data loss over bluetooth interface

Kenneth — Tue, 09 Feb 2016 11:39:36 GMT

If it's important for the application to continue from the exact place where the BLE_GAP_EVT_DISCONNECTED occured, then you can in the application have some handshaking with the central after BLE_GAP_EVT_CONNECTED to enquire where data should proceed.

RE: nRF51 UAart Example data loss over bluetooth interface

awneil — Tue, 09 Feb 2016 11:23:27 GMT

Yes - but how would the application know if there were outstanding packets that have not completed the transfer?

RE: nRF51 UAart Example data loss over bluetooth interface

Kenneth — Tue, 09 Feb 2016 10:30:39 GMT

On link loss the softdevice will provide a BLE_GAP_EVT_DISCONNECTED event to the application. How you want to handle this is entirely up to the application.

RE: nRF51 UAart Example data loss over bluetooth interface

awneil — Tue, 09 Feb 2016 09:48:31 GMT

So how would the application know that it had happened, in order to be able to handle it?

RE: nRF51 UAart Example data loss over bluetooth interface

Kenneth — Tue, 09 Feb 2016 09:08:36 GMT

Yes, that must be handled by the application in some way.

RE: nRF51 UAart Example data loss over bluetooth interface

awneil — Tue, 09 Feb 2016 09:04:33 GMT

So, at the point of link loss, there may be some packets that have not completed the transfer - surely that is something that the application needs to consider?

RE: nRF51 UAart Example data loss over bluetooth interface

Kenneth — Tue, 09 Feb 2016 08:49:48 GMT

Hi, all packets transmitted over a BLE link will be retried infinitely until link loss, all packets are protected by a CRC on the link layer. This is fully handled by the softdevice.

However on link loss (BLE_GAP_EVT_DISCONNECTED event) the last packet(s) that was in process of being sent might be lost. The application can on next connection establishment (BLE_GAP_EVT_CONNECTED event) do some handshaking on application layer to inquire where data should proceed.