nRF51 UAart Example data loss over bluetooth interface

[GlennEngel]

In looking at the nRF51 UART Example I'm wondering about data loss over the Bluetooth interface.

When bytes are sent to the host, is there a re-transmission mechanism somewhere that insures the bytes actually reach the host? I understand why flow control is needed on the actual UART hardware but what insures that the data actually makes it over the wireless connection without loss? Is there a way for the client to know if it needs to resend some of it's queued data or is the example just send and hope for the best?

[awneil]

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

[Kenneth]

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.

[awneil]

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"

[Kenneth]

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.

[awneil]

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!