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