Hello!
I have developed a BLE HID (HOGP) device in Nordic SDK 15.0.0 starting from an example project: ble_app_hids_keyboard .
The HID device that I have developed however needs to send a larger data payload than a standard keyboard. For that reason, I had to increase the maximum MTU size (NRF_SDH_BLE_GATT_MAX_MTU_SIZE ) from the default 23 to 67. After subtracting the header, this allows for an effective payload of up to 64 bytes.
I have tested the project with success on an nRF52840-DK, connecting it from various peer devices, such as:
- Windows7 PC (using a third party Bluetooth driver since not included in Windows7)
- MacOS 10.14 computer
- iOS
- Android
and it pairs fine and works as expected.
However, when it comes to testing from a Windows 10 PC, the pairing procedure always fails with an error message: "driver error", and specifically, Device Manager reports "Extra end collection found or end collection not found":
I found that the problem with Windows 10 seems to be related to the use of the increased GATT MTU size.
To be sure that the problem is not with my code, I ran a similar test with the original Nordic ble_app_hids_keyboard example from SDK 15.0.0.
I ran the example on my nRF52840 DK board without changes and it paired without errors with Windows 10.
Then, I modified the GATT MTU size in sdk_config.h as folllows:
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 67
(this change also required that I increase the RAM size, which I did). The result is that now Windows 10 shows exactly the same problem as described above.
At this point I tried to understand what happened using the nRF Sniffer. It turns out that when MTU size is increased, during the pairing process with Windows 10 only a part (the first segment) of the HID Report Map is transferred to the PC. This problem does not occur with other operating systems.
When MTU size = 23 bytes and things work fine, one can see that the entire HID Report Map (consisting of 76 bytes, see array report_map_data[] in the ble_app_hids_keyboard example project) is transferred in 4 chunks (segments, at packets # 1614, 1618, 1622 and 1626) and therefore is reassembled correctly:
However, when changing the MTU size to 67 bytes, the following happens with Windows 10:
As can be seen, there is only one response packet containing the first 22 bytes of the Report Map (packet # 4359). The rest is missing (Windows 10 does not request further segments). It is obvious that such a truncated Report Map is flagged as bad by Windows 10.
Just for comparison, the following nRF Sniffer log shows the correct pairing sequence with a MacOs computer, with MTU=67 bytes (pairing succeds):
As can be seen, the entire Report Map (76 bytes) is transferred in two segments (66 bytes in packet #2432, the remaining 10 bytes in packet # 2436).
My question:
Am I missing something? My application (and the Nordic ble_app_hids_keyboard example) with MTU=67 work fine on the majority of OS's, but not with Windows 10. Did I forget to make some further changes in addition to changing NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 67 ?
Even though I'm not ready to migrate my project to SDK 15.2.0, I did a quick test with the ble_app_hids_keyboard example project provided in that version. Same here: Windows 10 fails to pair as soon as MTU is increased from the default value of 23. However, the error reported by Windows is slightly different and nRF Sniffer reveals a different scenario (the nRF52840 answers with an error message "Insufficient Authentication" to the request for the Report Map).
Thanks for any suggestion!
I attach the nRF Sniffer logs (Wireshark):
1_ble_app_hids_keyboard-Win10-MTU23-OK.pcapng
