Mix BLE audio and custom BLE Characteristic

[bojan]

Hello, everyone!

I'm interested to know about the possibility of mixing BLE audio and custom BLE Characteristic in one single nRF5340 application.

For example, we would like to mix:

1. A True Wireless Earbud (TWS) BLE audio topology with mono output and microphone input for two-way audio communication and
2. Custom BLE Characteristic that will be used for transferring data collected from various sensors

If there is no possibility to mix BLE audio with the Custom BLE Characteristic for data transfer, would it be possible to have run-time reconfiguration and change the desired BLE profile during run time?

I know that we must have LE Audio Controller for nRF53 app binary implemented in the network core of nRF5340 for BLE audio profile. Is this any blocker for using custom BLE characteristic for data transfer?

Thanks in advance for your time and efforts.

Sincerely,
Bojan.

[Hieu]

Hi Bojan,

Yes, it is possible to setup a custom GATT Characteristic when you are using the BLE Audio feature together with the LE Audio Controller.

Could you please give a little more details on which devices have to connect to which for the sensor data in your example? There is a limit on the number of concurrent connections a device with the LE Audio Controller can maintain.

Hieu

---

Due to Christmas & New Year Holidays, our team is currently understaffed and will take longer than usual for responses and follow-ups. Our apologies for the inconvenience.

[bojan]

Hello, Hieu 

Sorry for the late reply.

We would basically have one single BLE Central device (e.g the smartphone) that will be used to establish a connection with nRF53.

We would need to:

1. Establish two-way audio communication (TWS topology) between nRF53 and BLE Central
2. Collect the data from various sensors and transfer them to the BLE Central device using a custom-defined BLE Service with multiple custom BLE Characteristics.

Those two should exist in parallel (ideally) or it would be nice if we could reconfigure the BLE part during run-time to run either in TWS BLE audio mode or in data collection mode.

I hope it's now clear what we want to achieve.

Sincerely,
Bojan.

[Hieu]

Hi Bojan,

Thank you for the information. I am out of office for the rest of the week so I will answer you latest by the end of next Tuesday, Jan 10. If you need support more urgently, please let me know and I will arrange some alternatives.

Best regards,

Hieu

[bojan]

No worries, Hieu, it's not urgent. We are in the research and development phase.

Thanks for your readiness to help, though!

Looking forward to hearing from you.

Sincerely,
Bojan.

[Hieu]

Hi Bojan,

Thank you for your patience.

I understand that, both your two-way audio communication (ISO Link) and the sensor data communications (ACL Link) are between the same nRF53 device and the same BLE Central, is this right?

If so, this is doable. The two "links" can run at the same time, and you should not have to reconfigure them during run time.

Are you going to send sensor data often, or will the data be large? Currently, the LE Audio Controller has some difficulties running both an ISO Link and a high throughput ACL Link at the same time. It is being improved, but that is the current state.

Best regards,

Hieu

[bojan]

Hello, Hieu . 

Thanks for the feedback. You are right, both ISO and ACL links are between the same nRF53 device and the same BLE Central. 

However, the ACL link should send sensor data continuously. There will be readings from quite a few sensors so I can also say that the data are large. 

The good thing is that we don't need ISO link too often. We might decide to stop transferring sensor data when we need audio link. That way, both profiles will co-exist without a need for reconfiguration on BLE side. Is that feasible?

Regards,
Bojan.

[Hieu]

Hi Bojan,

How large is your sensor data and how often do you send it? Raw sensor data are usually not too bad.

I consulted an LE Audio engineer and it is also possible to send the sensor data over the ISO link. The ACL link will always be there, because it is necessary to control the ISO link.

Thus, you have two options:

• Sensor data over ISO link
  • Pro: Quick
  • Cons: Data can be lost
  • Cons: Pretty much not possible to have audio comm at the same time as sensor data transfer
• Sensor data over ACL link
  • Pro: Reliable. No package is dropped.
  • Cons: High throughput at the same time as audio comm is difficult

As you don't need both audio comm and sensor data transfer at the same time, both are feasible for you, I believe.

Best wishes,

Hieu

[bojan]

Hello, Hieu .

Don't know by heart about size of data but the MTU size will be 250Bytes and the connection interval not above 12.5ms.

Anyway, good thing is that we could stop some of the sensor readings when we want BLE audio link.

What would be the code we need for the network CPU in this use case?

Regards,
Bojan.

[Karl Ylvisaker]

Hello Bojan,

Hieu is unfortunately unavailable for a couple of days, so I will follow this up in his absence.

bojan said:

Anyway, good thing is that we could stop some of the sensor readings when we want BLE audio link.

Great, then you can send the sensor data over the ACL link when the audio is paused and visa versa without issue.

bojan said:

What would be the code we need for the network CPU in this use case?

The network core must be programmed with the precompiled LE Audio Controller, so you do not need to write any code for the network core specifically.
Please note that we are aware of a stability issue with the current controller when the ACL connection interval is not a 2x multiple of the ISO interval, so please make sure to only use a 2x multiple of the ISO interval for your ACL connection interval to avoid this.
You should also avoid updating the ACL connection interval while the ISO is transferring audio for the same reason, if possible.
We are of course working on a fix for this already, but just keep it in mind for the time being! :)

Best regards,
Karl

[bojan]

Thanks for the update, Karl Ylvisaker .

For transferring sensor readings, we need a connection interval of at least 12.5ms (10 x 1.25).

What is the value of the ISO interval? Is it something fixed or flexible? Can we make it to be 5 x 1.25ms?

Best regards,
Bojan.

[Karl Ylvisaker]

Hello Bojan,

bojan said:

Thanks for the update, Karl Ylvisaker .

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

The ISO interval used is primarily 10 ms currently, but since you are stopping the ISO stream before you start your sensor data transfer then this consideration does not apply, so you can use whichever connection interval as you would like, just as with a regular BLE (non-ISO) connection.

Best regards,
Karl