Notifications disappear on their way

[AndrzejB]

I use two nrf51 chips, one of which works as central and second one as peripheral. After the DM_EVT_LINK_SECURED event is generated on the peripheral side I'm starting the app_timer in single_shot mode with a 15ms period. Inside of this timer, the characteristic is updated (in the same way as in "Bluetooth low energy Characteristics, a beginner's tutorial") with only one byte of data. On the central side I use lbs client profile and after BLE_GATTC_EVT_HVX is generated I change the flag in the program and terminate the connection.

Now, the problem is this notification send by server (peripheral) never reach the client (central). To actually send data I must repeat updates of the characteristic and only after few updates one of the notification come to the client. Could someone explain to me why this happens and how to overcome this? I use SDK 11

[RK]

that can't happen. BLE is reliable at the transport level so if you are sending a packet it will arrive at the other end (or the link will timeout). So you don't have to send it multiple times. So if you think you do, your bug is elsewhere.

Are you waiting for the callback telling you the packet buffer has been retired, when you have that you know the underlying transport has successfully sent the packet and received the L2CAP level confirmation the client side has received it? If you terminate the connection before that, you may just prevent it actually sending the packet out if the stack hasn't sent it yet, is waiting for the next connection interval or is in the process of retrying it.

[AndrzejB]

The connection terminate only by the client when BLE_GATTC_EVT_HVX event arrives. In the described situation (if only one notification is being sent) the connection last forever.