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