BLE_HIDS_EVT_NOTIF_ENABLED conditions

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?

  • 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

  • Thank you Simon.

    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?

    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?

  • 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

  • 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.

    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.

  • Hi

    Do you mean on the OS side of things? That I assume would be in the specification of the different OS's. Where they enable/request notifications will be stated there. In the Bluetooth core specification you can for example see that Notifications are commonly enabled after the scan request, see Scan_Request_Notification_Enable BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E page 2451 for details on that. But they can also be enabled after pairing/bonding for example.

    I'm not sure what you mean about a description of the "timing" of notifications being enabled, so please clarify here.

    Best regards,

    SImon

Related