nRF Desktop: Bluetooth

The nRF Desktop devices use Zephyr’s Bluetooth API to handle the Bluetooth LE connections.

This API is used only by the application modules that handle such connections. The information about peer and connection state is propagated to other application modules using Application Event Manager events.

The CONFIG_DESKTOP_BT Kconfig option enables support for Bluetooth connectivity in the nRF Desktop. Specific Bluetooth configurations and application modules are selected or implied according to the HID device role. Apart from that, the defaults of Bluetooth-related Kconfigs are aligned with the nRF Desktop use case.

The nRF Desktop devices come in the following roles:

• HID peripheral (CONFIG_DESKTOP_ROLE_HID_PERIPHERAL) that works as a Bluetooth Peripheral (CONFIG_DESKTOP_BT_PERIPHERAL)

  • Support only the Bluetooth Peripheral role (CONFIG_BT_PERIPHERAL).

  • Handle only one Bluetooth LE connection at a time.

  • Use more than one Bluetooth local identity.

• HID dongle (CONFIG_DESKTOP_ROLE_HID_DONGLE) that works as a Bluetooth Central (CONFIG_DESKTOP_BT_CENTRAL)

  • Support only the Bluetooth Central role (CONFIG_BT_CENTRAL).

  • Handle multiple Bluetooth LE connections simultaneously.

  • Use only one Bluetooth local identity (the default one).

Both central and peripheral devices have dedicated configuration options and use dedicated modules.

The nRF Desktop peripheral configurations that enable Fast Pair support use a slightly different Bluetooth configuration. This is needed to improve the user experience. See Fast Pair for more details.

Note

An nRF Desktop device cannot support both central and peripheral roles.

Common configuration and application modules

Some Bluetooth-related configuration options (including Link Layer configuration options in a separate section) and application modules are common for every nRF Desktop device.

Configuration options

This section describes the most important Bluetooth Kconfig options common for all nRF Desktop devices. For detailed information about every option, see the Kconfig help.

• CONFIG_BT_MAX_PAIRED

  • nRF Desktop central: The maximum number of paired devices is greater than or equal to the maximum number of simultaneously connected peers. The CONFIG_BT_MAX_PAIRED is by default set to CONFIG_DESKTOP_HID_DONGLE_BOND_COUNT.

  • nRF Desktop peripheral: The maximum number of paired devices is equal to the number of peers plus one, where the one additional paired device slot is used for erase advertising.

• CONFIG_BT_ID_MAX

  • nRF Desktop central: The device uses only one Bluetooth local identity, that is the default one.

  • nRF Desktop peripheral: The number of Bluetooth local identities must be equal to the number of peers plus two.

    • One additional local identity is used for erase advertising.

    • The other additional local identity is the default local identity, which is unused, because it cannot be reset after removing the bond. Without the identity reset, the previously bonded central could still try to reconnect after being removed from Bluetooth bonds on the peripheral side.

• CONFIG_BT_MAX_CONN

  • nRF Desktop central: This option is set to the maximum number of simultaneously connected devices. The CONFIG_BT_MAX_CONN is by default set to CONFIG_DESKTOP_HID_DONGLE_CONN_COUNT.

  • nRF Desktop peripheral: The default value (one) is used.

Note

After changing the number of Bluetooth peers for the nRF Desktop peripheral device, update the LED effects used to represent the Bluetooth connection state. For details, see LED state module.

Link Layer configuration options

The nRF Desktop devices use one of the following Link Layers:

• CONFIG_BT_LL_SW_SPLIT

  This Link Layer does not support the Low Latency Packet Mode (LLPM) and has a lower memory usage, so it can be used by memory-limited devices.

• CONFIG_BT_LL_SOFTDEVICE

  This Link Layer does support the Low Latency Packet Mode (LLPM). If you opt for this Link Layer and enable the CONFIG_BT_CTLR_SDC_LLPM, the CONFIG_CAF_BLE_USE_LLPM is also enabled by default and can be configured further:

  • When CONFIG_CAF_BLE_USE_LLPM is enabled, set the value for CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT to 3000.

    This is required by the nRF Desktop central and helps avoid scheduling conflicts with the Bluetooth Link Layer. Such conflicts could lead to a drop in HID input report rate or a disconnection. Because of this, if the nRF Desktop central supports LLPM and more than one simultaneous Bluetooth connection, it also uses 10 ms connection interval instead of 7.5 ms. Setting the value of CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT to 3000 also enables the nRF Desktop central to exchange data with up to three standard Bluetooth LE peripherals during every connection interval (every 10 ms).

  • When CONFIG_CAF_BLE_USE_LLPM is disabled, the device will use only standard Bluetooth LE connection parameters with the lowest available connection interval of 7.5 ms.

    If the LLPM is disabled and more than two simultaneous Bluetooth connections are supported (CONFIG_BT_MAX_CONN), you can set the value for CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT to 2500. With this value, the nRF Desktop central can exchange the data with up to three Bluetooth LE peripherals during every 7.5-ms connection interval. Using the value of 3000 for more than two simultaneous Bluetooth LE connections will result in a lower HID input report rate.

Application modules

Every nRF Desktop device that enables Bluetooth must handle connections and manage bonds. These features are implemented by the following modules:

• Bluetooth LE state module - Enables Bluetooth and LLPM (if supported), and handles Zephyr connection callbacks.

• Bluetooth LE bond module - Manages Bluetooth bonds and local identities.

You need to enable all these modules to enable both features. For information about how to enable the modules, see their respective documentation pages.

Optionally, you can also enable the following module:

• Bluetooth LE Quality of Service module - Helps achieve better connection quality and higher report rate. The module can be used only with the SoftDevice Link Layer.

Note

The nRF Desktop devices enable the CONFIG_BT_SETTINGS Kconfig option. When this option is enabled, the application is responsible for calling the settings_load() function - this is handled by the Settings loader module.

Bluetooth Peripheral

The nRF Desktop peripheral devices must include additional configuration options and additional application modules to comply with the HID over GATT specification.

The HID over GATT profile specification requires Bluetooth Peripherals to define the following GATT Services:

• HID Service - Handled in the HID Service module.

• Battery Service - Handled in the GATT Battery Service module.

• Device Information Service - Implemented in Zephyr and enabled with the CONFIG_BT_DIS Kconfig option. The device identifiers are configured according to the common HID device identifiers by default. You can configure it using Kconfig options with the CONFIG_BT_DIS prefix.

The nRF Desktop peripherals must also define a dedicated GATT Service that is used to provide the following information:

• Information on whether the device can use the LLPM Bluetooth connection parameters.

• Hardware ID of the peripheral.

The GATT Service is implemented by the Device description module.

Apart from the GATT Services, an nRF Desktop peripheral device must enable and configure the following application modules:

• Bluetooth LE advertising module - Controls the Bluetooth advertising.

• Bluetooth LE latency module - Keeps the connection latency low when the Configuration channel is used or when either the Simple Management Protocol module or Device Firmware Upgrade MCUmgr module receives an update image. This is done to ensure quick data transfer.

Optionally, you can also enable the following module:

• Quality of Service module - Forwards the Bluetooth LE channel map generated by Bluetooth LE Quality of Service module. The Bluetooth LE channel map is forwarded using GATT characteristic. The Bluetooth Central can apply the channel map to avoid congested RF channels. This results in better connection quality and a higher report rate.

Fast Pair

The nRF Desktop peripheral can be built with Google Fast Pair support. The configurations that enable Fast Pair are set in the prj_fast_pair.conf and prj_release_fast_pair.conf files.

Note

The Fast Pair integration in the nRF Desktop is experimental. The factory reset of the Fast Pair non-volatile data is not yet supported.

The Fast Pair support in the nRF Connect SDK is experimental. See Google Fast Pair integration for details.

These configurations support multiple bonds for each Bluetooth local identity (CONFIG_CAF_BLE_STATE_MAX_LOCAL_ID_BONDS is set to 3) and erase advertising (CONFIG_DESKTOP_BLE_PEER_ERASE), but Bluetooth peer selection (CONFIG_DESKTOP_BLE_PEER_SELECT) is disabled. You can now pair with your other hosts without switching the peripheral back in pairing mode (without triggering the erase advertising). The nRF Desktop peripheral that integrates Fast Pair behaves as follows:

• The dongle peer does not use the Fast Pair advertising payload.

• The bond erase operation is enabled for the dongle peer. This lets you change the bonded Bluetooth Central.

• If the dongle peer (CONFIG_DESKTOP_BLE_DONGLE_PEER_ENABLE) is enabled, the Swift Pair payload is, by default, included only for the mentioned peer. In the Fast Pair configurations, the dongle peer is intended to be used for all of the peers that are not Fast Pair Seekers.

• If the used Bluetooth local identity has no bonds, the device advertises in pairing mode, and the Fast Pair discoverable advertising is used. This allows to pair with the nRF Desktop device using both Fast Pair and normal Bluetooth pairing flows. This advertising payload is also used during the erase advertising.

• If the used Bluetooth local identity already has a bond, the device is no longer in the pairing mode and the Fast Pair not discoverable advertising is used. This allows to pair only with the Fast Pair Seekers linked to Google Accounts that are already associated with the nRF Desktop device. In this mode, the device rejects normal Bluetooth pairing by default (CONFIG_DESKTOP_FAST_PAIR_LIMIT_NORMAL_PAIRING option is enabled). The Fast Pair UI indication is hidden after the Provider reaches CONFIG_CAF_BLE_STATE_MAX_LOCAL_ID_BONDS bonded peers on the used local identity.

• The Factory reset module is enabled by default if the Configuration channel is supported by the device. The factory reset operation removes both Fast Pair and Bluetooth non-volatile data. The factory reset operation is triggered using the configuration channel.

After a successful erase advertising procedure, the peripheral removes all of the bonds of a given Bluetooth local identity.

Apart from that, the following changes are applied in configurations that support Fast Pair:

• The static Partition Manager configuration is modified to introduce a dedicated non-volatile memory partition used to store the Fast Pair provisioning data.

• Bluetooth privacy feature (CONFIG_BT_PRIVACY) is enabled.

• The fast and slow advertising intervals defined in the Bluetooth LE advertising module are aligned with Fast Pair expectations.

• The Bluetooth advertising filter accept list (CONFIG_CAF_BLE_ADV_FILTER_ACCEPT_LIST) is disabled to allow Fast Pair Seekers other than the bonded one to connect outside of the pairing mode.

• The security failure timeout (CONFIG_DESKTOP_BLE_SECURITY_FAIL_TIMEOUT_S) is longer to prevent disconnections during the Fast Pair procedure.

• Passkey authentication (CONFIG_DESKTOP_BLE_ENABLE_PASSKEY) is disabled on the keyboard. Currently, Fast Pair does not support devices that use a screen or keyboard for Bluetooth authentication.

• TX power correction value (CONFIG_BT_ADV_PROV_TX_POWER_CORRECTION_VAL) is configured to align the TX power included in the advertising data with the Fast Pair expectations.

See Google Fast Pair integration for detailed information about Fast Pair support in the nRF Connect SDK.

Bluetooth Central

The nRF Desktop central must implement Bluetooth scanning and handle the GATT operations. The central must also control the Bluetooth connection parameters. These features are implemented by the following application modules:

• Bluetooth LE scanning module - Controls the Bluetooth scanning.

• Bluetooth LE connection parameters module - Controls the Bluetooth connection parameters and reacts on latency update requests received from the connected peripherals.

• Bluetooth LE discovery module - Handles discovering and reading the GATT Characteristics from the connected peripheral.

• HID forward module - Subscribes for HID reports from the Bluetooth Peripherals (HID over GATT) and forwards data using application events.