NRF5340 BIS gateway audio and central mode BLE

[ChrisBon]

We currently have a project based off of the NRF5340_audio example.  This project was started off the 2.1.2 SDK.  Would like to use this build in Gateway BIS mode, but also enable Central BLE mode and have it connect to our buds for command/control.  I have managed to enable BLE Central in our source code, but when the Central gets connected the BIS audio never works, and if the BIS audio is connected, I always get a 0x3E from the BLE connection attempt.

I have read where maybe some improvements have been made in the most recent SDK, so I am considering upgrading to the 2.5.2, but what to confirm is it possible to use Central role BLE and gateway BIS in the same build in either SDK 2.1.2 or 2.5.2, and if so how.

I see this code in the latest 2.5.2 which tells me maybe not ?

    if (type == BT_MGMT_SCAN_TYPE_CONN && IS_ENABLED(CONFIG_BT_CENTRAL)) {

        ret = bt_mgmt_scan_for_conn_start(scan_param, srch_name);

    } else if (type == BT_MGMT_SCAN_TYPE_BROADCAST &&

           IS_ENABLED(CONFIG_BT_BAP_BROADCAST_SINK)) {

        ret = bt_mgmt_scan_for_broadcast_start(scan_param, srch_name);

[Karl Ylvisaker]

Hello,

There was a known issue in the earlier nRF5340 LE Audio reference application that made BIS + ACLs (regular BLE connections) unstable, but this has fortunately since been fixed! :) 

Which controller version are you using in your current application? Depending on the version it might be possible to just swap out the controller (if there have been no API version changes between the controller versions) to see if this fixes the issue, but I would of course on a general note recommend that you update your application to the latest nRF Connect SDK release since you then will have access to all the newest features and improvements.

Best regards,
Karl

[ChrisBon]

Karl,

Thanks, yes the original SDK was 2.1.2, so I have a feeling we are much further back then it would not allow me just to swap out the controller firmware.

Are there any good examples out there of someone doing this on 2.5.x SDK ?

I have run some test, and I am trying to advertise the BIS audio stream, and scan as a central to connect over BLE to buds.  I get the buds connected using BIS audio stream, but I get this when the central connects to the buds.

GW [00:00:37.176,788] <inf> bt_mgmt_scan: Start Scan
GW [00:00:37.177,856] <inf> bt_mgmt_scan: Local addr: D9:B3:53:44:4C:6F (random). May time out. Updates not printed
GW [00:00:37.177,856] <inf> bt_mgmt_scan: Scanning successfully started
GW [00:00:37.223,724] <inf> bt_mgmt_scan: Device found: B8:4C:87:C0:27:27 (public) (RSSI -45)
GW [00:00:37.225,250] <inf> bt_mgmt_scan: Creating connection to device: B8:4C:87:C0:27:27 (public)
GW [00:00:39.265,655] <inf> bt_mgmt: Connected: B8:4C:87:C0:27:27 (public)
GW [00:00:39.265,655] <inf> bt_mgmt_scan: Start Scan
GW [00:00:39.266,326] <inf> bt_mgmt_scan: Local addr: D9:B3:53:44:4C:6F (random). May time out. Updates not printed
GW [00:00:39.266,357] <inf> bt_mgmt_scan: Scanning successfully started
GW [00:00:39.266,662] <inf> streamctrl_brcast_src: Connected
GW [00:00:39.496,856] <inf> bt_mgmt: Disconnected: B8:4C:87:C0:27:27 (public) (reason 0x3e)
GW [00:00:39.496,887] <inf> streamctrl_brcast_src: Disconnected

Thanks,
Chris

[Karl Ylvisaker]

Hello Chris,

Thank you for your patience with this, and for including the logs.

ChrisBon said:

yes the original SDK was 2.1.2, so I have a feeling we are much further back then it would not allow me just to swap out the controller firmware.

Yes, this will require an update to the SDK in order to use the newer controllers, so I would highly recommend this.

ChrisBon said:

bt_mgmt: Disconnected: B8:4C:87:C0:27:27 (public) (reason 0x3e)

This means that the connection failed to be established, and could be caused by a couple of reasons.
Just to be sure, are you using a nRF5340 Audio DK for your broadcaster source and central for the connection to your custom ear bud boards?

The issue you describe sounds very similar to the known BIS + ACL issue with the earlier controller versions - could you give this another try with the newer nRF Connect SDK version and controller version?


Best regards,
Karl

[ChrisBon]

Karl,

This was running the latest 2.5.2, on the nRF5340 Audio DK as my broadcaster source and central for the connection to buds.  I am finishing porting the new 2.5.2 into our source for our custom case board, and should have that completed today.  Once that is done I can try an nRF5340 Audio DK board as both source and sink for the broadcast to see if that works.

Are there any examples of someone doing this same thing ?  Maybe I am just doing something wrong ?

Thanks,
Chris

[Karl Ylvisaker]

Hello Chris,

ChrisBon said:

This was running the latest 2.5.2, on the nRF5340 Audio DK as my broadcaster source and central for the connection to buds.  I am finishing porting the new 2.5.2 into our source for our custom case board, and should have that completed today.  Once that is done I can try an nRF5340 Audio DK board as both source and sink for the broadcast to see if that works.

Thank you for clarifying. I am glad to hear that you've updated the project to the newest SDK version, and I look forward to hearing how this test goes! If you could share the full logger output from this test that would also be great to see.

If this does not resolve the issue then I think we should proceed to capture a sniffer trace of the communication between the devices when this happens, to see exactly what occurs and what we should look into next. Are you familiar with the nRF Sniffer tool?

ChrisBon said:

Are there any examples of someone doing this same thing ?  Maybe I am just doing something wrong ?

There are no examples of this directly unfortunately, but it should not be any different from when you add a central role to any other nRF Connect SDK based application, and it looks to me like you are getting the scanning up and running correctly (and have set it up to connect correctly), but we can also take a look at your relevant source code if you share it here in the ticket.
Please use the Insert -> Code option when sharing code here on DevZone, and please let me know if you would like me to make this ticket private before you share anything (private tickets are only viewable by yourself and the support engineers here at Nordic).


Best regards,
Karl

[ChrisBon]

Karl,

Here is my latest.  I have tried to scan an connect to multiple peripheral device and get the same issue as above (0x3E).  This seems to be a timeout on our QUALCOMM buds.

This is what I have added to our prj.conf

CONFIG_BT_PER_ADV=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_MAX_CONN=2
#CONFIG_BT_SCAN_WITH_IDENTITY=y

And this is what I have changed in the streamctrl_broadcast_source.c

int streamctrl_start(void)
{
	int ret;
	static bool started;

	if (started) {
		LOG_WRN("Streamctrl already started");
		return -EALREADY;
	}

	size_t ext_adv_size = 0;
	size_t per_adv_size = 0;
	const struct bt_data *ext_adv = NULL;
	const struct bt_data *per_adv = NULL;

	ret = audio_system_init();
	ERR_CHK_MSG(ret, "Failed to initialize the audio system");

	ret = zbus_subscribers_create();
	ERR_CHK_MSG(ret, "Failed to create zbus subscriber threads");

	ret = zbus_link_producers_observers();
	ERR_CHK_MSG(ret, "Failed to link zbus producers and observers");

	ret = broadcast_source_enable();
	ERR_CHK_MSG(ret, "Failed to enable broadcaster");

	broadcast_source_adv_get(&ext_adv, &ext_adv_size, &per_adv, &per_adv_size);

	ret = bt_mgmt_adv_start(ext_adv, ext_adv_size, per_adv, per_adv_size, false);
	ERR_CHK_MSG(ret, "Failed to start advertiser");

#if 1
	// now start the scanner as well
	if (IS_ENABLED(CONFIG_BT_CENTRAL)) {
		ret = bt_mgmt_scan_start(0, 0, BT_MGMT_SCAN_TYPE_CONN, NULL);
		if (ret) {
			LOG_ERR("Failed to restart scanning: %d", ret);
		}
	}
#endif
	started = true;

	return 0;
}

In the above code, if I comment out the bt_mgmt_adv_start() call then the central connection is made and stays connected.

Is there just a configuration that we are missing ?

Thanks,
Chris

[ChrisBon]

After playing with the connection parameters, I am able to get central to usually connect, sometimes it still fails the first time.

#define CONNECTION_PARAMETERS                                                                      \
	BT_LE_CONN_PARAM(CONFIG_BLE_ACL_CONN_INTERVAL, CONFIG_BLE_ACL_CONN_INTERVAL,               \
			 CONFIG_BLE_ACL_SLAVE_LATENCY, CONFIG_BLE_ACL_SUP_TIMEOUT)

#define NEW_CONNECTION_PARAMETERS                                                                      \
	BT_LE_CONN_PARAM(100, 100,               \
			 2, 250)

However, now I get these errors and audio breaks up which was not occurring prior to this ?

GW [00:00:47.267,120] <wrn> broadcast_source: HCI ISO TX overrun on ch 0 - Single print
GW [00:00:47.267,150] <wrn> streamctrl_brcast_src: Problem with sending LE audio data, ret: -12

[Karl Ylvisaker]

Hello,

ChrisBon said:

Here is my latest.  I have tried to scan an connect to multiple peripheral device and get the same issue as above (0x3E).  This seems to be a timeout on our QUALCOMM buds.

0x3e is failed to establish connection, which usually means that the peripheral did not reply to the CONN_IND packet sent by the central device. Does the earbuds you are testing against have any particular set of connection parameters that they must use?

ChrisBon said:

After playing with the connection parameters, I am able to get central to usually connect, sometimes it still fails the first time.

Does it then still fail with the 0x3e error, failed to establish connection?
If not, could you possibly capture a sniffer trace of the communication when this happens?
It would be very helpful to see what is being exchanged before it fails.

ChrisBon said:

However, now I get these errors and audio breaks up which was not occurring prior to this ?

GW [00:00:47.267,120] <wrn> broadcast_source: HCI ISO TX overrun on ch 0 - Single print
GW [00:00:47.267,150] <wrn> streamctrl_brcast_src: Problem with sending LE audio data, ret: -12

errno 12 is ENOMEM, which means that there is not sufficient memory resources for the operation, which in this case seems to be returned from the bt_le_audio_tx_send call, which returns this if the number of streams exceeds the configured amount.
Could you share your full kconfig configuration for your project? You can find it under build/zephyr/ named .conf.

It would also still be great to see the full application log's output from when this happens, if possible.

Best regards,
Karl

[ChrisBon]

Prj.conf

#
# Copyright (c) 2022 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# nRF5340 Audio
CONFIG_NRF5340_AUDIO=y

# General
CONFIG_DEBUG=y
CONFIG_DEBUG_INFO=y
CONFIG_ASSERT=n
CONFIG_STACK_USAGE=y
CONFIG_THREAD_RUNTIME_STATS=y
CONFIG_STACK_SENTINEL=y
CONFIG_INIT_STACKS=y

# Uart driver
CONFIG_SERIAL=y
CONFIG_UART_ASYNC_API=y

# Logging
CONFIG_LOG=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
CONFIG_LOG_TAG_MAX_LEN=2
CONFIG_LOG_TAG_DEFAULT="--"
CONFIG_LOG_BACKEND_UART=y

# Console related defines
CONFIG_CONSOLE=y
CONFIG_RTT_CONSOLE=n
CONFIG_UART_CONSOLE=y

# Shell related defines
CONFIG_SHELL=y
CONFIG_KERNEL_SHELL=y
CONFIG_USE_SEGGER_RTT=n
## Disable logs on RTT
CONFIG_SHELL_RTT_INIT_LOG_LEVEL_NONE=y
CONFIG_SHELL_BACKEND_RTT=y
CONFIG_SHELL_BACKEND_SERIAL=n
CONFIG_SHELL_VT100_COLORS=y
CONFIG_SHELL_STACK_SIZE=1024
CONFIG_SHELL_CMD_BUFF_SIZE=128
## Reduce shell memory usage
CONFIG_SHELL_WILDCARD=n
CONFIG_SHELL_HELP_ON_WRONG_ARGUMENT_COUNT=n
CONFIG_SHELL_STATS=n
CONFIG_SHELL_CMDS=n
CONFIG_SHELL_HISTORY=y

# Turn off default shell commands 
CONFIG_I2C_SHELL=n
CONFIG_CLOCK_CONTROL_NRF_SHELL=n
CONFIG_FLASH_SHELL=n
CONFIG_DEVICE_SHELL=n

CONFIG_NRFX_UARTE2=y
CONFIG_NRFX_PRS_BOX_2=y

# I2C
CONFIG_I2C=y
CONFIG_NRFX_TWIM1=y

# Suppress LOG_ERR messages from sd_check_card_type. Because SPI_SDHC has no card presence method,
# assume card is in slot. Thus error message is always shown if card is not inserted
CONFIG_SD_LOG_LEVEL_OFF=y

# Suppress LOG_INF messages from hci_core
CONFIG_BT_HCI_CORE_LOG_LEVEL_WRN=y

CONFIG_AUDIO_DEV=2
CONFIG_AUDIO_SOURCE_I2S=y

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_COMMON_LIBC_MALLOC=n
CONFIG_DEBUG_THREAD_INFO=y

#CONFIG_NRFX_SPIM4=y
#CONFIG_SPI_SDHC=y
CONFIG_SPI=y
CONFIG_SPI_ASYNC=y
CONFIG_NRFX_SPIM1=y
CONFIG_I2C_TARGET=y
CONFIG_PWM=y
#CONFIG_SDMMC_SUBSYS=y
CONFIG_NEWLIB_LIBC_MIN_REQUIRED_HEAP_SIZE=2048
CONFIG_DEBUG_THREAD_INFO=y
CONFIG_BT_AUDIO_USE_BROADCAST_ID_RANDOM=n
#CONFIG_BT_AUDIO_BROADCAST_ID_FIXED=0x004A7526
# for now disable BT controller watchdog
CONFIG_WDT_CTLR=n

#Enable MCUBOOT bootloader build in the application
#CONFIG_BOOTLOADER_MCUBOOT=y
#Include MCUMGR and the dependencies in the build
#CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
#CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y
#CONFIG_AUDIO_DFU=1

#CONFIG_MAIN_LOG_LEVEL_ERR=y
#CONFIG_AUDIO_HEADSET_CHANNEL_COMPILE_TIME=y
CONFIG_BT_PER_ADV=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_MAX_CONN=2

CONFIG_TRANSPORT_BIS=y
#CONFIG_BT_SCAN_WITH_IDENTITY=y

Log file

-- [00:00:00.254,455] <err> i2c_nrfx_twim: Error 0x0BAE0001 occurred for message 0
GW [00:00:00.254,455] <err> INA230: Failed to write configuration register!
GW [00:00:00.254,638] <err> i2c_nrfx_twim: Error 0x0BAE0001 occurred for message 0
GW [00:00:00.254,638] <err> INA230: Failed to write configuration register!
GW [00:00:00.255,767] <err> i2c_nrfx_twim: Error 0x0BAE0001 occurred for message 0
GW [00:00:00.255,767] <err> INA230: Failed to write configuration register!
*** Booting nRF Connect SDK v2.5.2 ***
GW [00:00:00.256,317] <inf> fw_info: 
	 nRF5340 Audio nRF5340 Audio DK cpuapp 			    
	 NCS base version: 2.5.2 			    
	 Cmake run : Thu Feb 29 09:37:19 2024
GW [00:00:00.256,317] <inf> fw_info: ------- DEBUG BUILD -------
GW [00:00:00.256,317] <inf> fw_info: Compiled for GATEWAY device
GW [00:00:00.257,812] <err> max17303: Register 0x1C0 = 00
GW [00:00:00.258,392] <err> max17303: Register 0x1C1 = 00
GW [00:00:00.258,972] <err> max17303: Register 0x1C2 = 00
GW [00:00:00.259,552] <err> max17303: Register 0x1C3 = e000
GW [00:00:00.260,131] <err> max17303: Device Name Read 407c
GW [00:00:00.260,711] <err> max17303: Device Name Read 407c
GW [00:00:00.261,260] <err> max17303: Device Name Read 407c
GW [00:00:00.347,961] <err> max17303: Register 0x1FD = 303 03
GW [00:00:00.348,114] <inf> mxc4005: Device Found
GW [00:00:00.485,565] <inf> esp32: send Command (cmd: 208) (l: 1)
GW [00:00:00.502,105] <inf> esp32: send Command (cmd: 208) (l: 1)
GW [00:00:01.348,205] <inf> esp32: send Command (cmd: 129) (l: 4)
GW [00:00:01.448,242] <inf> iqs7222a: IQS7222A Initialization:
GW [00:00:01.548,553] <inf> iqs7222a: Product number is: 840 v 0.0
GW [00:00:01.548,553] <inf> iqs7222a: IQS7222A Release UI Confirmed!
GW [00:00:01.710,540] <inf> esp32: send Command (cmd: 130) (l: 0)
GW [00:00:02.210,601] <inf> main: Read ESP Mac 1
GW [00:00:02.210,601] <inf> esp32: send Command (cmd: 130) (l: 0)
GW [00:00:02.710,662] <inf> main: Read ESP Mac 2
GW [00:00:02.710,662] <inf> esp32: send Command (cmd: 130) (l: 0)
GW [00:00:03.210,693] <inf> main: Read ESP Mac 3
GW [00:00:03.210,723] <inf> esp32: send Command (cmd: 130) (l: 0)
GW [00:00:03.471,496] <inf> esp32: send Command (cmd: 129) (l: 4)
GW [00:00:03.472,656] <inf> esp32: Mac ID [2] cc:db:a7:4a:75:26
GW [00:00:03.524,169] <inf> esp32: CC Speed  1 false
GW [00:00:03.524,902] <inf> esp32: Update Mode 1
GW [00:00:03.710,784] <inf> main: Read ESP Mac 4
GW [00:00:03.722,412] <inf> bt_mgmt_ctlr_cfg: Controller: LL_ACS_NRF53. Version: 3424
GW [00:00:03.723,052] <inf> bt_mgmt: Local identity addr: ED:3E:DF:45:16:B7 (random)
GW [00:00:03.724,578] <inf> broadcast_source: Enabling broadcast_source NRF5340_BROADCASTER
GW [00:00:03.725,463] <inf> broadcast_source: Broadcast ID 004a7526
GW [00:00:03.727,081] <inf> bt_mgmt_scan: Start Scan
GW [00:00:03.727,996] <inf> bt_mgmt_adv: Local addr: 3C:8D:63:69:5B:85 (random)
GW [00:00:03.729,248] <inf> bt_mgmt_scan: Local addr: ED:3E:DF:45:16:B7 (random). May time out. Updates not printed
GW [00:00:03.729,278] <inf> bt_mgmt_scan: Scanning successfully started
GW [00:00:03.730,133] <inf> streamctrl_brcast_src: Ext adv ready
GW [00:00:03.730,590] <inf> bt_mgmt_adv: Advertising successfully started
GW [00:00:03.858,123] <inf> broadcast_source: Broadcast source 0x2000c098 started
GW [00:00:03.858,337] <inf> broadcast_source: Broadcast source 0x2000c0bc started
GW [00:00:03.882,415] <inf> audio_datapath: Drft comp state: CALIB
GW [00:00:03.915,802] <inf> bt_mgmt_scan: Device found: B8:4C:87:C0:27:3E (public) (RSSI -22)
GW [00:00:03.916,473] <inf> bt_mgmt_scan: Creating connection to device: B8:4C:87:C0:27:3E (public)
GW [00:00:03.982,391] <inf> audio_datapath: Drft comp state: INIT
GW [00:00:03.983,398] <inf> audio_datapath: Drft comp state: CALIB
GW [00:00:04.083,404] <inf> audio_datapath: Drft comp state: OFFSET
GW [00:00:04.175,415] <inf> bt_mgmt: check Connected 0
GW [00:00:04.175,415] <inf> bt_mgmt: check Connected new connection 1
GW [00:00:04.175,445] <inf> bt_mgmt: Connected: B8:4C:87:C0:27:3E (public)
GW [00:00:04.175,445] <inf> bt_mgmt_scan: Start Scan
GW [00:00:04.176,025] <inf> bt_mgmt_scan: Local addr: ED:3E:DF:45:16:B7 (random). May time out. Updates not printed
GW [00:00:04.176,025] <inf> bt_mgmt_scan: Scanning successfully started
GW [00:00:04.176,269] <inf> streamctrl_brcast_src: Connected
GW [00:00:05.483,337] <inf> iqs7222a: Status 00, Events 02 00, touch 00 00. prox 00 00
GW [00:00:05.483,367] <inf> iqs7222a: Lid Open
GW [00:00:05.483,367] <inf> esp32: send Command (cmd: 208) (l: 1)
GW [00:00:06.901,580] <wrn> broadcast_source: HCI ISO TX overrun on ch 0 - Single print
GW [00:00:06.901,580] <wrn> streamctrl_brcast_src: Problem with sending LE audio data, ret: -12
GW [00:00:07.031,738] <wrn> broadcast_source: HCI ISO TX overrun on ch 0 - Single print
GW [00:00:07.031,768] <wrn> streamctrl_brcast_src: Problem with sending LE audio data, ret: -12
GW [00:00:07.183,197] <inf> audio_datapath: Drft comp state: LOCKED
GW [00:00:07.281,646] <wrn> broadcast_source: HCI ISO TX overrun on ch 0 - Single print
GW [00:00:07.281,677] <wrn> streamctrl_brcast_src: Problem with sending LE audio data, ret: -12
GW [00:00:07.531,707] <wrn> broadcast_source: HCI ISO TX overrun on ch 0 - Single print
GW [00:00:07.531,707] <wrn> streamctrl_brcast_src: Problem with sending LE audio data, ret: -12
GW [00:00:07.831,665] <wrn> broadcast_source: HCI ISO TX overrun on ch 0 - Single print
GW [00:00:07.831,695] <wrn> streamctrl_brcast_src: Problem with sending LE audio data, ret: -12
GW [00:00:13.782,775] <inf> audio_datapath: Drft comp state: INIT
GW [00:00:13.783,782] <inf> audio_datapath: Drft comp state: CALIB
GW [00:00:13.883,758] <inf> audio_datapath: Drft comp state: OFFSET