[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

[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

[bstewart-cae]

Hey Karl,

I did as you suggested (including fully erasing and recovering the 5340 and resetting the earbuds) and there was no change in the log or response. I will experiment with tweaking some of the connection parameters to see if there's a timing issue.

Karl Ylvisaker said:

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.

I submitted a ticket late last week and last I heard it has been kicked over to their engineering team. I have yet to hear back, as soon as I know anything I'll forward it here. I asked about connection tweaks that I need for the buds to work and if there are any plans to support BIS.

[bstewart-cae]

Karl Ylvisaker said:

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'.

 Karl Ylvisaker , this does open up an additional question - Have you confirmed that the Samsung buds pro 2 work with the nRF5340 gateway? What other earbuds/headests/headphones is nordic using for testing and can be confirmed to work? I think it's valuable to identify the issue with the OnePlus buds, for certain, but if there are available earbuds on the market that do work out of the box, that would be helpful in our current situation as this is currently a blocking issue.

[Karl Ylvisaker]

Hello,

bstewart-cae said:

I submitted a ticket late last week and last I heard it has been kicked over to their engineering team. I have yet to hear back, as soon as I know anything I'll forward it here. I asked about connection tweaks that I need for the buds to work and if there are any plans to support BIS.

Thanks for the update - I look forward to hearing their reply! :) 

bstewart-cae said:

this does open up an additional question - Have you confirmed that the Samsung buds pro 2 work with the nRF5340 gateway? What other earbuds/headests/headphones is nordic using for testing and can be confirmed to work? I think it's valuable to identify the issue with the OnePlus buds, for certain, but if there are available earbuds on the market that do work out of the box, that would be helpful in our current situation as this is currently a blocking issue.

Yes, we have primarily tested against the Samsung Buds Pro 2 here at the support department, so these are the ear buds that we have the most knowledge about.

These worked out of the box until their most recent update, which caused something to break - if you revert them to the previous version they still work out of the box.
I will check with the engineer who most recently did tests on the latest Samsung Galaxy Buds Pro II version and see if they have any update on what went wrong with the latest update.

Best regards,
Karl

[bstewart-cae]

Hey Karl,

I went ahead and picked up a pair to run some testing. I was unable to roll back to a version of software where they worked out of the box, but I did have some success on the latest version of firmware that i got from the Samsung app. 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.

I went ahead and logged the output of the device and have attached it below. Hopefully an additional data point would help.

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. serial_20231005_161050.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.