HID keyboard sample is not discovered by Windows10

RE: HID keyboard sample is not discovered by Windows10

Einar Thorsrud — Fri, 28 Jun 2019 06:15:47 GMT

Hi,

This is the expected behavior. In this case, you describe that you delete the bonding information on Windows (step 4), but not on the nRF. The default behavior of the nRF is not allow re-pairing, and so you have to remove the bonding information. You can also change the example to allow repairing as described in this post. However, this has a slight impact on security, as an imposter can spoof your computers MAC address and pair silently. Therefore your "workaround" by deleting the bonding information on the nRF is the most secure approach.

Regarding whitelisting, it is common to use a button or similar to make the peripheral (mouse) advertise without whitelisting in cases where you want to pair with a new device. You can see in main.c of ble_app_hids_keyboard that it handles the BSP_EVENT_WHITELIST_OFF event, and starts to advertise without whitelisting. This event is triggered by pressing button 2 (marking on the PCB, the number in the code is 1).

RE: HID keyboard sample is not discovered by Windows10

toruish — Thu, 27 Jun 2019 20:41:01 GMT

It reproduce on these steps.

1) Write ble_app_hids_keyboard sample hex file to nRF52 DK

2) On Windows10 settings, add Nordic_Keyboard as bluetooth device

3) On pairing, IRK, LTK is saved on nRF52 storage

4) On Windows10 settings, remove Nordic_Keyboard

5) On Windows 10 try to add Nordic_Keyboard

6) nRF52 DK advertise with whitelist, Windows10 cannot discover Nordic_Keyboard

For workaround, I remove Win10 BLE chip info on nRF52 whitelist.

RE: HID keyboard sample is not discovered by Windows10

Einar Thorsrud — Thu, 27 Jun 2019 06:20:45 GMT

Hi,

Yes, using service changed should solve much of the problem. However this is probably only a problem during development (unless you will change the GATT services, name etc. in the actual product as well). In a development scenario, toggling Bluetooth or rebooting the PC should be an acceptable workaround since you probably don't do this often. Another workaround is to change the BLE address since this will make the peer (Windows PC) see it as a new device.

RE: HID keyboard sample is not discovered by Windows10

toruish — Wed, 26 Jun 2019 18:21:20 GMT

Before HID_keyboard, I run BLE_APP_HRS on same DK board.

I guess Windows 10 keeps cache of old GATT service info. Once I switch same device to HID, windows10 still use old cached GATT service and does not recognize as HID. I try to find a way to clear cache on Win10, like service-changed.

RE: HID keyboard sample is not discovered by Windows10

Einar Thorsrud — Tue, 25 Jun 2019 06:18:04 GMT

Hi,

That's odd. But as mentioned the name is already there in the advertising packet, so there is no good reason for putting it in the scan response packet instead (unless you need to put some other data in the advertising packet, and have to move something to the scan response for that reason).

Have you checked that the nRF is actually advertising and that there is no error check being hit?
Do you have a sniffer trace?
And does an unmodified example work, if you just go for a precompiled .hex file from <SDK>\examples\ble_peripheral\ble_app_hids_keyboard\hex\ ?

RE: HID keyboard sample is not discovered by Windows10

toruish — Mon, 24 Jun 2019 22:34:55 GMT

I try to add device name on init.srdata, but Windows 10 settings does not discover.

If I run BLE central scan sample on Windows 10, it discovered Nordic_Keyboard.

Windows 10 Settings does not discover nRF52 HID sample.

I tested 3 different Windows 10 PC and BLE chip combination, all failed.

Windows 10, Intel AC-7260 : Not discover

Windows 10, Intel AC-9560 : Not discover

Windows 10, DW1560 : Not discover.

RE: HID keyboard sample is not discovered by Windows10

Einar Thorsrud — Mon, 24 Jun 2019 08:02:41 GMT

Hi,

The HID keyboard example in the SDK does not use any scan response data, as there is no need (the appearance, full name, and HID UUID are in the advertising packet). Therefore, the scan response packet is empty. However, you can modify the advertisign_init() function in <SDK>\examples\ble_peripheral\ble_app_hids_keyboard\main.c to include it by populating init.srdata if you need it for some reason.

RE: HID keyboard sample is not discovered by Windows10

toruish — Fri, 21 Jun 2019 21:35:49 GMT

I still failed with PC10056 HID keyboard sample. I use Windows10 ver1903, BLE chip is DW1560 bluetooth4.0 LE.

I attach cfa capture file.

I compared with ESP32 HID sample, which is discovered by Windows 10. It returns full info with SCAN_RSP,

even nRF only return empty SCAN_RSP.

Do you have option for SCAN_RSP includes appearance, UUID and local_name?

Thanks,

devzone.nordicsemi.com/.../nrf_5F00_hid_5F00_mydell_5F00_f2.cfa

RE: HID keyboard sample is not discovered by Windows10

Einar Thorsrud — Wed, 19 Jun 2019 12:16:28 GMT

Hi,

[quote user=""]I run blue_app_hids_keyboard_pca10056_s140 sample on nRF52840-DK. I try to connect with Windows 10 PC, but PC does not discover Nordic_Keyboard.[/quote]

The ble_app_hids_keyboard example works with Windows 10, so it is probably something with your setup. Can you confirm that the computer you are testing with support BLE (Bluetooth version >= 4.0.0)? (I don't know if the other mouse you have tested with use BLE or Bluetooth classic). Which Bluetooth chipset is in your PC?

[quote user=""]I found advertising is sent every 25ms. PC send SCAN_REQ, but SCAN_RSP is not always sent back by nRF. SCAN_RSP reply rate is 3/10 (3 times per 10).[/quote]

How have you seen this? A sniffer trace? If so, can you upload it to this case?

[quote user=""]Do you know how to improve SCAN_RSP reply rate on HID sample?[/quote]

The nRF should always reply to SCAN_REQ as long as it is received in time. It could be that some packets are lost if there is alot of noise or long distance between the mouse and PC, but that does not seem likely(?).