BLE Audio - many to one, power consumptions of DK?

[Hillman007]

Excited to have ordered my BLE Audio DK which uses NRF5340.

In my use case I am looking for many microphones (audio transmitters) to a single listening device (audio receiver). Ideally, they'd be synchronised reasonably well but again that is something we can deal with in the back-end system. In terms of link robustness, will this work? e.g. 5 senders to one listener? 16bit, 16kHz ideal, but could be reduced if needed. 5 was a random number, even two would be useful. Can one use variable rates on each stream? And then I wasnt sure whether you'd recommend connected or broadcast - I understand connected minimises packet loss due to feedback. 

Finally, any idea of the DK / estimated power consumption for nRF5340 to send a single audio stream?

Thanks in advance,

[mtsunstrum]

Curious to see how this effort progresses.

@Hillman007 have you found you may need to make changed to the net core ( child image ) ?

I am interested in knowing what limitations there may be in the binary child image. 

Does it have limitations that may prevent developers from working with non-standard LE Audio use cases ?

Hopefully NordicSemi can shed light on this.

[Karl Ylvisaker]

Hello mtsunstrum,

Thank you for your patience with this.

mtsunstrum said:

Does it have limitations that may prevent developers from working with non-standard LE Audio use cases ?

Could you elaborate on what kind of non-standard LE Audio use cases you are referring to here?
The precompiled Packetcraft controller should not limit your LE Audio application, no. The Packetcraft controller implements the isochronous channels necessary for LE Audio.

Best regards,
Karl

[mtsunstrum]

Hi Karl, welcome back, and thank you for the responses.

For example, I would regard @Hillman007 use-case as a non-standard LE Audio use case.

I understand ( or I think I understand) that the PacketCraft controller handles BLE 5.3 operations on the network core, and I understand the upper layers of LE Audio are handled by NCS, running on the application core.

So for the binary PacketCraft controller, are there limitation such as:

• a limit on the # of concurrent isochronous channels ?
• any restrictions on number of concurrent "normal" LE Central / Peripheral connections
• any restrictions on ability to support simultaneous LE Audio gateway and headset operation ?
• is the PacketCraft work compliant with MPLS in any way, still allowing concurrent operation of ShockBurst/Gazell if we so choose.
• for nRF5340 project, if we wanted to change DLE ( data length ), we had to change prj.conf setting for the network core, and rebuilt the network core. Are DLE changes affected/limited by the binary PacketCraft controller ?
• compared to Nordic's own SoftDevice Controller are they any other capabilities missing from the PacketCraft controller ?

Thanks, Martin

[Hillman007]

Karl Ylvisaker said:

The precompiled one is Packetcraft controller I mention in my previous comment.
Is there a particular reason for why you would not like to use the Packetcraft controller?

Hi Karl - so I got looking at the softcontroller because I was researching how to inform the network controller that I would like more than one connection - i.e. to continue advertising. In my first attempt of just updating the example to call "start adv" again this errored - complaining about resoures. Where is the documentation about PackCraft controller that would allow me to learn what flags are supported? (is this the same as Zephyr? If so, where is the Zephyr documentation?)

From a learning perspectve, so I know there is a choice between Nordics Soft Controller and Zephyr, this is host controller on the application processor , right? On the network controller side - in general (no iso BLE) we use an image precompiled by Nordic? In the case of Audio you are suggesting the provided PacketCraft? 

Inciddently, it seems my requirement for live streaming has ended. These streams can no be unsyn and have some latency (non live playback). So for this, I think I could revert to a more normal BLE situation, right? So that would be perhaps Nordic Soft Controller and what network controller? I think I will still look at the LC3 codec as this could require the power consumption. Btw I did measure the eval kit and it was 12mA on transmit with no modifications. 

[Karl Ylvisaker]

Hello again,

Thank you for your patience with this, yet again.

mtsunstrum said:

I understand ( or I think I understand) that the PacketCraft controller handles BLE 5.3 operations on the network core, and I understand the upper layers of LE Audio are handled by NCS, running on the application core.

You are correct that the Packetcraft controller handles the BLE 5.2 LE Audio operations on the network core, and that the application core queues and receives transfers from the network core through the RPMSG API.

mtsunstrum said:

a limit on the # of concurrent isochronous channels ?

This is primarily limited by the encoding/decoding of the audio streams in the LC3 codec. As a 'rule of thumb' the encoding of a 96 kbps stream requires roughly 30% of the CPU, while decoding of a stream at 96 kbps requires roughly 15% CPU. So, the number of possible concurrent audio streams will depend on whether they are transmitted (encoded) or received (decoded) and their quality.

mtsunstrum said:

any restrictions on number of concurrent "normal" LE Central / Peripheral connections

This also depends on how many concurrent audio streams you will be running, since they will use the radio for a larger portion of the time (leaving less time to interweave other BLE communication). The PacketCraft controller currently only have support for a selection of the different LE Audio specific profiles and services - more profiles and services are also being actively implemented as they become adopted by Bluetooth SIG.

mtsunstrum said:

any restrictions on ability to support simultaneous LE Audio gateway and headset operation ?

Do you mean like in the case of a headset with a microphone (bi-directional CIS)?
If so, we have had this up and running with the reference application before, but I think it required some modification to work with the newer PacketCraft controllers, and we have not worked to include that in the reference application again at this moment.
There are however no technical limitation for implementing bi-directional CIS with the reference application yourself.

mtsunstrum said:

is the PacketCraft work compliant with MPLS in any way, still allowing concurrent operation of ShockBurst/Gazell if we so choose.

I dont think it is currently, unfortunately.
If you wish to know more about roadmaps or future releases or features I would have to ask that you reach out to your Regional Sales Manager (RSM) with these questions, since we do not discuss future releases or roadmaps here on DevZone.
If you do not know who your Regional Sales Manager is please send me a direct message with your location. here on DevZone, so that I may provide you with their contact information.

mtsunstrum said:

for nRF5340 project, if we wanted to change DLE ( data length ), we had to change prj.conf setting for the network core, and rebuilt the network core. Are DLE changes affected/limited by the binary PacketCraft controller ?

You may use the RPMSG API that is exposed in the reference application for configurations of the packetcraft controller running on the network core.

mtsunstrum said:

compared to Nordic's own SoftDevice Controller are they any other capabilities missing from the PacketCraft controller ?

Yes, the PacketCraft controller is not a subset of the SoftDevice controller, it is a separate entity made with the LE Audio specification as its target.

Best regards,
Karl