nRF5340 Audio DK - broadcast commands to a specific listener

[Dekel]

Hi,

I'm developing a system that uses multiple nRF5340 chips with BLE audio. At the moment, I'm working with nRF5340 Audio DKs and the relevant example code in BIS mode.

My goal is to be able to send commands to a specific device in my BIG based on device address. For example, there could be a predefined command known to both gateway and headset, and each headset in my BIG has a unique ID which the gateway is familiar with. Based on that, the gateway is able to send command + ID and control a specific headset.

My question is what would be the right approach for achieving that?

As a POC, I was able to successfully modify the example code and plant the so called "known command" as part of the encoded audio data on the gateway side. Then, the data is received by the headset, which constantly looks for that command. Once it's found, it's being executed. The upside of that is using an already existing communication channel, but the downside is that it affects the audio itself (corrupts the data).

I was wondering how complicated it would be to create a new service under the BLE Audio Profile to solely serve the commands transmission.

Thank you,

Dekel

[ovrebekk]

Hi Dekel

How many devices would typically be listening in on the stream? 

What kind of latency requirements do you have for sending this command? 

The normal way to handle command exchange when running LE Audio applications is to run a regular Bluetooth connection (also called ACL connection) in addition to the audio stream, and use this to pass commands. This is not really practical for broadcast applications though, since you have no idea how many devices are actually receiving the stream, and it would be impractical to connect to all of them. 

Still, it should be possible to establish ad hoc connections to selected devices if they are in advertise mode while receiving the broadcast stream, but the latency will be higher compared to simply embedding some data in the audio stream directly. 

Best regards
Torbjørn

[Dekel]

Hi Torbjørn,

ovrebekk said:

How many devices would typically be listening in on the stream? 

6-7 devices.

ovrebekk said:

What kind of latency requirements do you have for sending this command? 

I would say up to 0.5 second.

ovrebekk said:

it should be possible to establish ad hoc connections to selected devices if they are in advertise mode while receiving the broadcast stream

I would adopt this solution if integrating that feature into the existing audio code example was more straightforward. I've opened another support ticket for that, but things are not going very well.

How about adding service to the BLE Audio profile? Is that doable?

[ovrebekk]

Hi Dekel

Dekel said:

How about adding service to the BLE Audio profile? Is that doable?

The whole concept of services in BLE communication is part of the GATT profile, and this profile is only available when you are in an ACL connection. In other words you are not able to send service data over a BIS or CIS stream directly, but would need to run a standard ACL connection on the side if you want to exchange service data. 

If what you mean is to send command data over a broadcast stream I think it might be easier to set up two streams, one for the audio data and one for the commands, so that you can send commands without interfering with the audio data. 

The problem with this approach is that the link will be purely one directional, and you have no way of knowing on the gateway side whether or not the headset actually received the command. 

By establishing an ACL connection you will get bi-directional communication which allows the gateway to ensure that all the commands are received, and you can also get status information back from the headsets, such as the battery state. 

Best regards
Torbjørn

[Dekel]

ovrebekk said:

If what you mean is to send command data over a broadcast stream I think it might be easier to set up two streams, one for the audio data and one for the commands, so that you can send commands without interfering with the audio data.

I would appreciate some guidance for that. From what I see in the example code, the whole "bt_stream" folder relates only to an audio stream. How do I transfer that into a command stream?

ovrebekk said:

The problem with this approach is that the link will be purely one directional, and you have no way of knowing on the gateway side whether or not the headset actually received the command. 

I was thinking about setting each audio-sink unit also as a broadcaster for a command stream. Namely, the audio-source unit will also be a command-source and an ack-sink. The audio-sink units will also be command-sink and ack-source. To conclude, each unit in the system will communicate over 3 streams - audio, command, ack.

ovrebekk said:

By establishing an ACL connection you will get bi-directional communication which allows the gateway to ensure that all the commands are received, and you can also get status information back from the headsets, such as the battery state. 

What is the limit on the number of connections in that configuration? Will I be able to connect my central unit to 7 peripheral units at the same time, in parallel to the audio streaming? If yes, I would appreciate guidance about that too, since, as I mentioned in my original post, I'm having a hard time with this one and the dedicated ticket that I've opened doesn't bring much progress.

[ovrebekk]

Hi

Dekel said:

From what I see in the example code, the whole "bt_stream" folder relates only to an audio stream. How do I transfer that into a command stream?

True, the idea of sending commands over BIS is not something that is implemented currently. As mentioned the idea is to use ACL connections for anything not included in the audio stream itself. 

You mentioned you already tried to inject command data in the audio stream? Couldn't you extend this functionality to use separate streams for audio and command data instead? 

Where it makes most sense to handle this is hard to say. You could update the encoder_thread(..) function in audio_system.c to handle both an audio buffer and a command buffer, and run separate processing for the two before calling the streamctrl_send(..) function. 

At this point a lot if the function and file names might warrant changing, since they no longer deal with audio only, but that's another story

Dekel said:

The audio-sink units will also be command-sink and ack-source. To conclude, each unit in the system will communicate over 3 streams - audio, command, ack.

You mean that each of the 7 peripherals would set up their own ACK stream? 

Dekel said:

What is the limit on the number of connections in that configuration? Will I be able to connect my central unit to 7 peripheral units at the same time, in parallel to the audio streaming?

Again this is a use case that is not really explored from our side. 

Out of the box the LE audio solution will use a dedicated Bluetooth controller (just referred to as the LE Audio controller) which is limited to running 2 ACL connections concurrently. 

Quite recently the SoftDevice controller (which is the default Bluetooth controller used by all non audio related Bluetooth samples) was updated with experimental support for BIS and CIS, in order to provide LE Audio support also when using the SoftDevice controller. 

This controller supports up to 20 links concurrently, but if you want to run two BIS streams at the same time then the main limitation is the amount of radio time needed to service the BIS streams, the ACL links, and any scanning you need to do in order to establish new ACL connections. 

This ties back to my earlier question about latency, which affects the kind of connection intervals you would want to run for each of the ACL links. 

Best regards
Torbjørn