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