Bluetooth Fast Pair: Locator tag

This sample demonstrates how to use Google Fast Pair with the nRF Connect SDK to create a locator tag device that is compatible with the Android Find Hub app. Locator tag is a small electronic device that can be attached to an object or a person, and is designed to help locate them in case they are missing.

Google Fast Pair Service (GFPS) is a standard for pairing Bluetooth® and Bluetooth LE devices with as little user interaction required as possible. Google Fast Pair standard also supports the Find Hub Network (FHN) extension that is the main focus of this sample demonstration. For detailed information, see the official Fast Pair Find Hub Network extension documentation.

This sample follows the Fast Pair Device Feature Requirements for Locator Tags documentation and uses the Fast Pair configuration for the locator tag use case. The software maturity level for the locator tag use case is outlined in the Google Fast Pair use case support table.

Requirements

The sample supports the following development kits:

Hardware platforms

PCA

Board name

Board target

nRF54LS05 DK

PCA10214

nrf54ls05dk

nrf54ls05dk/nrf54ls05b/cpuapp nrf54ls05dk/nrf54ls05a/cpuapp

nRF54LM20 DK

PCA10184

nrf54lm20dk

nrf54lm20dk/nrf54lm20b/cpuapp nrf54lm20dk/nrf54lm20a/cpuapp

nRF54LC10 DK

PCA10226

nrf54lc10dk

nrf54lc10dk/nrf54lc10a/cpuapp

nRF54L15 TAG

PCA20072

nrf54l15tag

nrf54l15tag/nrf54l15/cpuapp

nRF54L15 DK

PCA10156

nrf54l15dk

nrf54l15dk/nrf54l15/cpuapp

nRF54L15 DK (emulating nRF54L10)

PCA10156

nrf54l15dk

nrf54l15dk/nrf54l10/cpuapp

nRF54L15 DK (emulating nRF54L05)

PCA10156

nrf54l15dk

nrf54l15dk/nrf54l05/cpuapp

Reference board targets

Reference board targets are complete boards with the onboard peripherals that are required in the locator tag products (speaker, motion detector, battery). You can use such devices as a reference design for the development and testing of the locator tag products.

The following are considered reference board targets:

  • nRF54L15 TAG (nrf54l15tag/nrf54l15/cpuapp)

Note

The nRF54L15 TAG is not fully representative of the reference board targets, as it does not include an onboard speaker - an essential component for locator tag applications. However, the board provides a dedicated placeholder socket that allows a compatible buzzer to be soldered in for evaluation and development purposes.

Overview

The sample works as a Fast Pair locator tag and is compatible with the Android Find Hub app.

FHN provisioning

You can add the device that runs the sample code to the Find Hub app in a process called FHN provisioning. The process is triggered automatically as a subsequent step of the Fast Pair procedure.

To trigger the Fast Pair Procedure, move your Android device close to the locator tag that is advertising in the Fast Pair discoverable mode. Your smartphone detects the tag’s advertising packets and displays the half-sheet notification which you can use to start the procedure. The FHN provisioning process automatically follows the Fast Pair procedure. During the provisioning, the device is linked with the Google account of its new owner.

Using a provisioned device

Once provisioned, the accessory starts to advertise the FHN payload. This payload is used by nearby Android devices to report the accessory location to its owner.

You can manage your provisioned device in the Find Hub app. The application displays a map in your item view. It helps you determine the approximate location of your device. You can also play a sound on the nearby tagged accessory with the Find Hub app to make it easier to find.

Synchronization mode

In the provisioned state, the accessory attempts to synchronize its beacon clock after the system reboot (for example, due to battery replacement). In this case, it broadcasts the Fast Pair not discoverable advertising payload to indicate that the Android device needs to synchronize with the locator tag. The smartphone detects the Fast Pair advertising, connects to the accessory, and exchanges the necessary data to synchronize its beacon clock with the current clock value of the connected device. After the successful synchronization, the locator tag stops the Fast Pair not discoverable advertising. From now on, the accessory uses only the FHN payload for the advertising process.

Note

The Android device uses a throttling mechanism to prevent the beacon clock synchronization from happening more than once every 24 hours. The provisioning operation is also considered a clock synchronization event and requires a 24-hour wait period before the next synchronization attempt.

Identification mode

In the provisioned state, you can enter the identification mode for a limited time. This mode allows the connected peer to read identifying information from the locator tag. An example of such identifying information is reading the Bluetooth GAP Device Name over Bluetooth. The identification mode also allows for reading the Identifier Payload defined in the Detecting Unwanted Location Trackers (DULT) specification. The timeout for identification mode is handled by the DULT subsystem and was introduced to improve user privacy.

Recovery mode

In the provisioned state, you can enter the recovery mode for a limited time. This mode allows the Android device to recover a lost provisioning key from the locator tag.

Motion detector mode

In the provisioned state, the accessory can activate the motion detector mode defined in the DULT specification. The mode is activated when the accessory is separated from the owner for a sufficient amount of time (see CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MIN and CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MAX Kconfig options). In this state, if motion is detected, the accessory starts the ringing action. Emitted sounds help to alert the non-owner that they are carrying an accessory that does not belong to them and might be used by the original owner to track their location. On DKs, you can generate the simulated motion by button action. On the Reference board targets, the built-in accelerometer is used to detect the motion. The motion detector is deactivated for the period set in the CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_BACKOFF_PERIOD Kconfig option after 10 sounds has been played or after the motion has been detected and 20 seconds have passed. The motion detector is also deactivated if the accessory reappears near its owner.

Precision Finding

In the provisioned state, if the Precision Finding is enabled, the Android device can initiate precise distance measurement with the locator tag using the Find nearby feature of the Find Hub app.

The sample uses Bluetooth Low Energy Channel Sounding (CS) as the ranging technology for the Precision Finding. When the Seeker initiates the Find nearby session, it negotiates the supported ranging technologies with the Provider and configures the Bluetooth Low Energy CS session. Once the Bluetooth Low Energy CS session is established, the Find Hub app displays the measured distance to the locator tag in the center of the Find nearby view.

The application-level ranging module is enabled by the CONFIG_APP_RANGING Kconfig option, which is set to y by default on board targets that provide hardware support for Bluetooth Low Energy CS. The following board targets support the ranging module:

  • nrf54l15dk/nrf54l10/cpuapp

  • nrf54l15dk/nrf54l15/cpuapp

  • nrf54l15tag/nrf54l15/cpuapp

  • nrf54lm20dk/nrf54lm20a/cpuapp

  • nrf54lm20dk/nrf54lm20b/cpuapp

Note

The CONFIG_APP_RANGING Kconfig option is explicitly disabled for CS-capable board targets with limited memory to avoid memory overflow. Currently, the nrf54l15dk/nrf54l05/cpuapp board target is the only example of such a board target.

FHN unprovisioning

You can remove your device from the Find Hub app in a symmetrical operation, called unprovisioning. Once unprovisioned, the accessory stops broadcasting the FHN advertising payload.

During the unprovisioning, the device link with the owner’s Google account is removed. To bring the accessory back to its initial state and make provisioning available for the next owner, you need to perform a factory reset.

After the factory reset operation, the Fast Pair discoverable advertising gets automatically disabled to prevent a restart of the Fast Pair procedure. You need to press a button to set your accessory in the Fast Pair discoverable advertising mode and make it available for the next FHN provisioning.

Fast Pair advertising policy

The sample uses the Fast Pair Advertising Manager module and its trigger-based system to manage the advertising process. The advertising is turned on if at least one trigger is active.

The sample code defines and manages the following triggers:

  • Pairing mode trigger that activates after a button action.

    Note

    This trigger can also automatically change its state in the following cases:

    • When the application is booted and the device is unprovisioned, the trigger is activated.

    • When the FHN provisioning is started, the trigger is deactivated. The button action used to control this trigger state is also disabled at the beginning of the FHN provisioning and gets enabled again once the device becomes unprovisioned.

  • DFU mode trigger that activates upon a DFU mode change.

The locator tag extension that is part of the Fast Pair Advertising Manager module additionally defines and manages the following triggers:

  • FHN provisioning trigger that activates on the Account Key write operation during the FHN provisioning operation.

  • Beacon clock synchronization trigger that activates after the system bootup if the device is provisioned.

If the Fast Pair advertising is enabled, the sample selects the correct advertising mode based on the state of the pairing mode trigger:

  • Fast Pair discoverable advertising - Selected when the trigger is active.

  • Fast Pair not discoverable advertising - Selected when the trigger is inactive.

To fully disable Fast Pair advertising, all trigger requests must be removed. However, you cannot manually disable all triggers, as the FHN provisioning and Beacon clock synchronization triggers are managed by the Fast Pair Advertising Manager module automatically and are required for the sample to work correctly. This approach ensures that Fast Pair advertising remains enabled as long as any of the modules needs it, preventing premature disabling.

The sample automatically disables the advertising by removing the trigger requests after the factory reset operation. To start Fast Pair discoverable advertising after the FHN unprovisioning and factory reset operations, you need to activate the pairing mode trigger.

Note

The Bluetooth advertising is active only until the Fast Pair Provider connects to a Bluetooth Central. Once connected, you can still request to turn on the advertising, but it will only activate after you disconnect.

Device Firmware Update (DFU)

The locator tag sample supports over-the-air updates using MCUmgr’s Simple Management Protocol (SMP) over Bluetooth. The application configures the appropriate DFU solution in relation to the selected board target (see the following table for more details). The following DFU solutions are supported in this sample:

To enable the DFU functionality use the SB_CONFIG_APP_DFU sysbuild Kconfig option. This option is enabled by default if a supported DFU solution is configured (see the following table to learn about supported configurations).

To select a specific version of the application, change the VERSION file in the sample root directory. See the Application version management for details.

Note

Ensure that the FHN firmware version defined by the following Kconfig options matches the version in the VERSION file:

The configuration of the DFU solution varies depending on the board target:

DFU solution

Mode of operation

Board targets

MCUboot

direct-xip mode without revert

  • nrf54l15dk/nrf54l05/cpuapp (only release configuration)

  • nrf54l15dk/nrf54l10/cpuapp

  • nrf54l15dk/nrf54l15/cpuapp

  • nrf54l15tag/nrf54l15/cpuapp

  • nrf54lm20dk/nrf54lm20a/cpuapp

  • nrf54lm20dk/nrf54lm20b/cpuapp

  • nrf54ls05dk/nrf54ls05a/cpuapp (only release configuration)

  • nrf54ls05dk/nrf54ls05b/cpuapp (only release configuration)

Signature algorithm

Each board target that is supported by this sample, sets a specific signature algorithm for its DFU functionality. The signature algorithm determines the type of the key pair that is used to automatically sign the application image by the nRF Connect SDK build system (the private key) and to verify the application image by the bootloader (the public key). The bootloader must have access to the public key for its image verification process. The choice of the signature algorithm and the implementation of the public key storage solution have an impact on the security properties of the overall DFU solution.

The configuration of the signature algorithm and the public key storage solution in this sample varies depending on the board target:

Signature algorithm

Board targets

Public key storage

Properties

ECDSA-P256

  • nrf54ls05dk/nrf54ls05a/cpuapp (only release configuration)

  • nrf54ls05dk/nrf54ls05b/cpuapp (only release configuration)

Bootloader partition

SW calculation, Signature derived from image hash

ED25519

  • nrf54l15dk/nrf54l05/cpuapp (only release configuration)

  • nrf54l15dk/nrf54l10/cpuapp

  • nrf54l15dk/nrf54l15/cpuapp

  • nrf54l15tag/nrf54l15/cpuapp

  • nrf54lm20dk/nrf54lm20a/cpuapp

  • nrf54lm20dk/nrf54lm20b/cpuapp

Key Management Unit (KMU)

HW-accelerated (CRACEN), Signature derived from image (pure)

Each supported board target has the signature key file (the SB_CONFIG_BOOT_SIGNATURE_KEY_FILE Kconfig option) defined in the sysbuild/configuration directory that is part of the sample directory. The signature key file is unique for each board target and is located in the <board_target> subdirectory. For example, the signature key file for the nrf54l15dk/nrf54l15/cpuapp board target is located in the sysbuild/configuration/nrf54l15dk_nrf54l15_cpuapp subdirectory.

Important

The signature private keys defined by the sample are publicly available and intended for demonstration purposes only. For production purposes, you must create and use your own signature key file that must be stored in a secure location.

DFU mode

You can perform the DFU procedure by entering the DFU mode for a limited time. The DFU mode is accessible regardless of the current FHN provisioning state.

This mode allows the connected peer to access the SMP GATT Service. Access to this service is restricted only to the DFU mode as a security measure. This restriction helps satisfy FHN privacy requirements, which prohibit the locator tag device from sharing identifying information, such as firmware version, with connected peers during standard operation. Moreover, after entering the DFU mode, the SMP GATT Service UUID is present in the Fast Pair advertising payload which helps to filter and find the devices that are in the DFU mode. It is located in advertising data when Fast Pair advertising is in the discoverable mode, or in the scan response data when it is in the not discoverable mode.

Android notifications about firmware updates

You can receive Android notifications about the new firmware version for your accessory if you add it during the FHN provisioning process to the Find Hub app of your Android device. The subsequent sections highlight the most important details to have this feature work properly.

The default device model for this sample is configured to support the Android intent feature for firmware updates (the Firmware Type option) and to use the nRF Connect Device Manager application as the Android companion application for this accessory firmware. See the Fast Pair device registration section for configuration details.

This sample also supports the firmware version read operation over Bluetooth and the GATT Device Information Service (DIS). This mechanism is used by the Android device to read the local firmware version of the Fast Pair accessory in the following cases:

  • During the Fast Pair procedure and the FHN provisioning operation.

  • Asynchronously every 24 hours in the FHN provisioning state.

Whenever the Android device reads the local firmware version of this Fast Pair accessory, it compares the local version with the version registered in the Firmware Version field of the Google Nearby Console. If the local version is different than the registered version, the Android device generates the firmware update intent that is sent to the nRF Connect Device Manager application. Then, the nRF Connect Device Manager application processes the intent and displays the user notification about the new firmware version available for this accessory.

Note

The example code for handling the Fast Pair firmware update intents in the Android companion application is available in the nRF Connect Device Manager GitHub repository. The code has been added as part of the nRF Connect Device Manager GitHub PR with support for Fast Pair firmware update intents.

To learn more about the Android intent feature for firmware updates, see the Firmware update intent section in the Fast Pair user guide.

Fast Pair device registration

Before you can use your device as a Fast Pair Provider, the device model must be registered with Google. This is required to obtain the Model ID and Anti-Spoofing Private Key. You can either register your own device or use the debug Model ID and Anti-Spoofing Public/Private Key pair obtained by Nordic Semiconductor for development purposes.

Note

To support the locator tag use case, you must select Locator Tag option in the Device Type list when registering your device model. To use the FHN extension, you must also set the Find My Device option to true during device model registration.

If the Model ID and Anti-Spoofing Private Key are not specified, the following default debug Fast Pair model is used:

  • NCS locator tag:

    • Device Name: NCS locator tag

    • Model ID: 0x4A436B

    • Anti-Spoofing Private Key (Base64, uncompressed): rie10A7ONqwd77VmkxGsblPUbMt384qjDgcEJ/ctT9Y=

    • Device Type: Locator Tag

    • Notification Type: Fast Pair

    • Firmware Version: 99.99.99+0

    • Firmware Type: Non-critical

    • Companion App Package Name: no.nordicsemi.android.nrfconnectdevicemanager

    • Data-Only connection: true

    • No Personalized Name: true

    • Find My Device: true

For details, see Provisioning the device in the Fast Pair user guide.

Important

This is the debug Fast Pair provisioning data obtained by Nordic for the development purposes. Do not use it in production.

To test with the debug mode Model ID, you must configure the Android device to include the debug results while displaying the nearby Fast Pair Providers. For details, see Verifying Fast Pair in the GFPS documentation.

Tip

The sample encodes TX power in the advertising set data that includes the Fast Pair payload. There is no need to provide the TX power value during device model registration.

User interface

The user interface of the sample depends on the hardware platform you are using.

LED 0:

Indicates that the firmware is running and informs about the state of the DFU mode. Depending on the DFU mode state:

  • Blinks at a 1 second interval if the DFU mode is disabled.

  • Blinks at a 0.25 second interval if the DFU mode is enabled.

LED 1:

Depending on the motion detected event, the ringing state, and the motion detector state:

  • Blinks fast twice if the motion detected event appears.

  • Lit if the device is ringing and no motion detection event is being indicated.

  • Blinks at a 0.25 second interval if the motion detector is active and none of the above conditions are met.

  • Off if none of the above conditions are met.

LED 2:

Depending on the FHN provisioning state and the Fast Pair advertising state:

  • Lit if the device is provisioned and Fast Pair advertising is disabled.

  • Blinks at a 0.25 second interval if the device is provisioned and Fast Pair advertising is enabled.

  • Blinks at a 1 second interval if the device is not provisioned and Fast Pair advertising is enabled.

  • Off if the device is not provisioned and Fast Pair advertising is disabled.

LED 3:

Depending on the states of the recovery mode and the identification mode:

  • Lit if both modes are active on the device.

  • Off if both modes are inactive on the device.

  • Blinks at a 0.5 second interval if the identification mode is active on the device and the recovery mode is inactive on the device.

  • Blinks at a 1 second interval if the recovery mode is active on the device and the identification mode is inactive on the device.

Button 0:

Sends a request to turn on Fast Pair discoverable advertising or removes such a request. This action controls the pairing mode trigger. It is enabled only in the FHN unprovisioned state and is disabled immediately once the FHN provisioning is started. See the Fast Pair advertising policy section for details.

Button 1:

Stops the ongoing ringing action on a single press. Generates simulated motion event on a double press.

Button 2:

Decrements the battery level by 10% (the default value in the CONFIG_APP_BATTERY_LEVEL_DECREMENT Kconfig option), starting from the full battery level of 100%. In the default sample configuration, with the CONFIG_BT_FAST_PAIR_FHN_BATTERY_DULT Kconfig option enabled, pressing the button when the battery level is lower than the decrement value transitions the device back to the starting point of 100%. You can disable the default CONFIG_BT_FAST_PAIR_FHN_BATTERY_DULT Kconfig setting to transition through the mode in which the battery level indication is not supported (refer to the last point in the list). The battery level is encoded in the FHN advertising set according to the following rules:

  • Normal battery level (starting point, as derived from the 100% battery level) - The battery level is higher than 40% and less than or equal to 100%. The lower threshold, 40%, is controlled by the CONFIG_BT_FAST_PAIR_FHN_BATTERY_LEVEL_LOW_THR Kconfig option.

  • Low battery level - The battery level is higher than 10% and less than or equal to 40%. The lower threshold, 10%, is controlled by the CONFIG_BT_FAST_PAIR_FHN_BATTERY_LEVEL_CRITICAL_THR Kconfig option.

  • Critically low battery level (battery replacement needed soon) - The battery level is higher than or equal to 0% and less than or equal to 10%.

  • Battery level indication unsupported - Occurs when the special BT_FAST_PAIR_FHN_BATTERY_LEVEL_NONE value is used. This battery level is unavailable in the default sample configuration. You can disable the CONFIG_BT_FAST_PAIR_FHN_BATTERY_DULT Kconfig option to reach this mode when transitioning from the critically low battery level to the full battery level of 100%.

In the default sample configuration, with the CONFIG_BT_FAST_PAIR_FHN_BATTERY_DULT Kconfig option enabled, the battery level is also encoded in the Battery Level response of the Accessory Non-owner Service (ANOS), which is set according to the following rules:

  • Full battery level (starting point, as derived from the 100% battery level) - The battery level is higher than 80% and less than or equal to 100%. The lower threshold, 80%, is controlled by the CONFIG_DULT_BATTERY_LEVEL_MEDIUM_THR Kconfig option.

  • Medium battery level - The battery level is higher than 40% and less than or equal to 80%. The lower threshold, 40%, is controlled by the CONFIG_DULT_BATTERY_LEVEL_LOW_THR Kconfig option.

  • Low battery level - The battery level is higher than 10% and less than or equal to 40%. The lower threshold, 10%, is controlled by the CONFIG_DULT_BATTERY_LEVEL_CRITICAL_THR Kconfig option.

  • Critically low battery level (battery replacement needed soon) - The battery level is higher than or equal to 0% and less than or equal to 10%.

Button 3:

When pressed during the application bootup, resets the accessory to its default factory settings.

The triggered action varies depending on how long the button was held:

  • From 0 to 3 seconds:

    Requests the FHN subsystem to enable the identification mode for five minutes. This timeout value is defined by the CONFIG_DULT_ID_READ_STATE_TIMEOUT Kconfig option according to the DULT specification requirements.

  • From 3 to 7 seconds:

    Enables the recovery mode for one minute as defined by the CONFIG_BT_FAST_PAIR_FHN_READ_MODE_FHN_RECOVERY_TIMEOUT Kconfig option.

  • From 7 seconds or more:

    Enables the DFU mode for five minutes.

Configuration

See Configuring and building for information about how to permanently or temporarily change the configuration.

Configuration options

The following Kconfig options are specific to the Fast Pair locator tag sample.

SB_CONFIG_APP_DFU

The sample sysbuild configuration option enables the Device Firmware Update (DFU) functionality. The value of this option is propagated to the application configuration option CONFIG_APP_DFU. This option is enabled by default if the MCUboot bootloader image is used (SB_CONFIG_BOOTLOADER_MCUBOOT).

CONFIG_APP_DFU

The sample application configuration option enables the Device Firmware Update (DFU) functionality. The value of this option is set based on the sysbuild configuration option SB_CONFIG_APP_DFU.

CONFIG_APP_RANGING

The sample application configuration option enables the ranging module that demonstrates the Precision Finding with Bluetooth Low Energy Channel Sounding (CS) as the ranging technology. This option is enabled by default on board targets that provide hardware support for Bluetooth Low Energy CS (the HAS_HW_NRF_RADIO_CS Kconfig option). See the Precision Finding section for more details.

The following Kconfig options are specific to the chosen hardware platform.

CONFIG_APP_BATTERY_LEVEL_DECREMENT

The sample configuration defines the decrement value used to simulate the battery level on the development kit. The battery level is defined in percentages and ranges from 0% to 100%. By default, the decrement level is set to 10%.

Building and running

This sample can be found under samples/bluetooth/fast_pair/locator_tag in the nRF Connect SDK folder structure.

To build the sample, follow the instructions in Building an application for your preferred building environment. See also Programming an application for programming steps and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.

Note

When building repository applications in the SDK repositories, building with sysbuild is enabled by default. If you work with out-of-tree freestanding applications, you need to manually pass the --sysbuild parameter to every build command or configure west to always use it.

When building the sample, you can provide the Fast Pair Model ID (SB_CONFIG_BT_FAST_PAIR_MODEL_ID) and the Fast Pair Anti-Spoofing Key (SB_CONFIG_BT_FAST_PAIR_ANTI_SPOOFING_PRIVATE_KEY) as sysbuild Kconfig options. If the data is not provided, the sample uses the default provisioning data obtained for the NCS locator tag (the locator tag debug Fast Pair Provider). See Provisioning the device for details.

Note

You cannot use the sample without the Fast Pair provisioning data. Programming the device with the sample firmware without providing the proper Fast Pair provisioning data results in assertion failure during boot.

Release build

To build the sample in a release variant, set the FILE_SUFFIX=release CMake option. The build will use the prj_release.conf configuration file instead of prj.conf. Check the contents of both files to learn which configuration changes you should apply when preparing the production build of your end product.

The release build reduces the code size and RAM usage of the sample by disabling logging functionality and performing other optimizations.

See Providing CMake options for detailed instructions on how to add the FILE_SUFFIX=release option to your build. For example, when building from the command line, you can add it as follows:

west build -b board_target -- -DFILE_SUFFIX=release

DFU build with the key storage in KMU

The MCUboot-based targets that enable the SB_CONFIG_MCUBOOT_SIGNATURE_USING_KMU Kconfig option use the Key Management Unit (KMU) hardware peripheral to store the public key that is used by the bootloader to verify the application image.

Note

The board targets based on the nRF54L SoC Series are currently the only targets that support the KMU-based key storage. See the Device Firmware Update (DFU) section of this sample documentation for the details regarding the supported signature algorithms, public key storage location and the signature key file.

To use KMU, the public key must first be provisioned. This provisioning step can be performed automatically by the west runner, provided that a keyfile.json file is present in the build directory. In this sample, the keyfile.json file is automatically generated using the SB_CONFIG_MCUBOOT_GENERATE_DEFAULT_KEY_FILE Kconfig option. This option uses the input key specified by the SB_CONFIG_BOOT_SIGNATURE_KEY_FILE Kconfig option to generate the required file during the build process.

To trigger KMU provisioning during flashing, use the west flash command with either the --erase or --recover flag. This ensures that both the firmware and the MCUboot public key are correctly programmed onto the target device using KMU-based key storage. Use the following command to perform the operation:

west flash --recover

Alternatively, you can perform the provisioning operation manually with the west ncs-provision upload command and then flash the device with the west flash command. See Provisioning the KMU for further details regarding the KMU provisioning process.

Motion detector test build

If you want to make testing the motion detector easier, enable the CONFIG_DULT_MOTION_DETECTOR_TEST_MODE Kconfig option to shorten the period between the device entering the Unwanted Tracking Protection mode and the activation of the motion detector. With this option enabled, the values of the CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MIN and CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MAX Kconfig options that are responsible for this period are shortened to three minutes. Otherwise, the period would be a random value between 8 and 24 hours. The CONFIG_DULT_MOTION_DETECTOR_TEST_MODE Kconfig option also shortens the motion detector backoff period (CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_BACKOFF_PERIOD) from six hours to two minutes.

See Configuring Kconfig for detailed instructions on how to enable the CONFIG_DULT_MOTION_DETECTOR_TEST_MODE Kconfig option in your build. For example, when building from the command line, you can enable it as follows:

west build -b board_target -- -DCONFIG_DULT_MOTION_DETECTOR_TEST_MODE=y

Testing

Note

Images in the testing section are generated for the debug device model registered by Nordic Semiconductor in the Google Nearby Console (see Fast Pair device registration). The debug device model name is covered by asterisks and the default Fast Pair logo is displayed instead of the one specified during the device model registration.

If the test Android device uses a primary email account that is not on Google’s email allowlist for the FHN feature, testing steps will fail at the FHN provisioning stage for the default debug (uncertified) device model. To be able to test with debug device models and use the “Inspect Spot device” tool in the Find Hub app, register your development email account by completing Google’s device proposal form. You can find the link to the device proposal form in the Fast Pair Find Hub Network extension specification.

After programming the sample to your development kit, complete the following steps to test it:

  1. Connect to the kit that runs this sample with a terminal emulator (for example, the Serial Terminal app). See Testing and optimization for the required settings and steps.

  2. Reset the development kit.

  3. Observe that LED 0 is blinking to indicate that firmware is running.

  4. Observe that LED 2 is blinking in 1 second intervals, which indicates that the device is not provisioned as an FHN beacon and the Fast Pair discoverable advertising is enabled. The Fast Pair Provider is ready for the FHN provisioning.

  5. Move the Android device close to your locator tag device.

  6. Wait for the notification from your Android device about the detected Fast Pair Provider.

    Fast Pair discoverable notification with support for the `Find Hub app`_

  7. Initiate the connection and trigger the Fast Pair procedure by tapping the Connect button. After the procedure is complete, you will see a pop-up with the Acceptable Use Policy for the Find Hub app.

    Note

    If you use the default debug device model and you have the nRF Connect Device Manager application installed on your test Android device, you may get the Android notification from this mobile application about the new firmware update. You can ignore this notification, as it is not related to the Fast Pair provisioning process. To test the notification feature, follow the Android notifications about firmware updates test section.

  8. If you want to start the FHN provisioning, accept the Acceptable Use Policy by tapping the Agree and continue button.

    The Find Hub Acceptable Use Policy

  9. Wait for the Android device’s notification that indicates completion of the provisioning process.

    Notification about provisioning completion for the `Find Hub app`_

  10. Observe that LED 2 is lit, which indicates that the device is provisioned as an FHN beacon and the Fast Pair advertising is disabled.

  11. Open the Find Hub app by tapping the Open app button.

  12. In your accessory view, tap the Find nearby button.

  13. Observe in the Find nearby view that the grey shape shrinks when you move your Android device further away from your locator tag device. The shape also grows when you move your Android device closer to the locator tag. The closest proximity level is indicated by the device logo displayed inside the grey shape.

    Find nearby view of the `Find Hub app`_

    Note

    If the Precision Finding is enabled for the chosen board target and you use the Android test device with the Bluetooth Low Energy CS support, the Find nearby view may also display the estimated distance from the locator tag in meters. See the Precision Finding section for comprehensive testing steps of this feature.

  14. Start the ringing action on your device by tapping the Play sound button.

  15. Observe that LED 1 is lit, which indicates that the ringing action is in progress.

  16. Stop the ringing action in one of the following ways:

    • Press Button 1 on the locator tag device.

    • Tap the Stop sound button in the Find Hub app.

  17. Observe that LED 1 is off, which indicates that your accessory is no longer ringing.

  18. Press Button 2 a few times to change the normal (default) battery level to low battery level.

  19. See that the Android notification with the Device with low battery label is displayed after a while.

  20. Exit the Find nearby view and return to the main accessory view.

  21. Open Device details by tapping the cog icon, located below the map view, next to the accessory name.

  22. Start the unprovisioning operation by tapping the Remove from Find Hub button at the bottom of the screen.

  23. Confirm the operation by tapping the Remove button in the Remove from Find Hub view.

    Remove from Find Hub view

  24. Reconfirm the procedure by tapping the Remove button in the Android pop-up window.

  25. Wait for the unprovisioning operation to complete.

  26. Observe that LED 2 is off, which indicates that the device is no longer provisioned as an FHN beacon and the Fast Pair advertising is disabled.

  27. Observe that the Android does not display a notification about the detected Fast Pair Provider, as the locator tag device disables advertising after the unprovisioning operation.

  28. Press Button 0 to request turning on the Fast Pair advertising in discoverable mode and to restart the FHN provisioning process.

Precision Finding

Testing the Precision Finding requires a board target that supports Bluetooth Low Energy Channel Sounding. See the Precision Finding section for the list of supported board targets. Currently, only selected nRF54 Series DKs support Bluetooth Low Energy CS for this testing scenario.

Note

The Precision Finding with Bluetooth Low Energy CS as the ranging technology requires an Android test device with hardware and software support for Bluetooth Low Energy Channel Sounding.

As of the beginning of the second quarter of 2026, Precision Finding support using Bluetooth Low Energy Channel Sounding as the ranging technology is not publicly available on Android platforms. However, you can experiment with this configuration on Android test devices that provide hardware and software support for Bluetooth Low Energy Channel Sounding (for example, Google Pixel 10), provided that the following requirements are met:

  • The target Android device must run Android QPR3 Beta 2 (January 2026) or a later release.

  • Google Play Services must not be enrolled in its independent beta program.

  • The primary email account on the Android test device must be registered on Google’s allowlist for this feature. To add a test email address to the allowlist, contact the Google team to request approval.

To test this feature, complete the following steps:

  1. Go to the Testing section and follow the instructions on performing the FHN provisioning operation.

  2. Observe that a Bluetooth bond was created during the Fast Pair procedure. The following log message in the terminal confirms that the bonding was successful:

    Ranging: pairing completed (bonded) with ...

  3. Observe that LED 2 is lit, which indicates that the device is provisioned as an FHN beacon.

  4. Open the Find Hub app by tapping the Open app button.

  5. In your accessory view, tap the Find nearby button.

  6. Wait for the Bluetooth Low Energy CS ranging session to be established. In the terminal, observe the log messages confirming that the ranging capability exchange and configuration have been completed. The following key log messages indicate that the ranging session has been successfully configured and started:

    Ranging: Ranging Configuration Response message to (...)
         Ranging technologies configuration set successfully bitfield 0x0002:
         (...) BLE CS=(X) (...)

    Verify that the bitfield value includes the Bluetooth Low Energy CS bit (0x0002) to confirm that the Bluetooth Low Energy CS technology has been successfully configured and started.

  7. Observe in the Find nearby view that the grey shape shrinks when you move your Android device further away from your locator tag device. The shape also grows when you move your Android device closer to the locator tag. With Bluetooth Low Energy CS enabled, the Find Hub app additionally displays the estimated distance from the locator tag in meters in the center of the shape. The distance updates as you adjust your position relative to the locator tag. The distance value is not displayed when the locator tag is within approximately 1 meter range from the Android device.

  8. Hold your phone straight up and try moving around. Observe that both the shape size and the displayed distance value change as you move closer to or further away from the locator tag.

  9. Exit the Find nearby view and return to the main accessory view. In the terminal, observe the log messages confirming that the ranging session has been stopped:

    Ranging: Stop Ranging Response message to (...)
         Ranging technologies stopped successfully bitfield 0x0002:
         (...) BLE CS=(X) (...)

    Verify that the bitfield value includes the Bluetooth Low Energy CS bit (0x0002) to confirm that the Bluetooth Low Energy CS technology has been successfully stopped.

Clock synchronization

Testing steps for the clock synchronization feature require a second Android device. The device must be registered to a different Google account from the first Android device. Testing steps also require the nRF Connect for Mobile application on your second Android device.

Note

You can execute these testing steps in combination with the Android notifications about firmware updates testing steps, as both test variants require you to wait for more than 24 hours.

To test this feature, complete the following steps:

  1. Go to the Testing section and follow the instructions on performing the FHN provisioning operation.

  2. Observe that LED 2 is lit, which indicates that the device is provisioned as an FHN beacon.

  3. Power off the development kit and wait for 24 hours.

  4. Power off the Android device that you used to perform the FHN provisioning operation.

  5. Power on the development kit.

  6. Connect to the kit that runs this sample with a terminal emulator (for example, the Serial Terminal app). See Testing and optimization for the required settings and steps.

  7. Use your second Android device configured for a different account, and start the nRF Connect for Mobile application.

  8. Wait for the SCANNER tab of the mobile application to populate the scanning list.

  9. Observe that the device advertising the Fast Pair Service UUID (0xFE2C) AD type with the Fast Pair Account Data payload is present in the scanning list. This entry indicates that the development kit is in the clock synchronization mode, and it is advertising the Fast Pair not discoverable payload.

    Note

    By default, the nRF Connect for Mobile application filters advertising packets used by ecosystems like Google or Apple. You need to take additional steps to see the Fast Pair advertising on the scanning list:

    1. In the SCANNER tab of the nRF Connect for Mobile application, tap the No filter white bar below the SCANNER label.

    2. In the drop-down menu for the filtering configuration, tap the three-dot icon in the Exclude option.

    3. In the exclude configuration menu, uncheck the Google option to remove the filtering for Google-related advertising like the Fast Pair advertising.

    4. Close the exclude configuration menu and the filtering configuration drop-down.

    5. Tap the SCAN button to restart the scanning activity.

  10. Power on the first Android device that you used to perform the FHN provisioning operation.

  11. In the terminal, observe the message confirming that your first Android device connected to the development kit and synchronized the clock value:

    FHN: clock information synchronized with the authenticated Bluetooth peer

  12. Go back to your second Android device and refresh the scanning list in the nRF Connect for Mobile application.

  13. Observe that the entry for the device advertising the Fast Pair Service UUID AD type is no longer present in the scanning list. The missing entry indicates that the development kit is no longer in the clock synchronization mode, and it is not advertising the Fast Pair not discoverable payload.

  14. In your first Android device, open the Find Hub app. Navigate to your accessory view, and tap the Find nearby button.

  15. Start the ringing action on your device by tapping the Play sound button.

  16. Observe that LED 1 is lit to confirm that the Android device is able to connect to your development kit after a clock synchronization.

Motion detector

To test this feature, complete the following steps:

  1. Enable the CONFIG_DULT_MOTION_DETECTOR_TEST_MODE Kconfig option in the sample configuration to shorten the motion detector activation periods. Refer to the Motion detector test build section for details on how to build the sample in the motion detector test mode.

  2. Build and flash the application in the motion detector test mode on your target device.

  3. Go to the Testing section and follow the instructions on performing the FHN provisioning operation.

  4. Observe that LED 2 is lit, which indicates that the device is provisioned as an FHN beacon.

  5. Double-click Button 1 to simulate the motion event.

  6. Observe that LED 1 blinks fast twice, which indicates that the motion detected event appears.

  7. Observe that the ringing action does not start, because the motion detector is inactive.

  8. Put the device into the Unwanted Tracking Protection mode. You can do it in two ways. If you have access to the “Inspect Spot device” tool in the Find Hub Android app, you can:

    1. Open the Find Hub app.

    2. Tap your accessory in the list. The accessory should have “Nearby” written under its name.

    3. Tap the gear icon next to the device name

    4. Tap the 3-dot menu and then Inspect Spot device (internal).

    5. Tap the 3-dot menu and then Activate Unwanted Tracking Mode.

    6. Observe the “Changed unwanted tracking mode successfully” message on the screen.

    7. Turn off your Android device to prevent it from automatically deactivating the mode. Do this as quickly as possible after activating the mode.

    Otherwise, you can:

    1. Turn off your Android device.

    2. Wait for minimum 30 minutes for other Android device to put the device into the Unwanted Tracking Protection mode. The other Android device can belong to anyone around you. It is recommended to be in a crowded area.

  9. Wait for three minutes (random value between the CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MIN and CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MAX Kconfig options) for the motion detector to be activated.

  10. Observe that LED 1 blinks at a 0.25 second interval, which indicates that the motion detector is active.

  11. Double-click Button 1 to simulate the motion event.

  12. Observe that LED 1 blinks fast twice, which indicates that the motion detected event appears.

  13. Observe that after up to 10 seconds, the ringing action starts for one second, which is indicated by LED 1 being lit.

  14. Observe that LED 1 goes back to blinking at a 0.25 second interval, which indicates that the motion detector is active.

  15. Double-click Button 1 to simulate the motion event.

  16. Observe that LED 1 blinks fast twice, which indicates that the motion detected event appears.

  17. Observe that after up to 0.5 second, the ringing action starts for one second, which is indicated by LED 1 being lit.

  18. Observe that LED 1 goes back to blinking at a 0.25 second interval, which indicates that the motion detector is active.

  19. Double-click Button 1 to simulate the motion event.

  20. Observe that LED 1 blinks fast twice, which indicates that the motion detected event appears.

  21. Observe that after up to 0.5 second, the ringing action starts, which is indicated by LED 1 being lit.

  22. Double-click Button 1 to simulate the motion event while the LED 1 is still lit (ringing action is still in progress).

  23. Observe that LED 1 blinks fast twice, which indicates that the motion detected event appears.

  24. Observe that after 0.5 second, of not ringing, the ringing action starts again for one second, which is indicated by LED 1 being lit.

  25. Observe that LED 1 goes back to blinking at a 0.25 second interval, which indicates that the motion detector is active.

  26. Observe that after 20 seconds from the first motion event or after 10 ringing actions completes, the LED 1 is off, which indicates that the motion detector is inactive.

  27. Double-click Button 1 to simulate the motion event.

  28. Observe that LED 1 blinks fast twice, which indicates that the motion detected event appears.

  29. Observe that the ringing action does not start, because the motion detector is inactive.

  30. Wait for two minutes (the backoff period defined by the CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_BACKOFF_PERIOD Kconfig option) for the motion detector to be activated again.

  31. Observe that LED 1 blinks at a 0.25 second interval, which indicates that the motion detector is active.

  32. Double-click Button 1 to simulate the motion event and observe the ringing action just as before.

  33. Wait for 20 seconds for the LED 1 to go off, which indicates that the motion detector is inactive.

  34. Wait for two minutes for the motion detector to be activated again.

  35. Observe that LED 1 blinks at a 0.25 second interval, which indicates that the motion detector is active.

  36. Turn on your Android device.

  37. Observe that after up to few hours the LED 1 goes off, which means that the motion detector has been deactivated, because the device is no longer in the Unwanted Tracking Protection mode.

Performing the DFU procedure

Testing steps for the DFU feature require the nRF Connect Device Manager application on your test Android device.

To perform the DFU procedure, complete the following steps:

  1. Observe that LED 0 is blinking at a 1 second interval, which indicates that the DFU mode is disabled.

  2. Press the Button 3 for 7 seconds or more to enter the DFU mode.

  3. Observe that LED 0 is blinking at a 0.25 second interval, which indicates that the DFU mode is enabled.

  4. Observe that LED 2 is blinking, which indicates that the Fast Pair advertising is enabled.

  5. Perform DFU using the nRF Connect Device Manager mobile app:

    1. Generate the DFU package by building your application with the FOTA support over Bluetooth Low Energy. You can find the generated dfu_application.zip archive in the build directory.

      Note

      For each image included in the DFU-generated package, use a higher version number than your currently active firmware. Otherwise, the DFU target may reject the FOTA process due to a downgrade prevention mechanism.

    2. Download the dfu_application.zip archive to your device. See Output build files (image files) for more information about the contents of update archive.

      Note

      nRF Connect for Desktop does not currently support the FOTA process.

    3. Use the nRF Connect Device Manager mobile app to update your device with the new firmware.

      1. Ensure that you can access the dfu_application.zip archive from your phone or tablet.

      2. In the mobile app, scan and select the device to update.

      3. Switch to the Image tab.

      4. Tap the SELECT FILE button and select the dfu_application.zip archive.

      5. Tap the START button.

        Note

        When performing a FOTA update with the iOS app for samples using random HCI identities, ensure that the Erase application settings option is deselected before starting the procedure. Otherwise, the new image will boot with random IDs, causing communication issues between the app and the device.

      6. Initiate the DFU process of transferring the image to the device:

        • If you are using an Android device, select a mode in the dialog window, and tap the START button.

        • If you are using an iOS device, tap the selected mode in the pop-up window.

        Note

        For samples using random HCI identities, the Test and Confirm mode should not be used.

      7. Wait for the DFU to finish and then verify that the application works properly.

Android notifications about firmware updates

Testing steps for the firmware update notification feature require the nRF Connect Device Manager application on your test Android device.

Note

The support for the Android notifications about the firmware updates in the context of the FHN extension is a new feature. Before you start the testing, ensure that versions for the following applications and services are equal to or greater than the specified minimum versions:

Also, ensure that Android notifications are enabled for the nRF Connect Device Manager application.

Note

You can execute these testing steps in combination with the Clock synchronization testing steps, as both test variants require you to wait for more than 24 hours.

To test this feature, complete the following steps:

  1. Go to the Testing section and follow the instructions on performing the FHN provisioning operation.

  2. Observe that LED 2 is lit, which indicates that the device is provisioned as an FHN beacon.

  3. Power off the development kit and wait for 24 hours.

  4. Power off your test Android device.

  5. Power on the development kit.

  6. Connect to the kit that runs this sample with a terminal emulator (for example, the Serial Terminal app). See Testing and optimization for the required settings and steps.

  7. Power on your test Android device and unlock it after the smartphone screen is turned on.

  8. Wait for the device to automatically connect to the development kit and read the local firmware version in the background.

  9. In the terminal, verify that a message confirming that the firmware version is being read appears:

    DIS Firmware Revision characteristic is being read

  10. Observe that you get the Android notification about the new firmware update on your test Android device.

    Note

    Notification delivery on Android may be delayed due to system conditions or background processing. It is recommended to wait up to five minutes before concluding that this test step has failed.

    Firmware update notification in the Android notification center

  11. Upgrade the sample firmware to the latest version:

    1. Set the application firmware version to v99.99.99 by modifying the following files:

      The new firmware version should match the version specified in the Firmware Version field from the Fast Pair device registration section.

    2. Rebuild the sample application to generate the DFU package.

    3. Follow the instructions from the Performing the DFU procedure section to perform the DFU procedure.

  12. Validate the new firmware version is correct by reading the application boot banner.

  13. Power off the development kit and wait again for 24 hours.

  14. Power off your test Android device.

  15. Power on the development kit.

  16. Connect to the kit that runs this sample with a terminal emulator (for example, the Serial Terminal app). See Testing and optimization for the required settings and steps.

  17. Power on your test Android device and unlock it after the smartphone screen is turned on.

  18. Wait for the device to automatically connect to the development kit and read the local firmware version in the background.

  19. In the terminal, verify that a message confirming that the firmware version is being read appears.

  20. Observe that you no longer get the Android notification about the new firmware update on your test Android device.

Disabling the locator tag

The following instructions on disabling the locator tag apply to the default debug device model registered for this sample (see the Fast Pair device registration section), and are used for demonstration purposes.

To disable the locator tag device, complete the following steps:

  1. Find the power switch on the device.

  2. Turn off the locator tag by sliding the switch to the off position.

  3. Observe that the on-device LEDs are turned off.

Note

Vendor-specific instructions on disabling the unknown trackers are registered on mobile platforms, like Android and iOS, for each device model.

Fast Pair Validator app

You can test the sample against the Eddystone test suite from the Fast Pair Validator app.

Note

To start testing the FHN solution with the Fast Pair Validator app, use your project in the Google Nearby Console and the Fast Pair device model that is defined in the scope of your project. The default debug device model from Nordic Semiconductor cannot be used for this purpose. Additionally, you must sign into the Fast Pair Validator app using an email address associated with your project in the Google Nearby Console.

After programming the sample to your development kit, complete the following steps to test it:

  1. Open the Fast Pair Validator app on your Android device.

  2. In the app list, tap on the target device model that matches your flashed firmware.

  3. Select the correct test category by tapping the EDDYSTONE button.

    Test category selection in the Fast Pair Validator app

  4. In the Eddystone test view, choose a test case by tapping the START button next to it.

    Eddystone test suite in the Fast Pair Validator app

  5. In the chosen test view, run the test case by tapping the TEST button.

  6. Follow the pop-up instructions during the test execution.

    Important

    Use your locator tag device button interface to comply with the instructions during the test execution:

    • Please put the headset into pairing mode - Ensure that your device advertises in the Fast Pair discoverable mode or switch to this mode by pressing Button 0.

    • After you close this dialog, as soon as you hear device ringing, press a button on the device to stop ringing - Stop the ringing action by pressing Button 1 once the LED 1 is lit.

    • Before you close this dialog, press the button on the device to allow reading its identifier - Enter the identification mode by shortly pressing Button 3. The LED 3 should start blinking at half-second intervals after the button press.

  7. Wait until the test case execution completes.

    Successful execution of the provisioning test case in the Fast Pair Validator app

  8. Exit the test case view by tapping on the cross icon in the upper left corner.

  9. Start another test case or exit the Fast Pair Validator app.

    Note

    Each test case is concluded with the unprovisioning operation that disables the Fast Pair advertising in the discoverable mode. To set your locator tag device back into the pairing mode, press Button 0.

Dependencies

The sample uses subsystems and firmware components available in the nRF Connect SDK. For details, see the following sections.

Fast Pair GATT Service

This sample uses the Google Fast Pair Service (GFPS) and its dependencies and is configured to meet the requirements of the Fast Pair standard together with its FHN extension. For details about integrating Fast Pair in the nRF Connect SDK, see Google Fast Pair integration.

By default, this sample sets the SB_CONFIG_BT_FAST_PAIR_MODEL_ID and SB_CONFIG_BT_FAST_PAIR_ANTI_SPOOFING_PRIVATE_KEY Kconfig options to use the Nordic device model that is intended for demonstration purposes. With these options set, the build system calls the Fast Pair provision script that automatically generates a hexadecimal file containing Fast Pair Model ID and the Anti-Spoofing Private Key. For more details about enabling Fast Pair for your application, see the Enabling Fast Pair in Kconfig section in the Fast Pair integration guide.

Bluetooth LE advertising data providers

The Bluetooth LE advertising providers are used to generate Bluetooth advertising and scan response data for the Fast Pair advertising set. The sample uses the following providers to generate the advertising packet payload:

The sample uses the Bluetooth device name provider (CONFIG_BT_ADV_PROV_DEVICE_NAME) provider to generate the scan response data.

When the DFU functionality is enabled (CONFIG_APP_DFU), the sample uses the SMP GATT Service UUID provider. The SMP UUID is placed in the advertising data when Fast Pair advertising is in the discoverable mode, or in the scan response data when it is in the not discoverable mode.

Precision Finding

When you enable the CONFIG_APP_RANGING Kconfig option, the sample uses the following components for the Precision Finding:

Device Firmware Update (DFU)

This sample uses the following components for the DFU functionality: