[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]

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, Ben

Great - I am glad that you were able to acquire some so quickly, and that you have already been able to start testing and have some success.

bstewart-cae said:

I was unable to roll back to a version of software where they worked out of the box

Which version are they on now? I know that the latest/troublesome version is RS10XXUDAWF4.

bstewart-cae said:

I was able to get one at a time to connect, whichever one it found first, but only immediately after flashing. Once the bonded list was full, the buds would refuse to connect and I'd have to reflash it to get it to work. As far as I can tell, the buds are not sending direct pairing requests, which is the only way to trigger the bond_connect function, and I did try changing the scan filter from 'filter_duplicate' to 'none', but that didn't seem to change anything - I also have tried active scanning and that didn't seem to work either.

Could you possibly capture a sniffer trace of this? This would be very helpful for seeing what goes wrong in the setup of the connection.

I also see from your log that you are using the 3349 controller, please upgrade to the 3393 controller for these tests. The controllers are 'drag-and-drop' interchangeable, so you can just download the 3393 from here, and place it in the same location in your SDK directory to change which is being flashed to your device.
Please move the 3349 out from this location when you do so, since the build script only expects to find 1 .hex controller .hex file in this location.

bstewart-cae said:

What changes have you made to the application to work with the Samsung buds? If I can recreate your 'known working', maybe I can help figure out what's going on.

I spoke to the engineer who's done most of our testing against the Samsung Galaxy Pro 2 buds, and this is the main takeaways:

The current issue we are seeing when testing against the newest Galaxy Buds firmware is related to the service discovery, as we are doing both service discovery and endpoint configuration at the same time, which seems to break in the newest Galaxy buds firmware.

The engineer in question has made this quick fix for the service discovery issue:
Quick fix for service discover issue · nrfconnect/sdk-nrf@6c549de · GitHub
Please add this to your application, and see if this resolves the discovery issue.

I must also end with the 'disclaimer' that we can not guarantee that the galaxy buds will work at any time against our LE Audio reference application (until both are fully LE Audio qualified, of course), since we are not in control of the changes that they make to their firmware at any time, and since this is not a Nordic product it is not something that we run continuous testing against, unfortunately.
You mentioned that this is a blocker for you - could you elaborate on what is being blocked by the third-party earbuds failing? I ask this just to get a better overview of the situation on your side.

Best regards,
Karl

[bstewart-cae]

Hey Karl,

Looks like that did the trick. the fix and new BLE controller seems to work pretty well. There are some stability issues but I can connect, reset, do whatever I need to and it seems to work about as well as I can expect at the moment, given the nebulous state of Samsung's firmware.

Karl Ylvisaker said:

Which version are they on now? I know that the latest/troublesome version is RS10XXUDAWF4.

R510XXU0AWI2. Thankfully this isn't the 'broken' version.

Karl Ylvisaker said:

must also end with the 'disclaimer' that we can not guarantee that the galaxy buds will work at any time against our LE Audio reference application (until both are fully LE Audio qualified, of course), since we are not in control of the changes that they make to their firmware at any time, and since this is not a Nordic product it is not something that we run continuous testing against, unfortunately.

Oh of course, this is a new technology and we're all kind of figuring this out as we go. The reason I was concerned is that we're currently working out all of the signal paths and this one is the last wild card, and I didn't want to test with dev kits because building our own headphones is not in the scope of the project, so I wanted to test with the products that our device would be used with.

I'll keep you updated when I hear back from OnePlus. I plan on doing some more testing of my own as well.

Karl Ylvisaker said:

Could you possibly capture a sniffer trace of this? This would be very helpful for seeing what goes wrong in the setup of the connection.

It isn't presenting the issue anymore so if it pops back up I'll be sure to get you that.

[Karl Ylvisaker]

Hello again, Ben

I am glad to read that you now have the Samsung buds up and running and that you are no longer blocked by this, great! :) 

bstewart-cae said:

Oh of course, this is a new technology and we're all kind of figuring this out as we go. The reason I was concerned is that we're currently working out all of the signal paths and this one is the last wild card, and I didn't want to test with dev kits because building our own headphones is not in the scope of the project, so I wanted to test with the products that our device would be used with.

Thank you for your understanding - when things settle down and all devices are qualified this will all be a lot easier, but the journey there can sometimes indeed be a little bumpy.

bstewart-cae said:

I'll keep you updated when I hear back from OnePlus. I plan on doing some more testing of my own as well.

Great, that would be very helpful - I have not worked with the OnePluss' myself yet, but I am of course interested in any developments on this area :) 

bstewart-cae said:

It isn't presenting the issue anymore so if it pops back up I'll be sure to get you that.

I must note that the nRF Sniffer does not have ISO support, but it is still a great tool for debugging the connectivity issues you mentioned with the ACL (regular BLE Connection/non-ISO connection).
Let's look back into this if the issues with establishing the connection ever should return.

Best regards,
Karl

[bstewart-cae]

FYI - this is the response from OnePlus:

Upon escalating your case with our relevant team, I would want to keep you informed the details mentioned below:

1. BLE currently relies on joint debugging by mobile phone manufacturers and is not yet open to the public.
2. There are currently no plans to support BIS

I hope the provided information has addressed your query. If you require any additional assistance, please don't hesitate to reach out to us.

This is disappointing, but it sounds like they're not going for mass adoption until more phones support the codec.

Also, the firmware that I just put on my Samsung buds claims to support Auracast - I haven't been able to find any documentation on whether or not this is the same thing as BIS or a different technology entirely. Our end goal is one-to-many, so we may be able to get a head start on this.

[Karl Ylvisaker]

Thank you for the update, Ben.

bstewart-cae said:

This is disappointing, but it sounds like they're not going for mass adoption until more phones support the codec.

Yes, this is disappointing indeed - it is also daunting that it takes this much digging to get to the bottom of whether a product has support - and what level of support - for the different LE Audio features. Perhaps they might want to unveil the Auracast support as a separate feature in later models or similar - but this is just my personal speculations.

bstewart-cae said:

Also, the firmware that I just put on my Samsung buds claims to support Auracast - I haven't been able to find any documentation on whether or not this is the same thing as BIS or a different technology entirely. Our end goal is one-to-many, so we may be able to get a head start on this.

Auracast is the 'branding'/brand name of LE Audio's broadcast feature and so they might support this in their earbuds, but you wont see much use of it until you also have a 'commander' device (typically your phone) to choose which broadcast you will listen in to.

The good news is that you can still develop your broadcaster already - and test it against the nRF5340 Audio DK, or some of the few hearing aids which have recently come out with Auracast support - and then test it with devices closer to your use-case (earbuds and phones) once they make this support available.

Best regards,
Karl