nRF5340 Audio configuration and testing

The nRF5340 Audio application has the following unique characteristics:

• It is developed for use only with the nRF5340 Audio development kit.

• In its default configuration, the application requires the LC3 software codec.

• The application also comes with various application-specific tools, including the buildprog.py Python script that simplifies building and programming the firmware.

Requirements

The nRF5340 Audio application is designed to be used only with the following hardware:

Hardware platforms	PCA	Board name	Build target
nRF5340 Audio DK	PCA10121 revision 1.0.0 or above	nrf5340_audio_dk_nrf5340	nrf5340_audio_dk_nrf5340_cpuapp

Note

The application supports PCA10121 revisions 1.0.0 or above. The application is also compatible with the following pre-launch revisions:

• Revisions 0.8.0 and above.

You need at least two nRF5340 Audio development kits (one with the gateway firmware and one with headset firmware) to test the application. For CIS with TWS in mind, three kits are required.

Software codec requirements

The nRF5340 Audio application only supports the LC3 software codec, developed specifically for use with LE Audio.

nRF5340 Audio development kit

The nRF5340 Audio development kit is a hardware development platform that demonstrates the nRF5340 Audio application. Read the nRF5340 Audio DK Hardware documentation on Nordic Semiconductor Infocenter for more information about this development kit.

nRF5340 Audio configuration files

The nRF5340 Audio application uses Kconfig.defaults files to change configuration defaults automatically, based on the different application versions and device types.

Only one of the following .conf files is included when building:

• prj.conf is the default configuration file and it implements the debug application version.

• prj_release.conf is the optional configuration file and it implements the release application version. No debug features are enabled in the release application version. When building using the command line, you must explicitly specify if prj_release.conf is going to be included instead of prj.conf. See Building and running for details.

Requirements for FOTA

To test Firmware Over-The-Air (FOTA), you need an Android or iOS device with the nRF Connect Device Manager app installed.

If you want to do FOTA upgrades for the application core and the network core at the same time, you need an external flash shield. See Configuring FOTA upgrades for more details.

User interface

The application implements a simple user interface based on the available PCB elements. You can control the application using predefined switches and buttons while the LEDs display information.

Switches

The application uses the following switches on the supported development kit:

Switch	Function
POWER	Turns the development kit on or off.
DEBUG ENABLE	Turns on or off power for debug features. This switch is used for accurate power and current measurements.

Buttons

The application uses the following buttons on the supported development kit:

Button	Function
VOL-	Depending on the moment it is pressed: Long-pressed during startup: Changes the headset to the left channel one. Pressed on the headset or the CIS gateway during playback: Turns the playback volume down (and unmutes).
VOL+	Depending on the moment it is pressed: Long-pressed during startup: Changes the headset to the right channel one. Pressed on the headset or the CIS gateway during playback: Turns the playback volume up (and unmutes).
PLAY/PAUSE	Starts or pauses the playback.
BTN 4	Depending on the moment it is pressed: Long-pressed during startup: Turns on the DFU mode, if the device is configured for it. Pressed on the gateway during playback: Sends a test tone generated on the device. Use this tone to check the synchronization of headsets. Pressed on the gateway during playback multiple times: Changes the tone frequency. The available values are 1000 Hz, 2000 Hz, and 4000 Hz. Pressed on a BIS headset during playback: Change audio stream, if more than one is available.
BTN 5	Depending on the moment it is pressed: Long-pressed during startup: Clears the previously stored bonding information. Pressed during playback: Mutes the playback volume. Pressed on a BIS headset during playback: Change the gateway, if more than one is available.
RESET	Resets the device to the originally programmed settings. This reverts any changes made during testing, for example the channel switches with VOL buttons.

LEDs

To indicate the tasks performed, the application uses the LED behavior described in the following table:

LED	Indication
LED1	Off - No Bluetooth connection.
	Blinking blue - Depending on the device and the mode: Headset: Kits have started streaming audio (BIS and CIS modes). Gateway: Kit has connected to a headset (CIS mode) or has started broadcasting audio (BIS mode).
	Solid blue - Headset, depending on the mode: Kits have connected to the gateway (CIS mode) or found a broadcasting stream (BIS mode).
LED2	Off - Sync not achieved.
	Solid green - Sync achieved (both drift and presentation compensation are in the LOCKED state).
LED3	Blinking green - The nRF5340 Audio DK application core is running.
CODEC	Off - No configuration loaded to the onboard hardware codec.
	Solid green - Hardware codec configuration loaded.
RGB1 (bottom side LEDs around the center opening)	Solid green - The device is programmed as the gateway.
	Solid blue - The device is programmed as the left headset.
	Solid magenta - The device is programmed as the right headset.
	Solid yellow - The device is programmed with factory firmware. It must be re-programmed as gateway or headset.
	Solid red (debug mode) - Fault in the application core has occurred. See UART log for details and use the RESET button to reset the device. In the release mode, the device resets automatically with no indication on LED or UART.
RGB 2	Controlled by the Bluetooth LE Controller on the network core.
	Blinking green - Ongoing CPU activity.
	Solid red - Error.
	Solid white (all colors on) - The RGB 2 LED is not initialized by the Bluetooth LE Controller.
ERR	PMIC error or a charging error (or both). Also turns on when charging the battery exceeds seven hours, since the PMIC has a protection timeout, which stops the charging.
CHG	Off - Charge completed or no battery connected.
	Solid yellow - Charging in progress.
OB/EXT	Off - No 3.3 V power available.
	Solid green - On-board hardware codec selected.
	Solid yellow - External hardware codec selected. This LED turns solid yellow also when the devices are reset, for the time then pins are floating.
FTDI SPI	Off - No data is written to the hardware codec using SPI.
	Yellow - The same SPI is used for both the hardware codec and the SD card. When this LED is yellow, the shared SPI is used by the FTDI to write data to the hardware codec.
IFMCU (bottom side)	Off - No PC connection available.
	Solid green - Connected to PC.
	Rapid green flash - USB enumeration failed.
HUB (bottom side)	Off - No PC connection available.
	Green - Standard USB hub operation.

Configuration

See Configuring your application for information about how to permanently or temporarily change the configuration.

Selecting the BIS mode

The CIS mode is the default operating mode for the application. To switch to the BIS mode, set the CONFIG_TRANSPORT_BIS Kconfig option to y in the prj.conf file for the debug version and in the prj_release.conf file for the release version.

Enabling the BIS mode with two gateways

In addition to the standard BIS mode with one gateway, you can also add a second gateway device that the BIS headsets can receive audio stream from. To configure the second gateway, add both the CONFIG_TRANSPORT_BIS and the CONFIG_BT_AUDIO_USE_BROADCAST_NAME_ALT Kconfig options set to y to the prj.conf file for the debug version and to the prj_release.conf file for the release version. You can provide an alternative name to the second gateway using the CONFIG_BT_AUDIO_BROADCAST_NAME_ALT or use the default alternative name.

You build each BIS gateway separately using the normal procedures from Building and running. After building the first gateway, configure the required Kconfig options for the second gateway and build the second gateway firmware. Remember to program the two firmware versions to two separate gateway devices.

Selecting the CIS bidirectional communication

The CIS unidirectional mode is the default operating mode for the application. To switch to the bidirectional mode, set the CONFIG_STREAM_BIDIRECTIONAL Kconfig option to y in the prj.conf file (for the debug version) or in the prj_release.conf file (for the release version).

Enabling the walkie-talkie demo

The walkie-talkie demo uses one or two bidirectional streams from the gateway to one or two headsets. The PDM microphone is used as input on both the gateway and headset device. To switch to using the walkie-talkie, set the CONFIG_WALKIE_TALKIE_DEMO Kconfig option to y in the prj.conf file (for the debug version) or in the prj_release.conf file (for the release version).

Selecting the I2S serial

In the default configuration, the gateway application uses the USB serial port as the audio source. The Building and running and Testing steps also refer to using the USB serial connection.

To switch to using the I2S serial connection, set the CONFIG_AUDIO_SOURCE_I2S Kconfig option to y in the prj.conf file for the debug version and in the prj_release.conf file for the release version.

When testing the application, an additional audio jack cable is required to use I2S. Use this cable to connect the audio source (PC) to the analog LINE IN on the development kit.

Configuring FOTA upgrades

Caution

Firmware based on the nRF Connect SDK versions earlier than v2.1.0 does not support DFU. FOTA is not available for those versions.

You can test performing separate application and network core upgrades, but for production, both cores must be updated at the same time. When updates take place in the inter-core communication module (HCI RPMsg), communication between the cores will break if they are not updated together.

You can configure Firmware Over-The-Air (FOTA) upgrades to replace the applications on both the application core and the network core. The nRF5340 Audio application supports the following types of DFU flash memory layouts:

• Internal flash memory layout - which supports only single-image DFU.

• External flash memory layout - which supports multi-image DFU.

The LE Audio Controller Subsystem for nRF53 supports both the normal and minimal sizes of the bootloader. The minimal size is specified using the CONFIG_NETBOOT_MIN_PARTITION_SIZE.

Hardware requirements for external flash memory DFU

To enable the external flash DFU, you need an additional flash memory shield. See Requirements for external flash memory DFU in the nRF5340 Audio DK Hardware documentation in Infocenter for more information.

Enabling FOTA upgrades

The FOTA upgrades are only available when Building and programming using script. With the appropriate parameters provided, the buildprog.py Python script will add overlay files for the given DFU type. To enable the desired FOTA functions:

• To define flash memory layout, include the -m internal parameter for the internal layout (when using the release application version) or the -m external parameter for the external layout (when using either release or debug).

• To use the minimal size network core bootloader, add the -M parameter.

For the full list of parameters and examples, see the Running the script section.

FOTA build files

The generated FOTA build files use the following naming patterns:

• For multi-image DFU, the file is called dfu_application.zip. This file updates two cores with one single file.

• For single-image DFU, the bin file for the application core is called app_update.bin. The bin file for the network core is called net_core_app_update.bin. In this scenario, the cores are updated one by one with two separate files in two actions.

See Output build files for more information about the image files.

Note

The network core for both gateway and headsets is programmed with the precompiled Bluetooth Low Energy Controller binary file ble5-ctr-rpmsg_<XYZ>.hex, where <XYZ> corresponds to the controller version, for example ble5-ctr-rpmsg_3216.hex. This file includes the LE Audio Controller Subsystem for nRF53 and is provided in the nrf/lib/bin/bt_ll_acs_nrf53/bin directory. If DFU is enabled, the subsystem’s binary file will be generated in the build/zephyr/ directory and will be called net_core_app_signed.hex.

Entering the DFU mode

The nRF Connect SDK uses SMP server and mcumgr as the DFU backend. Unlike the CIS and BIS modes for gateway and headsets, the DFU mode is advertising using the SMP server service. For this reason, to enter the DFU mode, you must long press BTN 4 during each device startup to have the nRF5340 Audio DK enter the DFU mode.

To identify the devices before the DFU takes place, the DFU mode advertising names mention the device type directly. The names follow the pattern in which the device ROLE is inserted before the _DFU suffix. For example:

• Gateway: NRF5340_AUDIO_GW_DFU

• Left Headset: NRF5340_AUDIO_HL_DFU

• Right Headset: NRF5340_AUDIO_HR_DFU

The first part of these names is based on CONFIG_BT_DEVICE_NAME.

Note

When performing DFU for the nRF5340 Audio application, there will be one or more error prints related to opening flash area ID 1. This is due to restrictions in the DFU system, and the error print is expected. The DFU process should still complete successfully.

Building and running

This sample can be found under applications/nrf5340_audio in the nRF Connect SDK folder structure.

Note

Building and programming the nRF5340 Audio application is different from the standard procedure of building and programming for the nRF5340 DK. This is because the nRF5340 Audio application only builds and programs the files for the application core. The network core for both gateway and headsets is programmed with the precompiled Bluetooth Low Energy Controller binary file ble5-ctr-rpmsg_<XYZ>.hex, where <XYZ> corresponds to the controller version, for example ble5-ctr-rpmsg_3216.hex. This file includes the LE Audio Controller Subsystem for nRF53 and is provided in the nrf/lib/bin/bt_ll_acs_nrf53/bin directory. If DFU is enabled, the subsystem’s binary file will be generated in the build/zephyr/ directory and will be called net_core_app_signed.hex.

You can build and program the application in one of the following ways:

• Building and programming using script. This is the suggested method. Using this method allows you to build and program multiple development kits at the same time.

• Building and programming using command line. Using this method requires building and programming each development kit separately.

Important

Building and programming using the nRF Connect for VS Code extension is currently not supported.

Note

You might want to check the nRF5340 Audio application known issues before building and programming the application.

Testing out of the box

Each development kit comes preprogrammed with basic firmware that indicates if the kit is functional. Before building the application, you can verify if the kit is working by completing the following steps:

1. Plug the device into the USB port.

2. Turn on the development kit using the On/Off switch.

3. Observe RGB1 (bottom side LEDs around the center opening that illuminate the Nordic Semiconductor logo) turn solid yellow, OB/EXT turn solid green, and LED3 start blinking green.

You can now program the development kits with either gateway or headset firmware before they can be used.

Adding FEM support

You can add support for the nRF21540 front-end module (FEM) to this application by using one of the following options, depending on how you decide to build the application:

• If you opt for Building and programming using script, add the --nrf21540 to the script’s building command.

• If you opt for Building and programming using command line, add the -DSHIELD=nrf21540ek_fwd to the west build command. For example:

  west build -b nrf5340_audio_dk_nrf5340_cpuapp --pristine -- -DCONFIG_AUDIO_DEV=1 -DSHIELD=nrf21540ek_fwd -DCONF_FILE=prj_release.conf
  

To set the TX power output, use the CONFIG_NRF_21540_MAIN_TX_POWER and CONFIG_NRF_21540_PRI_ADV_TX_POWER Kconfig options.

Note

When you build the nRF5340 Audio application with the nRF21540 FEM support, the LE Audio controller for nRF5340 does not support the +20 dBm setting. This is because of a power class restriction in the controller’s QDID.

See Working with RF front-end modules for more information about FEM in the nRF Connect SDK.

Building and programming using script

The suggested method for building the application and programming it to the development kit is running the buildprog.py Python script, which is located in the applications/nrf5340_audio/tools/buildprog directory. The script automates the process of selecting configuration files and building different versions of the application. This eases the process of building and programming images for multiple development kits.

Preparing the JSON file

The script depends on the settings defined in the nrf5340_audio_dk_devices.json file. Before using the script, make sure to update this file with the following information for each development kit you want to use:

• nrf5340_audio_dk_snr – This field lists the SEGGER serial number. You can check this number on the sticker on the nRF5340 Audio development kit. Alternatively, connect the development kit to your PC and run nrfjprog -i in a command window to print the SEGGER serial number of the kit.

• nrf5340_audio_dk_dev – This field assigns the specific nRF5340 Audio development kit to be a headset or a gateway.

• channel – This field is valid only for headsets operating in the CIS mode. It sets the channels on which the headset is meant to work. When no channel is set, the headset is programmed as a left channel one.

Running the script

After editing the nrf5340_audio_dk_devices.json file, run buildprog.py to build the firmware for the development kits. The building command for running the script requires providing the following parameters, in line with nRF5340 Audio configuration files:

• Core type (-c parameter): app, net, or both

• Application version (-b parameter): either release or debug

• Device type (-d parameter): headset, gateway, or both

• DFU type (-m parameter): internal, external

• Network core bootloader minimal size (-M)

See the following examples of the parameter usage with the command run from the buildprog directory:

• Example 1: The following command builds the application using the script for the application core with the debug application version for both the headset and the gateway:

  python buildprog.py -c app -b debug -d both
  

• Example 2: The following command builds the application using the script for both the application and the network core (both). It builds with the release application version, with the DFU internal flash memory layout enabled, and using the minimal size of the network core bootloader:

  python buildprog.py -c both -b release -d both -m internal -M
  

  If you run this command with the external DFU type parameter instead of internal, the external flash memory layout will be enabled.

The command can be run from any location, as long as the correct path to buildprog.py is given.

The build files are saved in the applications/nrf5340_audio/build directory. The script creates a directory for each application version and device type combination. For example, when running the command above, the script creates the dev_gateway/build_debug and dev_headset/build_debug directories.

Programming with the script

The development kits are programmed according to the serial numbers set in the JSON file. Make sure to connect the development kits to your PC using USB and turn them on using the POWER switch before you run the command.

The following parameters are available for programming:

• Programming (-p parameter) – If you run the building script with this parameter, you can program one or both of the cores after building the files.

• Sequential programming (-s parameter) – If you are using Windows Subsystem for Linux (WSL) and encounter problems while programming, include this parameter alongside other parameters to program sequentially.

The command for programming can look as follows:

python buildprog.py -c both -b debug -d both -p

This command builds the application with the debug application version for both the headset and the gateway and programs the application core. Given the -c both parameter, it also takes the precompiled Bluetooth Low Energy Controller binary from the nrf/lib/bin/bt_ll_acs_nrf53/bin directory and programs it to the network core of both the gateway and the headset.

Note

If the programming command fails because of Readback protection, run buildprog.py with the --recover_on_fail or -f parameter to recover and re-program automatically when programming fails. For example, using the programming command example above:

python buildprog.py -c both -b debug -d both -p --recover_on_fail

If you want to program firmware that has DFU enabled, you must include the DFU parameters in the command. The command for programming with DFU enabled can look as follows:

python buildprog.py -c both -b release -d both -m internal -M -p

Getting help

Run python buildprog.py -h for information about all available script parameters.

Configuration table overview

When running the script command, a table similar to the following one is displayed to provide an overview of the selected options and parameter values:

+------------+----------+---------+--------------+---------------------+---------------------+
| snr        | snr conn | device  | only reboot  | core app programmed | core net programmed |
+------------+----------+---------+--------------+---------------------+---------------------+
| 1010101010 | True     | headset | Not selected | Selected TBD        | Not selected        |
| 2020202020 | True     | gateway | Not selected | Selected TBD        | Not selected        |
| 3030303030 | True     | headset | Not selected | Selected TBD        | Not selected        |
+------------+----------+---------+--------------+---------------------+---------------------+

See the following table for the meaning of each column and the list of possible values:

Column	Indication	Possible values
snr	Serial number of the device, as provided in the nrf5340_audio_dk_devices.json file.	Serial number.
snr conn	Whether the device with the provided serial number is connected to the PC with a serial connection.	True - Connected.
		False - Not connected.
device	Device type, as provided in the nrf5340_audio_dk_devices.json file.	headset - Headset.
		gateway - Gateway.
only reboot	Whether the device is to be only reset and not programmed. This depends on the -r parameter in the command, which overrides other parameters.	Not selected - No reset.
		Selected TBD - Only reset requested.
		Done - Reset done.
		Failed - Reset failed.
core app programmed	Whether the application core is to be programmed. This depends on the value provided to the -c parameter (see above).	Not selected - Core will not be programmed.
		Selected TBD - Programming requested.
		Done - Programming done.
		Failed - Programming failed.
core net programmed	Whether the network core is to be programmed. This depends on the value provided to the -c parameter (see above).	Not selected - Core will not be programmed.
		Selected TBD - Programming requested.
		Done - Programming done.
		Failed - Programming failed.

Building and programming using command line

You can also build the nRF5340 Audio application using the standard nRF Connect SDK build steps for the command line.

Note

Using this method requires you to build and program each development kit one at a time before moving to the next configuration, which can be time-consuming. Building and programming using script is recommended.

Building the application

Complete the following steps to build the application:

1. Choose the combination of build flags:

   1. Choose the device type by using one of the following options:

      • For headset device: -DCONFIG_AUDIO_DEV=1

      • For gateway device: -DCONFIG_AUDIO_DEV=2

   2. Choose the application version by using one of the following options:

      • For the debug version: No build flag needed.

      • For the release version: -DCONF_FILE=prj_release.conf

2. Build the application using the standard build steps for the command line. For example, if you want to build the firmware for the application core as a headset using the release application version, you can run the following command:

   west build -b nrf5340_audio_dk_nrf5340_cpuapp --pristine -- -DCONFIG_AUDIO_DEV=1 -DCONF_FILE=prj_release.conf
   

   Unlike when Building and programming using script, this command creates the build files directly in the build directory. This means that you first need to program the headset development kits before you build and program gateway development kits. Alternatively, you can add the -d parameter to the west command to specify a custom build folder. This lets you build firmware for both headset and gateway before programming any development kits.

Programming the application

After building the files for the development kit you want to program, complete the following steps to program the application from the command line:

1. Plug the device into the USB port.

   Note

   Make sure to check the nRF5340 Audio application known issues related to serial connection with the USB.

2. Turn on the development kit using the On/Off switch.

3. Open a command prompt.

4. Run the following command to print the SEGGER serial number of your development kit:

   nrfjprog -i
   

   Note

   Pay attention to which device is to be programmed with the gateway HEX file and which devices are to be programmed with the headset HEX file.

5. Program the network core on the development kit by running the following command:

   nrfjprog --program bin/*.hex --chiperase --coprocessor CP_NETWORK -r
   

   The network core for both gateway and headsets is programmed with the precompiled Bluetooth Low Energy Controller binary file ble5-ctr-rpmsg_<XYZ>.hex, where <XYZ> corresponds to the controller version, for example ble5-ctr-rpmsg_3216.hex. This file includes the LE Audio Controller Subsystem for nRF53 and is provided in the nrf/lib/bin/bt_ll_acs_nrf53/bin directory. If DFU is enabled, the subsystem’s binary file will be generated in the build/zephyr/ directory and will be called net_core_app_signed.hex.

6. Program the application core on the development kit with the respective HEX file from the build directory by running the following command:

   nrfjprog --program build/zephyr/zephyr.hex --coprocessor CP_APPLICATION --chiperase -r
   

   In this command, build/zephyr/zephyr.hex is the HEX binary file for the application core. If a custom build folder is specified, the path to this folder must be used instead of build/.

7. If any device is not programmed due to Readback protection, complete the following steps:

   1. Run the following commands to recover the device:

      nrfjprog --recover --coprocessor CP_NETWORK
      nrfjprog --recover
      

   2. Repeat steps 5 and 6 to program both cores again.

8. When using the default CIS configuration, if you want to use two headset devices, you must also populate the UICR with the desired channel for each headset. Use the following commands, depending on which headset you want to populate:

   • Left headset:

     nrfjprog --memwr 0x00FF80F4 --val 0
     

   • Right headset:

     nrfjprog --memwr 0x00FF80F4 --val 1
     

   Select the correct board when prompted with the popup or add the --snr parameter followed by the SEGGER serial number of the correct board at the end of the nrfjprog command.

Testing

After building and programming the application, you can test it for both the CIS and the BIS modes. The following testing scenarios assume you are using USB as the audio source on the gateway. This is the default setting.

Testing the default CIS mode

Complete the following steps to test the unidirectional CIS mode for one gateway and two headset devices:

1. Make sure that the development kits are still plugged into the USB ports and are turned on.

   Note

   Make sure to check the nRF5340 Audio application known issues related to serial connection with the USB.

   After programming, RGB2 starts blinking green on every device to indicate the ongoing CPU activity on the network core. LED3 starts blinking green on every device to indicate the ongoing CPU activity on the application core.

2. Wait for the LED1 on the gateway to start blinking blue. This happens shortly after programming the development kit and indicates that the gateway device is connected to at least one headset and ready to send data.

3. Search the list of audio devices listed in the sound settings of your operating system for nRF5340 USB Audio (gateway) and select it as the output device.

4. Connect headphones to the HEADPHONE audio jack on both headset devices.

5. Start audio playback on your PC from any source.

6. Wait for LED1 to blink blue on both headsets. When they do, the audio stream has started on both headsets.

   Note

   The audio outputs only to the left channel of the audio jack, even if the given headset is configured as the right headset. This is because of the mono hardware codec chip used on the development kits. If you want to play stereo sound using one development kit, you must connect an external hardware codec chip that supports stereo.

7. Wait for LED2 to light up solid green on the headsets to indicate that the audio synchronization is achieved.

8. Press the VOL+ button on one of the headsets. The playback volume increases for both headsets.

9. Press the VOL- button on the gateway. The playback volume decreases for both headsets.

10. Press the PLAY/PAUSE button on any one of the devices. The playback stops for both headsets and the streaming state for all devices is set to paused.

11. Press the RESET button on the gateway. The gateway resets and the playback on the unpaused headset stops. After some time, the gateway establishes the connection with both headsets and resumes the playback on the unpaused headset.

12. Press the PLAY/PAUSE button on any one of the devices. The playback resumes in both headsets.

13. Press the BTN 4 button on the gateway multiple times. For each button press, the audio stream playback is stopped and the gateway sends a test tone to both headsets. These tones can be used as audio cues to check the synchronization of the headsets.

14. Hold down the VOL+ button and press the RESET button on the left headset. After startup, this headset will be configured as the right channel headset.

15. Hold down the VOL- button and press the RESET button on the left headset. After startup, this headset will go back to be configured as the left channel headset. You can also just press the RESET button to restore the original programmed settings.

After the kits have paired for the first time, they are now bonded. This means the Long-Term Key (LTK) is stored on each side, and that the kits will only connect to each other unless the bonding information is cleared. To clear the bonding information, press and hold BTN 5 during boot.

When you finish testing, power off the nRF5340 Audio development kits by switching the power switch from On to Off.

Testing the BIS mode

Testing the BIS mode is identical to Testing the default CIS mode, except for the following differences:

• You must select the BIS mode manually before building the application.

• You can play the audio stream with different audio settings on the receivers. For example, you can decrease or increase the volume separately for each receiver during playback.

• When pressing the PLAY/PAUSE button on a headset, the streaming state only changes for that given headset.

• Pressing the PLAY/PAUSE button on the gateway will respectively start or stop the stream for all headsets listening in.

• Pressing the BTN 4 button on a headset will change the active audio stream. The default configuration of the BIS mode supports two audio streams (left and right).

• Pressing the BTN 5 button on a headset will change the gateway source for the audio stream (after Enabling the BIS mode with two gateways). If a second gateway is not present, the headset will not play audio.

Testing the walkie-talkie demo

Testing the walkie-talkie demo is identical to Testing the default CIS mode, except for the following differences:

• You must enable the Kconfig option mentioned in Enabling the walkie-talkie demo before building the application.

• Instead of controlling the playback, you can speak through the PDM microphones. The line is open all the time, no need to press any buttons to talk, but the volume control works as in Testing the default CIS mode.

Testing FOTA upgrades

nRF Connect Device Manager can be used for testing FOTA upgrades. The procedure for upgrading the firmware is identical for both headset and gateway firmware. You can test upgrading the firmware on both cores at the same time on a headset device by completing the following steps:

1. Make sure you have configured the application for FOTA.

2. Install nRF Connect Device Manager on your Android or iOS device.

3. Connect an external flash shield to the headset.

4. Make sure the headset runs a firmware that supports DFU using external flash memory. One way of doing this is to connect the headset to the USB port, turn it on, and then run this command:

   python buildprog.py -c both -b debug -d headset --pristine -m external -p
   

   Note

   When using the FOTA related functionality in the buildprog.py script on Linux, the python command must execute Python 3.

5. Use the buildprog.py script to create a zip file that contains new firmware for both cores:

   python buildprog.py -c both -b debug -d headset --pristine -m external
   

6. Transfer the generated file to your Android or iOS device, depending on the DFU scenario. See the FOTA build files section for information about FOTA file name patterns. For transfer, you can use cloud services like Google Drive for Android or iCloud for iOS.

7. Enter the DFU mode by pressing and holding down RESET and BTN 4 at the same time, and then releasing RESET while continuing to hold down BTN 4 for a couple more seconds.

8. Open nRF Connect Device Manager and look for NRF5340_AUDIO_HL_DFU in the scanned devices window. The headset is left by default.

9. Tap on NRF5340_AUDIO_HL_DFU and then on the downward arrow icon at the bottom of the screen.

10. In the Firmware Upgrade section, tap SELECT FILE.

11. Select the file you transferred to the device.

12. Tap START and check Confirm only in the notification.

13. Tap START again to start the DFU process.

14. When the DFU has finished, verify that the new application core and network core firmware works properly.

Dependencies

Note

The following lists mention the most important dependencies. For the full list, check the application’s Kconfig options. All dependencies are automatically included.

The application uses the following nRF Connect SDK components:

• LE Audio controller for nRF5340

• Continuous array

• Pulse Code Modulation audio mixer

• Tone generator

This application uses the following nrfx libraries:

• nrfx_clock.h

• nrfx_gpiote.h

• nrfx_timer.h

• nrfx_dppi.h

• nrfx_i2s.h

• nrfx_ipc.h

• nrfx_nvmc.h

The application also depends on the following Zephyr libraries:

• Logging

• Kernel Services

• Zephyr message bus (zbus)

• Peripherals:

  • USB device support APIs

• Bluetooth APIs:

  • include/bluetooth/bluetooth.h

  • include/bluetooth/gatt.h

  • include/bluetooth/hci.h

  • include/bluetooth/uuid.h

Application configuration options

CONFIG_NRF5340_AUDIO

(bool) nRF5340 Audio [EXPERIMENTAL]

None

CONFIG_AUDIO_DEV

(int) Select which device type to compile for. 1=HEADSET or 2=GATEWAY

Setting this variable to 1 selects that the project is compiled as a HEADSET device. Setting to 2 will compile as a GATEWAY.

CONFIG_TRANSPORT_BIS

(bool) Use BIS (Broadcast Isochronous Stream)

None

CONFIG_TRANSPORT_CIS

(bool) Use CIS (Connected Isochronous Stream)

None

CONFIG_ZBUS_RUNTIME_OBSERVERS_POOL_SIZE

(int) Number of zbus observers

None

CONFIG_REBOOT

(unknown)

None

CONFIG_MAIN_THREAD_PRIORITY

(unknown)

None

CONFIG_MAIN_STACK_SIZE

(unknown)

None

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE

(int)

None

CONFIG_THREAD_NAME

(bool)

None

CONFIG_NCS_INCLUDE_RPMSG_CHILD_IMAGE

(unknown)

None

CONFIG_RESET_ON_FATAL_ERROR

(unknown)

None

CONFIG_HW_CODEC_CIRRUS_LOGIC

(unknown)

None

CONFIG_BT

(unknown)

None

CONFIG_BOARD_ENABLE_DCDC_APP

(unknown)

None

CONFIG_BOARD_ENABLE_DCDC_NET

(unknown)

None

CONFIG_BOARD_ENABLE_CPUNET

(unknown)

None

CONFIG_NFCT_PINS_AS_GPIOS

(unknown)

None

CONFIG_ZBUS

(unknown)

None

CONFIG_ZBUS_RUNTIME_OBSERVERS

(unknown)

None

CONFIG_SENSOR

(unknown)

None

CONFIG_REGULATOR

(unknown)

None

CONFIG_CONTIN_ARRAY

(unknown)

None

CONFIG_NRFX_I2S0

(unknown)

None

CONFIG_PCM_MIX

(unknown)

None

CONFIG_TONE

(unknown)

None

CONFIG_PSCM

(unknown)

None

CONFIG_DATA_FIFO

(unknown)

None

CONFIG_NRFX_CLOCK

(unknown)

None

CONFIG_I2C

(unknown)

None

CONFIG_FPU

(unknown)

None

CONFIG_FPU_SHARING

(unknown)

None

CONFIG_DISK_DRIVERS

(unknown)

None

CONFIG_DISK_DRIVER_SDMMC

(unknown)

None

CONFIG_SPI

(unknown)

None

CONFIG_ADC

(unknown)

None

CONFIG_SPI_NRFX_RAM_BUFFER_SIZE

(unknown)

None

CONFIG_FILE_SYSTEM

(unknown)

None

CONFIG_FAT_FILESYSTEM_ELM

(unknown)

None

CONFIG_FS_FATFS_LFN

(unknown)

None

CONFIG_FS_FATFS_EXFAT

(unknown)

None

CONFIG_FS_FATFS_MAX_LFN

(unknown)

None

CONFIG_BT_LL_ACS_NRF53

(unknown)

None

CONFIG_WATCHDOG

(unknown)

None

CONFIG_TASK_WDT

(unknown)

None

CONFIG_NRFX_TIMER1

(unknown)

None

CONFIG_NRFX_DPPI

(unknown)

None

CONFIG_CMSIS_DSP

(unknown)

None

CONFIG_CMSIS_DSP_FASTMATH

(unknown)

None

CONFIG_LC3_BITRATE

(int)

None

CONFIG_LC3_ENC_CHAN_MAX

(unknown)

None

CONFIG_LC3_DEC_CHAN_MAX

(unknown)

None

CONFIG_AUDIO_TEST_TONE

(bool)

None

CONFIG_AUDIO_MUTE

(bool)

None

CONFIG_AUDIO_FRAME_DURATION_7_5_MS

(bool) 7.5 ms

None

CONFIG_AUDIO_FRAME_DURATION_10_MS

(bool) 10 ms

None

CONFIG_AUDIO_FRAME_DURATION_US

(int)

Audio frame duration in µs.

CONFIG_AUDIO_MIN_PRES_DLY_US

(int) The minimum presentation delay

The minimum presentation delay in micro seconds determined by the audio system processing and the minimum buffering.

CONFIG_AUDIO_MAX_PRES_DLY_US

(int) The maximum presentation delay

The maximum presentation delay in micro seconds.

CONFIG_AUDIO_SAMPLE_RATE_16000_HZ

(bool) 16 kHz

Sample rate of 16kHz is currently only valid for I2S/line-in.

CONFIG_AUDIO_SAMPLE_RATE_24000_HZ

(bool) 24 kHz

Sample rate of 24kHz is currently only valid for I2S/line-in.

CONFIG_AUDIO_SAMPLE_RATE_48000_HZ

(bool) 48 kHz

Sample rate of 48kHz is valid for both I2S/line-in and USB.

CONFIG_AUDIO_SAMPLE_RATE_HZ

(int)

I2S supports 16, 24, and 48 kHz sample rates for both input and output. USB supports only 48 kHz for input.

CONFIG_AUDIO_BIT_DEPTH_16

(bool) 16 bit audio

None

CONFIG_AUDIO_BIT_DEPTH_32

(bool) 32 bit audio

None

CONFIG_AUDIO_BIT_DEPTH_BITS

(int)

Bit depth of one sample in storage.

CONFIG_AUDIO_BIT_DEPTH_OCTETS

(int)

Bit depth of one sample in storage given in octets.

CONFIG_AUDIO_SOURCE_USB

(bool) Use USB as audio source

Set USB as audio source. Note that this forces the stream to be unidirectional because of CPU load.

CONFIG_AUDIO_SOURCE_I2S

(bool) Use I2S as audio source

None

CONFIG_AUDIO_HEADSET_CHANNEL_RUNTIME

(bool) Select at runtime

Make channel selection at runtime. Selected value is stored in persistent memory. Left channel: Hold volume-down button on headset while resetting headset. Right channel: Hold volume-up button on headset while resetting headset.

CONFIG_AUDIO_HEADSET_CHANNEL_COMPILE_TIME

(bool) Set at compile-time

Set channel selection at compile-time.

CONFIG_AUDIO_HEADSET_CHANNEL

(int) Audio channel used by headset

Audio channel compile-time selection. Left = 0. Right = 1.

CONFIG_SW_CODEC_LC3

(bool) LC3

LC3 is the mandatory codec for LE Audio.

CONFIG_SW_CODEC_PLC_DISABLED

(bool) Skip PLC on a bad frame and fill the output buffer(s) with zeros instead

None

CONFIG_LC3_BITRATE_MAX

(int) Max bitrate for LC3

None

CONFIG_LC3_BITRATE_MIN

(int) Min bitrate for LC3

None

CONFIG_BUF_BLE_RX_PACKET_NUM

(int)

Value can be adjusted to affect the overall latency. This adjusts the number packets in the BLE FIFO RX buffer, which is where the main latency resides. A low value will decrease latency and reduce stability, and vice-versa. Two is recommended minimum to reduce the likelyhood of audio gaps due to BLE retransmits.

CONFIG_STREAM_BIDIRECTIONAL

(bool) Bidirectional stream

Bidirectional stream enables encoder and decoder on both sides, and one device can both send and receive audio.

CONFIG_WALKIE_TALKIE_DEMO

(bool) Walkie talkie demo

The walkie talkie demo will set up a bidirectional stream using PDM microphones on each side.

CONFIG_MONO_TO_ALL_RECEIVERS

(bool) Send mono (first/left channel) to all receivers

With this flag set, the gateway will encode and send the same (first/left) channel on all ISO channels.

CONFIG_ENCODER_THREAD_PRIO

(int) Priority for encoder thread

This is a preemptible thread.

CONFIG_AUDIO_DATAPATH_THREAD_PRIO

(int) Priority for audio datapath thread

This is a preemptible thread.

CONFIG_BUTTON_MSG_SUB_THREAD_PRIO

(int) Thread priority for button subscriber

This is a preemptible thread. This thread will subscribe to button events from zbus.

CONFIG_LE_AUDIO_MSG_SUB_THREAD_PRIO

(int) Thread priority for LE Audio subscriber

This is a preemptible thread. This thread will subscribe to LE Audio events from zbus.

CONFIG_CONTENT_CONTROL_MSG_SUB_THREAD_PRIO

(int) Thread priority for content control subscriber

This is a preemptible thread. This thread will subscribe to content control events from zbus.

CONFIG_ENCODER_STACK_SIZE

(int) Stack size for encoder thread

None

CONFIG_AUDIO_DATAPATH_STACK_SIZE

(int) Stack size for audio datapath thread

None

CONFIG_BUTTON_MSG_SUB_STACK_SIZE

(int) Stack size for button subscriber

None

CONFIG_LE_AUDIO_MSG_SUB_STACK_SIZE

(int) Stack size for LE Audio subscriber

None

CONFIG_CONTENT_CONTROL_MSG_SUB_STACK_SIZE

(int) Stack size for content control subscriber

None

CONFIG_BUTTON_MSG_SUB_QUEUE_SIZE

(int) Queue size for button subscriber

None

CONFIG_LE_AUDIO_MSG_SUB_QUEUE_SIZE

(int) Queue size for LE Audio subscriber

None

CONFIG_CONTENT_CONTROL_MSG_SUB_QUEUE_SIZE

(int) Queue size for content control subscriber

None

CONFIG_BT_AUDIO

(unknown)

None

CONFIG_BT_DEVICE_NAME

(unknown)

None

CONFIG_BT_ECC

(unknown)

None

CONFIG_BT_EXT_ADV

(unknown)

None

CONFIG_BT_ATT_PREPARE_COUNT

(unknown)

None

CONFIG_BT_ATT_ENFORCE_FLOW

(unknown)

None

CONFIG_BT_HCI_VS_EXT

(unknown)

None

CONFIG_BT_HCI_ACL_FLOW_CONTROL

(unknown)

None

CONFIG_NRF_21540_ACTIVE

(bool)

The front end module can help boost the TX power as high as 20 dBm.

CONFIG_NRF_21540_MAIN_TX_POWER_0DBM

(bool) 0dBm

None

CONFIG_NRF_21540_MAIN_TX_POWER_10DBM

(bool) +10dBm

None

CONFIG_NRF_21540_MAIN_TX_POWER_20DBM

(bool) +20dBm

None

CONFIG_NRF_21540_MAIN_DBM

(int)

None

CONFIG_NRF_21540_PRI_ADV_TX_POWER_0DBM

(bool) 0dBm

None

CONFIG_NRF_21540_PRI_ADV_TX_POWER_10DBM

(bool) +10dBm

None

CONFIG_NRF_21540_PRI_ADV_TX_POWER_20DBM

(bool) +20dBm

None

CONFIG_NRF_21540_PRI_ADV_DBM

(int)

None

CONFIG_BLE_LE_POWER_CONTROL_ENABLED

(bool) Enable the Bluetooth LE power control feature

The Bluetooth LE power control feature makes devices be able to change TX power dynamically and automatically during connection, which may reduce power consumption.

CONFIG_WDT_CTLR

(bool) Enable watchdog for controller

When true, the controller will be polled at regular intervals to check that it is alive. Turn off to reduce overhead, or HCI traffic. The watchdog will be deactivated automatically for DFU procedures.

CONFIG_BLE_CONN_TX_POWER_0DBM

(bool) 0dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_1DBM

(bool) -1dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_2DBM

(bool) -2dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_3DBM

(bool) -3dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_4DBM

(bool) -4dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_5DBM

(bool) -5dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_6DBM

(bool) -6dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_7DBM

(bool) -7dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_8DBM

(bool) -8dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_12DBM

(bool) -12dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_16DBM

(bool) -14dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_20DBM

(bool) -20dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_40DBM

(bool) -40dBm

None

CONFIG_BLE_CONN_TX_POWER_DBM

(int)

None

CONFIG_BLE_ADV_TX_POWER_0DBM

(bool) 0dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_1DBM

(bool) -1dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_2DBM

(bool) -2dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_3DBM

(bool) -3dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_4DBM

(bool) -4dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_5DBM

(bool) -5dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_6DBM

(bool) -6dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_7DBM

(bool) -7dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_8DBM

(bool) -8dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_12DBM

(bool) -12dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_16DBM

(bool) -14dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_20DBM

(bool) -20dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_40DBM

(bool) -40dBm

None

CONFIG_BLE_ADV_TX_POWER_DBM

(int)

None

CONFIG_BLE_ACL_PER_ADV_INT_MIN

(hex) Minimum periodic advertising interval

Minimum hexadecimal value for the interval of periodic advertisements. For ms, multiply the provided value by 1.25.

CONFIG_BLE_ACL_PER_ADV_INT_MAX

(hex) Maximum periodic advertising interval

Maximum hexadecimal value for the interval of periodic advertisements. For ms, multiply the provided value by 1.25.

CONFIG_BLE_ACL_EXT_ADV_INT_MIN

(hex) Minimum extended advertising interval

Minimum hexadecimal value for the interval of extended advertisements. When the LE Audio Controller Subsystem for nRF53 is used, this interval should be a multiple of the ISO interval and maximum 4x larger than the lowest interval if using BIS. For ms, multiply the provided value by 0.625.

CONFIG_BLE_ACL_EXT_ADV_INT_MAX

(hex) Maximum extended advertising interval

Maximum hexadecimal value for the interval of extended advertisements. When the LE Audio Controller Subsystem for nRF53 is used, this interval should be a multiple of the ISO interval and maximum 4x larger than the lowest interval if using BIS. For ms, multiply the provided value by 0.625.

CONFIG_EXT_ADV_BUF_MAX

(int) Maximum number of extended advertising data parameters

None

CONFIG_EXT_ADV_UUID_BUF_MAX

(int) Maximum number of UUIDs to add to extended advertisements

None

CONFIG_BT_BACKGROUND_SCAN_INTERVAL

(unknown)

None

CONFIG_BT_BACKGROUND_SCAN_WINDOW

(unknown)

None

CONFIG_BT_SCAN_WITH_IDENTITY

(unknown)

None

CONFIG_SCAN_MODE_PASSIVE

(bool) Passive Scan

None

CONFIG_SCAN_MODE_ACTIVE

(bool) Active Scan

None

CONFIG_BLE_ACL_CONN_INTERVAL

(int) Bluetooth LE ACL Connection Interval (x*1.25ms)

When the LE Audio Controller Subsystem for nRF53 is used, this interval should be a multiple of the ISO interval and maximum 4x larger than the lowest interval.

CONFIG_BLE_ACL_SLAVE_LATENCY

(int) Bluetooth LE Slave Latency

None

CONFIG_BLE_ACL_SUP_TIMEOUT

(int) Bluetooth LE Supervision Timeout (x*10ms)

None

CONFIG_BT_BUF_ACL_RX_SIZE

(unknown)

None

CONFIG_BT_OBSERVER

(unknown)

None

CONFIG_BT_PERIPHERAL

(unknown)

None

CONFIG_BT_DEVICE_APPEARANCE

(unknown)

None

CONFIG_BT_ISO_SYNC_RECEIVER

(unknown)

None

CONFIG_BT_BAP_BROADCAST_SINK

(unknown)

None

CONFIG_BT_BAP_SCAN_DELEGATOR

(unknown)

None

CONFIG_BT_BAP_BROADCAST_SNK_STREAM_COUNT

(unknown)

None

CONFIG_BT_BAP_BROADCAST_SNK_COUNT

(unknown)

None

CONFIG_BT_ISO_MAX_CHAN

(unknown)

None

CONFIG_BT_ISO_MAX_BIG

(unknown)

None

CONFIG_BT_PER_ADV_SYNC_MAX

(unknown)

None

CONFIG_BT_SMP

(unknown)

None

CONFIG_BT_PAC_SNK

(unknown)

None

CONFIG_BT_AUDIO_RX

(unknown)

None

CONFIG_BT_CAP_INITIATOR

(unknown)

None

CONFIG_BT_AUDIO_BROADCAST_NAME

(string)

None

CONFIG_BT_ISO_BROADCASTER

(unknown)

None

CONFIG_BT_BAP_BROADCAST_SOURCE

(unknown)

None

CONFIG_BT_ISO_TX_BUF_COUNT

(unknown)

None

CONFIG_BT_BAP_BROADCAST_SRC_STREAM_COUNT

(unknown)

None

CONFIG_BT_AUDIO_TX

(unknown)

None

CONFIG_BT_AUDIO_BROADCAST_CONFIGURABLE

(bool) Configurable broadcast settings

Configurable option that doesn’t follow any preset. Allows for more flexibility.

CONFIG_BT_BAP_BROADCAST_16_2_1

(bool) 16_2_1

Broadcast mandatory codec capability 16_2_1. 16kHz, 32kbps, 2 retransmits, 10ms transport latency, and 40ms presentation delay.

CONFIG_BT_BAP_BROADCAST_24_2_1

(bool) 24_2_1

Broadcast codec capability 24_2_1. 24kHz, 48kbps, 2 retransmits, 10ms transport latency, and 40ms presentation delay.

CONFIG_BT_BAP_BROADCAST_16_2_2

(bool) 16_2_2

Broadcast mandatory codec capability 16_2_2. 16kHz, 32kbps, 4 retransmits, 60ms transport latency, and 40ms presentation delay.

CONFIG_BT_BAP_BROADCAST_24_2_2

(bool) 24_2_2

Broadcast codec capability 24_2_2. 24kHz, 48kbps, 4 retransmits, 60ms transport latency, and 40ms presentation delay.

CONFIG_BT_AUDIO_BROADCAST_NAME_ALT

(string) Alternative broadcast name

Alternative name of the broadcast.

CONFIG_BT_AUDIO_USE_BROADCAST_NAME_ALT

(bool) Use the alternative broadcast name

Use the alternative broadcast name.

CONFIG_BT_AUDIO_BROADCAST_ENCRYPTED

(bool) Encrypted broadcast

Encrypt the broadcast to limit the connection possibilities.

CONFIG_BT_AUDIO_BROADCAST_ENCRYPTION_KEY

(string) Broadcast encryption key

Key to use for encryption and decryption, with maximum BT_ISO_BROADCAST_CODE_SIZE characters. Encryption keys larger than BT_ISO_BROADCAST_CODE_SIZE will be truncated to BT_ISO_BROADCAST_CODE_SIZE.

CONFIG_BT_AUDIO_USE_BROADCAST_ID_RANDOM

(bool) Use a random broadcast ID

Use a randomly generated broadcast ID.

CONFIG_BT_AUDIO_BROADCAST_ID_FIXED

(hex) Fixed broadcast ID

Fixed broadcast ID; 3 octets. Will only be used if BT_AUDIO_USE_BROADCAST_ID_RANDOM=n. Only use for debugging.

CONFIG_BT_AUDIO_BROADCAST_IMMEDIATE_FLAG

(bool) Immediate rendering flag

Set the immediate rendering flag.

CONFIG_AURACAST

(bool) Enable Auracast

When Auracast is enabled, a Public Broadcast Announcement will be included when advertising.

CONFIG_BT_AUDIO_BITRATE_BROADCAST_SRC

(int) ISO stream bitrate

Bitrate for the broadcast source ISO stream.

CONFIG_BT_GATT_CLIENT

(unknown)

None

CONFIG_BT_BONDABLE

(unknown)

None

CONFIG_BT_PRIVACY

(unknown)

None

CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS

(unknown)

None

CONFIG_BT_AUTO_PHY_UPDATE

(unknown)

None

CONFIG_BT_AUTO_DATA_LEN_UPDATE

(unknown)

None

CONFIG_BT_L2CAP_TX_BUF_COUNT

(unknown)

None

CONFIG_SETTINGS

(unknown)

None

CONFIG_BT_SETTINGS

(unknown)

None

CONFIG_FLASH

(bool)

None

CONFIG_FLASH_MAP

(bool)

None

CONFIG_NVS

(unknown)

None

CONFIG_NVS_LOG_LEVEL

(unknown)

None

CONFIG_BT_BAP_UNICAST_SERVER

(unknown)

None

CONFIG_BT_MAX_CONN

(unknown)

None

CONFIG_BT_ASCS_ASE_SNK_COUNT

(unknown)

None

CONFIG_BT_ASCS_ASE_SRC_COUNT

(unknown)

None

CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS

(unknown)

None

CONFIG_BT_GATT_AUTO_SEC_REQ

(unknown)

None

CONFIG_BT_VCP_VOL_REND

(unknown)

None

CONFIG_BT_MCC

(unknown)

None

CONFIG_BT_PAC_SNK_NOTIFIABLE

(unknown)

None

CONFIG_BT_PACS_SNK_CONTEXT

(unknown)

None

CONFIG_BT_PACS_SRC_CONTEXT

(unknown)

None

CONFIG_BT_CSIP_SET_MEMBER

(unknown)

None

CONFIG_BT_CAP_ACCEPTOR

(unknown)

None

CONFIG_BT_CAP_ACCEPTOR_SET_MEMBER

(unknown)

None

CONFIG_BT_AUDIO_CODEC_CFG_MAX_METADATA_SIZE

(unknown)

None

CONFIG_BT_BAP_UNICAST_CLIENT

(unknown)

None

CONFIG_BT_MAX_PAIRED

(unknown)

None

CONFIG_BT_BAP_UNICAST_CLIENT_GROUP_STREAM_COUNT

(unknown)

None

CONFIG_BT_BAP_UNICAST_CLIENT_ASE_SNK_COUNT

(unknown)

None

CONFIG_BT_BAP_UNICAST_CLIENT_ASE_SRC_COUNT

(unknown)

None

CONFIG_BT_VCP_VOL_CTLR

(unknown)

None

CONFIG_BT_MCS

(unknown)

None

CONFIG_BT_GATT_DYNAMIC_DB

(unknown)

None

CONFIG_UTF8

(unknown)

None

CONFIG_BT_MPL

(unknown)

None

CONFIG_MCTL

(unknown)

None

CONFIG_MCTL_LOCAL_PLAYER_CONTROL

(unknown)

None

CONFIG_MCTL_LOCAL_PLAYER_REMOTE_CONTROL

(unknown)

None

CONFIG_BT_BAP_UNICAST_CONFIGURABLE

(bool) Configurable unicast settings

Configurable option that doesn’t follow any preset. Allows for more flexibility.

CONFIG_BT_BAP_UNICAST_16_2_1

(bool) 16_2_1

Unicast mandatory codec capability 16_2_1. 16kHz, 32kbps, 2 retransmits, 10ms transport latency, and 40ms presentation delay.

CONFIG_BT_BAP_UNICAST_24_2_1

(bool) 24_2_1

Unicast codec capability 24_2_1. 24kHz, 48kbps, 2 retransmits, 10ms transport latency, and 40ms presentation delay.

CONFIG_BT_AUDIO_PRES_DELAY_SRCH_MIN

(bool) Largest minimum delay over all audio receivers

Search for the largest minimum delay over all audio receivers.

CONFIG_BT_AUDIO_PRES_DELAY_SRCH_MAX

(bool) Smallest maximum delay over all audio receivers

Search for the smallest maximum delay over all audio receivers.

CONFIG_BT_AUDIO_PRES_DELAY_SRCH_PREF_MIN

(bool) Largest minimum preferred delay over all audio receivers

Search for the largest minimum preferred delay over all audio receivers.

CONFIG_BT_AUDIO_PRES_DELAY_SRCH_PREF_MAX

(bool) Smallest maximum preferred delay over all audio receivers

Search for the smallest maximum preferred delay over all audio receivers.

CONFIG_BT_AUDIO_PRES_DELAY_SRCH_SOURCE

(bool) Use the presentation delay of audio source or client

Use the presentation delay defined by the broadcast_source or unicast_client if it is within the range set by AUDIO_MIN_PRES_DLY_US and AUDIO_MAX_PRES_DLY_US. This will override the audio receiver presentation delay as long as it is in range of the max and min supported by the audio receivers. If it is outside this range, then it will revert to the closest supported value.

CONFIG_CODEC_CAP_COUNT_MAX

(int) Max storage of codec capabilities

Max number of codec capabilities to store per stream.

CONFIG_BT_AUDIO_PREFERRED_MIN_PRES_DLY_US

(int) The preferred minimum presentation delay

The preferred minimum presentation delay in microseconds. This can not be less than the absolute minimum presentation delay.

CONFIG_BT_AUDIO_PREFERRED_MAX_PRES_DLY_US

(int) The preferred maximum presentation delay

The preferred maximum presentation delay in microseconds. This can not be less than the absolute maximum presentation delay.

CONFIG_BT_AUDIO_BITRATE_UNICAST_SINK

(int) ISO stream bitrate

Bitrate for the unicast sink ISO stream.

CONFIG_BT_AUDIO_BITRATE_UNICAST_SRC

(int) ISO stream bitrate

Bitrate for the unicast source ISO stream.

CONFIG_BT_AUDIO_PACKING_INTERLEAVED

(bool) Interleaved packing

ISO channels can either be interleaved or sequentially packed; sequential is the default one.

CONFIG_BT_AUDIO_PRESENTATION_DELAY_US

(int) Presentation delay

The audio source/client defined presentation delay if within AUDIO_MIN_PRES_DLY_US and AUDIO_MAX_PRES_DLY_US range. This will override the audio receivers presentation delay as long as it is in range of the max and min supported by the audio receivers. If it is outside this range, then it will revert to the closest supported value.

CONFIG_BT_AUDIO_MAX_TRANSPORT_LATENCY_MS

(int) Max transport latency

Max transport latency for the ISO link.

CONFIG_BT_AUDIO_RETRANSMITS

(int) Number of retransmits

Number of retransmits for the ISO link. 2 retransmits means a total of 3 packets sent per stream.

CONFIG_BT_AUDIO_VOL_DEFAULT

(int) Default volume

The default volume when starting a volume control renderer.

CONFIG_BT_AUDIO_VOL_STEP_SIZE

(int) Volume adjust step size

None

CONFIG_CS47L63_THREAD_PRIO

(int) Priority for CS47L63 thread

This is a preemptible thread

CONFIG_CS47L63_STACK_SIZE

(int) Stack size for CS47L63

None

CONFIG_USB_DEVICE_STACK

(unknown)

None

CONFIG_NET_BUF

(unknown)

None

CONFIG_USB_DEVICE_AUDIO

(unknown)

None

CONFIG_USB_DEVICE_VID

(unknown)

None

CONFIG_USB_DEVICE_PID

(unknown)

None

CONFIG_USB_DEVICE_PRODUCT

(unknown)

None

CONFIG_USB_DEVICE_MANUFACTURER

(unknown)

None

CONFIG_USB_DRIVER_LOG_LEVEL

(unknown)

None

CONFIG_USB_DEVICE_LOG_LEVEL

(unknown)

None

CONFIG_BUTTON_DEBOUNCE_MS

(int) Button debounce time in ms

None

CONFIG_POWER_MEAS_INTERVAL_MS

(int) Power measurement interval in milliseconds

Power measurement runs continuously, this option just establishes the results polling period. Note that this value needs to be >= the configured sampling interval on the current sensor. When below, repeated measurements will be observed.

CONFIG_POWER_MEAS_START_ON_BOOT

(bool) Start power measurements for all rails on boot

This option will automatically start and periodically print the voltage, current consumption, and power usage for the following rails: VBAT, VDD1_CODEC, VDD2_CODEC, and VDD2_NRF

CONFIG_I2S_LRCK_FREQ_HZ

(int)

The sample rate of I2S. For now this is tied directly to AUDIO_SAMPLE_RATE_HZ Note that this setting is only valid in I2S master mode.

CONFIG_I2S_CH_NUM

(int)

The I2S driver itself supports both mono and stereo. Parts of the implementation are configured for only stereo.

CONFIG_POWER_MEAS_THREAD_PRIO

(int) Priority for power measurement thread

This is a preemptible thread.

CONFIG_BUTTON_PUBLISH_THREAD_PRIO

(int) Priority for button publish thread

This is a preemptible thread. This thread will publish button events to zbus.

CONFIG_VOLUME_MSG_SUB_THREAD_PRIO

(int) Priority for volume message subscribe thread

This is a preemptible thread. This thread will subscribe to volume events from zbus.

CONFIG_POWER_MEAS_STACK_SIZE

(int) Stack size for power measurement thread

None

CONFIG_BUTTON_PUBLISH_STACK_SIZE

(int) Stack size for button publish thread

None

CONFIG_VOLUME_MSG_SUB_STACK_SIZE

(int) Stack size for volume message subscribe thread

None

CONFIG_VOLUME_MSG_SUB_QUEUE_SIZE

(int) Queue size for volume message subscriber

None

CONFIG_NRFX_NVMC

(unknown)

None

CONFIG_FIFO_FRAME_SPLIT_NUM

(int) Number of blocks to make up one frame of audio data

Easy DMA in I2S requires two buffers to be filled before I2S transmission will begin. In order to reduce latency, an audio frame can be split into multiple blocks with this parameter. USB sends data in 1 ms blocks, so we need the split to match that. Since we set frame size to 10 ms for USB, 10 is selected as FRAME_SPLIT_NUM

CONFIG_FIFO_TX_FRAME_COUNT

(int) Max number of audio frames in TX slab

FIFO_TX is the buffer that holds decoded audio data before it is sent to either I2S or USB

CONFIG_FIFO_RX_FRAME_COUNT

(int) Max number of audio frames in RX slab

FIFO_RX is the buffer that holds uncompressed audio data coming from either I2S or USB

CONFIG_AUDIO_DFU

(int) Select which DFU type. 0=NONE, 1=Internal flash, 2=External flash

Setting this variable to 0 disables DFU. Setting this variable to 1 selects internal flash single image DFU. Setting this variable to 2 selects external flash multi images DFU.

CONFIG_B0N_MINIMAL

(bool) B0N use minimal or not

Let CMakelist choose corresponding overlay file

CONFIG_NCS_SAMPLE_EMPTY_NET_CORE_CHILD_IMAGE

(bool) Dummy Net core application

None

CONFIG_AUDIO_DFU_ENABLE

(bool)

To show warning message of EXPERIMENTAL feature DFU

CONFIG_BOOTLOADER_MCUBOOT

(bool)

None

CONFIG_ZCBOR

(bool)

None

CONFIG_MCUMGR

(bool)

None

CONFIG_MCUMGR_GRP_OS

(bool)

None

CONFIG_MCUMGR_GRP_OS_TASKSTAT

(bool)

None

CONFIG_MCUMGR_GRP_STAT

(bool)

None

CONFIG_MCUMGR_GRP_IMG

(bool)

None

CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE

(int)

None

CONFIG_IMG_MANAGER

(bool)

None

CONFIG_STREAM_FLASH

(bool)

None

CONFIG_MCUMGR_TRANSPORT_BT

(bool)

None

CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN

(bool)

None

CONFIG_BT_L2CAP_TX_MTU

(int)

None

CONFIG_BT_BUF_ACL_TX_SIZE

(int)

None

CONFIG_MCUMGR_TRANSPORT_NETBUF_COUNT

(int)

None

CONFIG_THREAD_MONITOR

(bool)

None

CONFIG_STATS

(bool)

None

CONFIG_STATS_NAMES

(bool)

None

CONFIG_BT_DEVICE_NAME_DYNAMIC

(bool)

None

CONFIG_BT_DEVICE_NAME_GATT_WRITABLE

(bool)

None

CONFIG_BT_DEVICE_NAME_MAX

(int)

None

CONFIG_UPDATEABLE_IMAGE_NUMBER

(int)

None

CONFIG_IMG_ERASE_PROGRESSIVELY

(bool)

None

CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY

(bool)

None

CONFIG_SPI_NOR

(bool)

None

CONFIG_SPI_NOR_CS_WAIT_DELAY

(int)

None

CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE

(int)

None

CONFIG_MCUMGR_GRP_ZBASIC

(bool)

None

CONFIG_MCUMGR_GRP_ZBASIC_STORAGE_ERASE

(bool)

None

CONFIG_BOOT_IMAGE_ACCESS_HOOKS

(bool)

None

CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK

(bool)

None

CONFIG_PRINT_STACK_USAGE_MS

(int) Print stack usage every x milliseconds

None