HID reconnection problem

[David]

I'm trying to save power on my HID keyboard application by disconnecting the Bluetooth link after some time of inactivity. As soon as there are keystrokes to send, the device advertises again and sends the pending values.

Generally I have 8 chars to transmit at once, but in Android 7.1.1 (Nexus 5X) I often get only 7 or less. The first one or two characters seem to get lost, although there is no error event generated by my nRF8001. I even get the right number of data credit events, so I assume the values have been sent correctly. The second value (again 8 chars) is always transmitted entirely.

I always wait for the first pipe status event after reconnection, sending data right after the connected event makes it even worse.

How can I achieve a reliable transmission of my first value? Is there some event to tell me that the master device is fully ready to receive keystrokes? Has someone experienced a similar behaviour and found a workaround?

[David]

OK, thank you for the information.

But how can I know that the encryption process has been successfully completed? The nRF8001 does not generate any events...

Edit: In another thread (devzone.nordicsemi.com/.../), I found that the nRF8001 generates a pipe status event after finishing encryption. Waiting for this event works for some devices, but not all. Specially iOS devices seem to ignore the first couple of notifications. What do I need to do to assure a reliable data transmission after HID reconnection?

[run_ar]

Did you check with a sniffer that the LL_START_ENC_RSP was sent before the notifications? Maybe you could try adding a small delay before you start sending notifications . or for testing use a long one, and see if that helps.

[David]

Yes, the LL_START_ENC_RSP (line in blue) is sent before my first indication. My first indication is sent about 0.57s later, the last indication (black lines) even more than 1.2s after the encryption message but they are still ignored by the master device.

In this case the nRF8001 generates three identical pipe status events. Any notification sent before the third one seems to be ignored by the master device. Unfortunately sometimes there is only one pipe status event...

OK, waiting for about five seconds after the first pipe status event works fine, but this is definitely too long! Any idea how to make sure all the indications are received correctly?

[run_ar]

This looks like a limitation with the Android device. It should accept notifications as soon as you have encrypted the link again. Have you teste this with other masters? e.g. do you see the same behavior if you test with iOS?