BLE_HIDS_EVT_NOTIF_ENABLED conditions

[Matthew K]

Hi guys. I have several questions when testing the ble_app_hids_keyboard_pca10056_s113 project from 17.1.0 nRF5 SDK.

I couldn't find the part that explains when does the Bluetooth Central device enables the HID notification.

First, is it true that the central device enables HID input report characteristic's notification when pairing is completed with the nRF52 HID keyboard?

(EX: Android v12 / iOS phone / Windows laptop etc connects with the nRF52 first time, pairing is successful, then BLE_HIDS_EVT_NOTIF_ENABLED happens)

Then what about the nRF52 that was paired previously? Since it was already paired, does the BLE_HIDS_EVT_NOTIF_ENABLED happen right after BLE_GAP_EVT_CONNECTED?

Next, When the nRF52 connects with an Android 12 smartphone the first time,

on_hids_evt() - BLE_HIDS_EVT_NOTIF_ENABLED happened twice, when the Android phone pairs with the nRF52.

Is it normal to see this being enabled 2 times?

[Simonr]

Hi

Depending on the central side that the keyboard application connects to that is the device deciding when/if service discovery is done. The service discovery is optional, and is done if the central accepts/requests it after pairing, correct. If a paired/bonded device is disconnected, then service discovery can be done upon connection.

In the nRF5 SDK, the peer manager is the library that manages BLE security, paring and bonding, so you can take a look there to see how these events are handled.

I think seeing this event twice is something that's common when using Android devices, as it tries to do service discovery upon connection before pairing, then either gets the pairing request or info that the device has to be paired to successfully do service discovery. To see exactly what happens on the air you can sniff the BLE packets either with a dedicated Bluetooth sniffer (Ellisys for example) or a spare DK with the nRF Sniffer firmware and Wireshark.

Best regards,

Simon

[Matthew K]

Thank you Simon.

Simonr said:

The service discovery is optional, and is done if the central accepts/requests it after pairing

Did you mean the service discovery is done after the pairing is completed?

Simonr said:

when using Android devices, as it tries to do service discovery upon connection before pairing

In case for Android v12, do you mean the BLE_HIDS_EVT_NOTIF_ENABLED happens due to the service discovery?

So [1] Service discovery [2] Pairing complete

are the reasons for seeing the BLE_HIDS_EVT_NOTIF_ENABLED, right?

[Simonr]

Hi

Depending on the service and application, discovery is done before or after the pairing procedure. Some services, like the Glucose service used in our ble_app_gls application requires pairing and bonding first. Most others don't.

Matthew K said:

In case for Android v12, do you mean the BLE_HIDS_EVT_NOTIF_ENABLED happens due to the service discovery?

Yes, I think so. My guess is that the Android device does discovery, then enables notifications. Afterwards it gets a pairing request and does the full pairing method before doing another service discovery and enables notifications again. This can be seen more easily if you're able to capture a sniffer trace.

Best regards,

Simon

[Matthew K]

Thank you Simon.

Thanks to the Nordic sniffer, I was able to detect two Notification enables and check the HID input since this default example was using JustWorks.

Simonr said:

My guess is that the Android device does discovery, then enables notifications.

Back to my first part "I couldn't find the part that explains when does the Bluetooth Central device enables the HID notification.",

Is there a document that describes this "timing" when the Input Report Notification is enabled for each OSes (Android, iOS, Windows, Linux, etc)?

Sadly, I couldn't find this from the USB HID document. After finding the reference, let's close this thread.