This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

HID keyboard sample is not discovered by Windows10

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.

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

With SANWA BT4.0 mouse, it reply SCAN_RSP 10/10 rate. PC always found BT4.0 mouse.

I also tested with SEGGER Embedded Studio debug mode, SCAN_RSP reply rate is 0/10.

Do you know how to fix HID discover issue?

Do you know how to improve SCAN_RSP reply rate on HID sample?

SDK is 15.3

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

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

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

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

Children
No Data
Related