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

[Karl Ylvisaker]

Hello again, hillman007

Hillman007 said:

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.

You will need to set this as part of the prj.conf, or in the nrf5340_audio reference application you will need to change the existing connection and channel limits set in the headset/gateway overlays.
Overlays are specific additions to the prj.conf that takes priority over the prj.conf defines, in the case that there is a conflict.

Hillman007 said:

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?)

The documentation for the Packetcraft controller is very sparse at the moment, I am afraid, but we are working on publishing extensive documentation for it as we speak. I can however not speculate on when this documentation will be made available. If you have questions about future releases or roadmaps you will have to reach out to your Regional Sales Manager (RSM) with these, since we do not discuss roadmaps / future releases here on DevZone.

The documentation is not the same as for the Zephyr Controller, though. You can find information about the Zephyr controller here.

Hillman007 said:

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?

Thank you for updating me on the changes in the applications requirements.
Will you still be doing playback of the audio, or does it just need to be recorded and saved for later playback?
The viability of using regular BLE connection for this will depend on the audio quality that you intend to transfer / the throughput that you need for the transfer. You can read more about the possible throughput for regular BLE connections here.
In general, it is however the nRF5340 that we recommend for wireless audio applications, as the LC3 codec significantly will reduce the necessary size of transfer, which in turn reduced power consumption by requiring less CPU and RADIO time.

Hillman007 said:

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. 

There is currently no power optimization made to the nRF5340_audio reference application.
Could you detail your setup for the 12 mA power consumption measurement?

Best regards,
Karl