BLE_HIDS_EVT_NOTIF_ENABLED conditions

RE: BLE_HIDS_EVT_NOTIF_ENABLED conditions

Simonr — Wed, 22 Feb 2023 06:55:23 GMT

Yes, the Managing peers section in the documentation states as follows:

"After a bond to a new peer is established, the Peer Manager assigns a unique peer ID to the peer and stores the bonding and GATT data in flash. The application can later read or update this data, if required, but in most cases, it should be handled exclusively by the Peer Manager."

Best regards,

Simon

RE: BLE_HIDS_EVT_NOTIF_ENABLED conditions

Matthew K — Wed, 22 Feb 2023 04:54:49 GMT

Hello Simon. Then does this mean the CCCD information for enabling Input Report Notification is stored in the flash memory via peer manager?

RE: BLE_HIDS_EVT_NOTIF_ENABLED conditions

Simonr — Tue, 21 Feb 2023 15:18:13 GMT

If the two devices are bonded and have enabled notifications once, I don't think the Android device has to enable notifications again upon reconnecting to a bonded device.

Best regards,

Simon

RE: BLE_HIDS_EVT_NOTIF_ENABLED conditions

Matthew K — Tue, 21 Feb 2023 08:11:15 GMT

Hi Simon. Two last questions before closing this.

When debugging this keyboard example,

1) nRF52 is paired to an Android phone for the first time

2) Android enables HID input report Notify

3) nRF52 disconnects and reconnect

4) this time, Android DOES NOT enable HID input report Notify

Am I missing something or is it really true that central devices (Android, iOS, etc) doesn't need to enable Notification again?

Interestingly, after the re-connection, the nRF52 was still able to send 'hello' keys to the Android device without the Notify enable. Why is this possible?

Thank you so much for your great help!

RE: BLE_HIDS_EVT_NOTIF_ENABLED conditions

Simonr — Mon, 20 Feb 2023 08:45:49 GMT

[quote user="MatthewKYEO"]

From the sniffer, the Android v12 sent two Notification enable for the Input Report.

Where there any documentations from Google/Android explaining that

[/quote]

I'm sorry but we don't know the Android stack by heart, so I think you should either contact the Android support team or ask in a forum with more expertise on Android development.

Best regards,

Simon

RE: BLE_HIDS_EVT_NOTIF_ENABLED conditions

Matthew K — Fri, 17 Feb 2023 15:57:06 GMT

Hi Simon.

[quote userid="75734" url="~/f/nordic-q-a/96603/ble_hids_evt_notif_enabled-conditions/410660"]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.[/quote]

Thanks for pointing this part.

[quote userid="75734" url="~/f/nordic-q-a/96603/ble_hids_evt_notif_enabled-conditions/410660"]I'm not sure what you mean about a description of the "timing" of notifications being enabled,[/quote]

You are right. I meant on the OS side.

From the sniffer, the Android v12 sent two Notification enable for the Input Report.

Where there any documentations from Google/Android explaining that

- two Notification enable will be sent for HID firmwares

- when the Notification enables are sent to nRF52 HID (ex. after pairing complete, etc)

I was trying to search this type of document for Android, iOS, Windows, Linux, etc but I couldn't find it.

Appreciate your great help!

RE: BLE_HIDS_EVT_NOTIF_ENABLED conditions

Simonr — Fri, 17 Feb 2023 13:28:52 GMT

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

RE: BLE_HIDS_EVT_NOTIF_ENABLED conditions

Matthew K — Thu, 16 Feb 2023 21:47:29 GMT

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.

[quote userid="75734" url="~/f/nordic-q-a/96603/ble_hids_evt_notif_enabled-conditions/410055"]My guess is that the Android device does discovery, then enables notifications. [/quote]

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.

RE: BLE_HIDS_EVT_NOTIF_ENABLED conditions

Simonr — Wed, 15 Feb 2023 11:56:11 GMT

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.

[quote user="MatthewKYEO"]In case for Android v12, do you mean the BLE_HIDS_EVT_NOTIF_ENABLED happens due to the service discovery?[/quote]

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

RE: BLE_HIDS_EVT_NOTIF_ENABLED conditions

Matthew K — Wed, 15 Feb 2023 05:24:04 GMT

Thank you Simon.

[quote userid="75734" url="~/f/nordic-q-a/96603/ble_hids_evt_notif_enabled-conditions/409740"]The service discovery is optional, and is done if the central accepts/requests it after pairing[/quote]

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

[quote userid="75734" url="~/f/nordic-q-a/96603/ble_hids_evt_notif_enabled-conditions/409740"]when using Android devices, as it tries to do service discovery upon connection before pairing[/quote]

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?

RE: BLE_HIDS_EVT_NOTIF_ENABLED conditions

Simonr — Tue, 14 Feb 2023 07:12:08 GMT

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