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 Kconfig options are aligned with the nRF Desktop use case.

The nRF Desktop devices come in the following roles:

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

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.

Application modules

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

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:

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:

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:

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 specified in the files with filenames ending with the fast_pair and release_fast_pair suffixes.

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 SB_CONFIG_BT_FAST_PAIR Kconfig option is enabled in the sysbuild configuration. For more details about enabling Fast Pair for your application, see the Enabling Fast Pair in Kconfig section in the Fast Pair integration guide.

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