[nRF5340 Audio Example Application] Device will not connect to TWS earbuds that support LC3

[bstewart-cae]

I am working on project based off of the nRF5340 chip. I'm using the audio example application to run some proof of concept tests so we can finalize our electrical design, however, I am running into issues getting the Gateway to connect to anything other than other dev kits. I purchased a pair of OnePlus Buds Pro 2 which according to the website and my bluetooth sniffer support Bluetooth 5.3 and the LC3 codec (one of two currently on the market, the other being the Samsung Buds 2 Pro). 

The earbuds are on the latest firmware, but will not pair with the gateway, and I can't tell if the gateway is seeing the beacons off of the earbuds, ignoring them, or trying to connect unsuccessfully.

The gateway is currently running in USB audio mode and CIS transport.

I'm using sdk version 2.4.2 on Ubuntu 22.04.

A couple thoughts:

When the dev kits are beaconing, they report that they are 'BR/EDR not supported'.

the earbuds report as follows:

Also, according to the sniffer, the earbuds report that they support LE or dual mode, but are advertising on Legacy.

These are my questions:

- Does the fact that the Earbuds are reporting that they are BR/ERD capable keep them from connecting with the gateway? This should just be a flag saying they CAN support dual mode, not that the server MUST support it, is this correct?

- How come the gateway cannot connect to the earbuds and just negotiate an LE connection and LC3 codec? The earbuds are compatible, and this has been tested using a pixel 7 set to LC3.

- Is this a limitation in the nRF5340 chip or the earbuds?

- Can the gateway even see devices that are advertising on Legacy?

 - If not, I have further questions regarding the life cycle of these chips and how they will interact with existing earbuds.

Any ideas? the goal is simply to get them to connect and listen to music.

[Karl Ylvisaker]

Hello,

according to the website and my bluetooth sniffer support

Just to be sure, do you have access to a LE Audio compatible sniffer tool like the Ellisys sniffer, or are you here referring to using the nRF Connect for Smartphones application to look at the advertised packets?

I'm using the audio example application to run some proof of concept tests so we can finalize our electrical design, however, I am running into issues getting the Gateway to connect to anything other than other dev kits

Have you made any changes at all to the LE Audio reference application, or is it running as its default?
The default behavior of the LE Audio reference application is to establish connections to peers that advertise a specific name, so all advertisements are filtered based on this, which could be the reason why you are not seeing it react at all to the eaburds.
The name it by default is scanning for is NRF5340_AUDIO + LEFT or RIGHT.

- Does the fact that the Earbuds are reporting that they are BR/ERD capable keep them from connecting with the gateway? This should just be a flag saying they CAN support dual mode, not that the server MUST support it, is this correct?

Your understanding of this is correct - the flag is only used to signify to the scanner what the advertiser supports, it does not prevent the central from connecting (unless the device does not support LE Audio, and you have an LE Audio only scanner, for instance).

- Can the gateway even see devices that are advertising on Legacy?

Yes, the gateway can see BLE legacy advertisements - all BLE qualified devices can do this.

 - If not, I have further questions regarding the life cycle of these chips and how they will interact with existing earbuds.

I am not sure I understand this question completely, could you elaborate?
On a general note I must mention that LE Audio is a new specification entirely, and so there is no backwards compatibility between LE Audio (only) devices and Bluetooth Classic (only) devices. If one of them however is a dual/hybrid device then there should be no issue.

Please make changes to the scan filter and see if you then register the devices.

Best regards,
Karl

[bstewart-cae]

Hey Karl,

Thank you for your detailed reply.

Karl Ylvisaker said:

Have you made any changes at all to the LE Audio reference application, or is it running as its default?
The default behavior of the LE Audio reference application is to establish connections to peers that advertise a specific name, so all advertisements are filtered based on this, which could be the reason why you are not seeing it react at all to the eaburds.

This is probably my roadblock at the moment - I will pursue this first. I am using the sample application as-is in this instance, however, I have cut up and heavily modified the application for other use cases and never came across this functionality. I am unsure how I would go about making changes, can you give some direction at least on where this would be located in source?

Karl Ylvisaker said:

On a general note I must mention that LE Audio is a new specification entirely, and so there is no backwards compatibility between LE Audio (only) devices and Bluetooth Classic (only) devices. If one of them however is a dual/hybrid device then there should be no issue.

Yes, LE audio is very much the goal here. We want to take advantage of the broadcast capabilities inherent to the BLE spec, but we're limited by whats available. We did a lot of research to ensure that these headphones would support the correct spec.

Karl Ylvisaker said:

 - If not, I have further questions regarding the life cycle of these chips and how they will interact with existing earbuds.

I would ignore this question. I was concerned that if the chip needed a LE-only headphone to work,I wasn't really sure what to do next as there are zero LC3-only headphones currently available and I don't see LE audio specific (not dual-mode) headphones being available for years.

[bstewart-cae]

I went ahead and made the changes you suggested in the the le_audio_cis_gateway.c file within the application. I went ahead and added a separate config option with the the advertised name of the earbuds, and changed the device_found cb to try to connect to the buds if it finds them. This seems to work as intended, however, the earbuds reject the connection and I'm trying to figure out why. It appears to have something to do with an inability to exchange the connection encryption key, or that the earbuds don't trust the connection. Maybe because the mac address is randomized? I'm using the same connection parameters that the other dev kits use. Hopefully you guys can take a look.

The new function is as shown:

static int device_found(uint8_t type, const uint8_t *data, uint8_t data_len,
			const bt_addr_le_t *addr)
{
	int ret;
	struct bt_conn *conn;


	if (ble_acl_gateway_all_links_connected()) {
		LOG_DBG("All headset connected");
		return 0;
	}

	if ((data_len == DEVICE_NAME_PEER_LEN) &&
	    (strncmp(DEVICE_NAME_PEER, data, DEVICE_NAME_PEER_LEN) == 0)) {
		LOG_DBG("nRF Devkit Device found");

		ret = bt_le_scan_stop();
		if (ret) {
			LOG_WRN("Stop scan failed: %d", ret);
		}

		ret = bt_conn_le_create(addr, BT_CONN_LE_CREATE_CONN, CONNECTION_PARAMETERS, &conn);
		if (ret) {
			LOG_ERR("Could not init connection");
			ble_acl_start_scan();
			return ret;
		}

		return 0;
		// Added support for the OnePlus buds
	} else if ((data_len == DEVICE_NAME_EXT_LEN) &&
	    		(strncmp(DEVICE_NAME_EXT, data, DEVICE_NAME_EXT_LEN) == 0)) {
		LOG_DBG("Located supported third party headphones: \"%s\"",DEVICE_NAME_EXT); 
		// Attempt connection with external LC3-compatible device.
		ret = bt_le_scan_stop();
		if (ret) {
			LOG_WRN("Stop scan failed: %d", ret);
		}

		ret = bt_conn_le_create(addr, BT_CONN_LE_CREATE_CONN, CONNECTION_PARAMETERS, &conn);
		if (ret) {
			LOG_ERR("Could not init connection");
			ble_acl_start_scan();
			return ret;
		}
	}

	return -ENOENT;
}

My config option is here: (mapped to a #define statement)

config BT_ALT_HP_SUPPORT

string "Name of supported 3rd party devices"

default "OnePlus Buds Pro 2"

help

The chip has no ability for the user to select a device in beaconing mode,

so the supported devices need to be specified as shown.

the log file from the debug output is attached. I elevated the relevant log levels to try to get as much information as possible.

The connection would fail, then the next tick it would try again, so it just looped through over and over again, trying to connect to the earbuds. Let me know if you have any insight into what is failing.

bt_log_dump.txt

Edit: Ran it with a larger log buffer and even more logging enabled.

bt_log_dump_expanded.txt

[Karl Ylvisaker]

Hello again, 

bstewart-cae said:

Thank you for your detailed reply.

No problem at all, I am happy to help! :) 

bstewart-cae said:

I am unsure how I would go about making changes, can you give some direction at least on where this would be located in source?

I am glad to see that you resolved this in the time since my last comment - sorry that my previous comment was not explicit enough about this in the first place.

bstewart-cae said:

Yes, LE audio is very much the goal here. We want to take advantage of the broadcast capabilities inherent to the BLE spec, but we're limited by whats available. We did a lot of research to ensure that these headphones would support the correct spec.

The broadcast functionality definitively opens up a whole range of new use-cases for wireless audio :)
Unfortunately, the focus among the consumer electronic vendors have primarily been on CIS thus far (and so many headsets have actually only supported CIS, up until now at least), but they are starting to bring out BIS support as well.
Have you confirmed that the OnePlus Buds Pro 2 supports BIS as well as CIS?
I ask because I do not have any personal experience with testing against the OnePlus Buds Pro 2, just so you know.

bstewart-cae said:

The connection would fail, then the next tick it would try again, so it just looped through over and over again, trying to connect to the earbuds. Let me know if you have any insight into what is failing.

bt_log_dump.txt

Edit: Ran it with a larger log buffer and even more logging enabled.

Thank you for providing the logs and the clarification on the modifications you made.
I will review this and get back to you.

Best regards,
Karl

[bstewart-cae]

Karl Ylvisaker said:

Have you confirmed that the OnePlus Buds Pro 2 supports BIS as well as CIS?
I ask because I do not have any personal experience with testing against the OnePlus Buds Pro 2, just so you know.

I have not definitively confirmed it one way or the other, but I have tested it with a broadcast gateway and so far it appears that they do not support or recognize BIS. I do not know if this is a result of whatever issues are lingering here, but I would not at all be surprised if they just don't support it. I plan on opening a ticket with OnePlus to get more information.

[Karl Ylvisaker]

Hello again,

Thank you for your patience with this.

bstewart-cae said:

but I have tested it with a broadcast gateway and so far it appears that they do not support or recognize BIS.

I think it likely could be that they only support CIS - I imagine it would have been used as a big selling point of they supported BIS/Auracast too.

bstewart-cae said:

I do not know if this is a result of whatever issues are lingering here, but I would not at all be surprised if they just don't support it. I plan on opening a ticket with OnePlus to get more information.

It would be great to have this confirmed by OnePlus - you could additionally ask them if there are any special considerations when developing an initiator (gateway) device to work with the OnePlus buds. We have seen in the past that some vendors and particular updates have caused things to break or need tweaking (initially the Samsung Earbuds Pro II for instance preferred a 45 ms Connection Interval), since most of the offerings are still 'experimental'.

These types of kinks will of course all be ironed out once it devices (both acceptors and initiators) are all qualified and tested.

bstewart-cae said:

The connection would fail, then the next tick it would try again, so it just looped through over and over again, trying to connect to the earbuds. Let me know if you have any insight into what is failing.

bt_log_dump.txt

Edit: Ran it with a larger log buffer and even more logging enabled.

Over to the work with getting it up and running smoothly with the CIS:
Looking through the provided logs I particularly notice the security failure.
The most common reason for this issue when working with BLE devices is if you have previously paired with the devices, and then reprogrammed either the initiator or the acceptor, so that only one side has lost its keys.
This will cause the old keys to be present in the peer, which will then fail the security callback. For more information you could see the discussion here.

Could you make sure that both devices are 'factory reset' or have their 'bonds erased' and then give this a try again, and see if there are any changes to the behavior or the logs?

Best regards,
Karl