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

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

mtsunstrum — Sat, 09 Jul 2022 16:15:42 GMT

When doing BV16 encoding ( for your microphone transmission ) on a nRF52832, CPU % utilization was about 35%

For BV16 decoding ( for reception ) on a nRF52832, CPU % utilization was about 7.5%

So roughly, your nRF52832 receiver unit could conceivably handle receiving from about 10 transmitters simultaneously. ( leave some CPU utilization for other activities )

Current draw roughly would be in 10mA range overall, or about 1mA for each audio link.

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

mtsunstrum — Sat, 09 Jul 2022 05:03:51 GMT

Yes, if it is just voice, not music you need to transfer, you can skip the memory and processing intensive LC3 codec.

You can use other open-source codecs out there like Broadcom BV16/BV32 ( 8 or 16kHz bandwidth ).

They will encode/decode comfortably within the processing/RAM available in a nRF52832.

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

Karl Ylvisaker — Fri, 08 Jul 2022 09:58:43 GMT

Hello Hillman,

Sorry for the increase in response-time here. The summer holiday has begun here in Norway, and so DevZone is operating at reduced capacity for the duration.

[quote user="Hillman007"]So we just need to send the audio the server for playback another day. So standard BLE is not an issue from latency.HOWEVER as you say, the CODEC is still very much of interest and clearly reduces the power consumption of the overall system despite the added computation over-head. So I am still very much looking at the dual core SoC.[/quote]

Sure, that could work as long as you have the time and memory to see the audio transfer happen over a regular BLE link, then it should be no problem.
Please also keep in mind that our LC3 implementation is made specifically for use with, and optimized for, the nRF5340.

[quote user="Hillman007"]This was simply the default application - audio from laptop to speaker. I used the head on the evaluation kit to meaure it. Indeed no optimisation. So I am hopeful for lower but that is sufficient starting point to be worthy of investment. [/quote]

Great, I am happy to hear that! :) You will definitely see a lower average consumption once it is power optimized.

[quote user="Hillman007"]So my next step is to go back to "the non audio dk" and build up a custom application - including adding the LC3 codec. Karl Ylvisaker does that seem the right approach to you? That way I dont need to worry about lack of packet craft documentaiton either. [/quote]

Yes - with the change in the application requirements to do non-live audio transfer it sounds to me like you will not be needing the on-board audio specific peripherals of the nRF5340 Audio DK, so long as you are able to get the data for transfer over to the nRF5340 some other way (such as through any of the serial protocols directly).
The application is thus reduced to a regular 'transfer data' use-case, for which the nRF53 DK should be used.

Best regards,
Karl

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

Hillman007 — Fri, 01 Jul 2022 19:38:52 GMT

[quote userid="87869" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/374555"]

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.

[/quote]

Yes - you are right. So we just need to send the audio the server for playback another day. So standard BLE is not an issue from latency.HOWEVER as you say, the CODEC is still very much of interest and clearly reduces the power consumption of the overall system despite the added computation over-head. So I am still very much looking at the dual core SoC.

[quote userid="87869" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/374555"]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?[/quote]

This was simply the default application - audio from laptop to speaker. I used the head on the evaluation kit to meaure it. Indeed no optimisation. So I am hopeful for lower but that is sufficient starting point to be worthy of investment.

So my next step is to go back to "the non audio dk" and build up a custom application - including adding the LC3 codec. Karl Ylvisaker does that seem the right approach to you? That way I dont need to worry about lack of packet craft documentaiton either.

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

Karl Ylvisaker — Tue, 28 Jun 2022 13:18:06 GMT

Hello again, hillman007

[quote user="Hillman007"]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. [/quote]

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.

[quote user="Hillman007"]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?)[/quote]

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.

[quote user="Hillman007"]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?[/quote]

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.

[quote user="Hillman007"]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. [/quote]

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

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

Karl Ylvisaker — Fri, 24 Jun 2022 13:28:49 GMT

Hello again,

Thank you for your patience with this, yet again.

[quote user="mtsunstrum"]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.[/quote]

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.

[quote user="mtsunstrum"]a limit on the # of concurrent isochronous channels ?[/quote]

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.

[quote user="mtsunstrum"]any restrictions on number of concurrent "normal" LE Central / Peripheral connections[/quote]

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.

[quote user="mtsunstrum"]any restrictions on ability to support simultaneous LE Audio gateway and headset operation ?[/quote]

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.

[quote user="mtsunstrum"]is the PacketCraft work compliant with MPLS in any way, still allowing concurrent operation of ShockBurst/Gazell if we so choose.[/quote]

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.

[quote user="mtsunstrum"]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 ?[/quote]

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

[quote user="mtsunstrum"]compared to Nordic's own SoftDevice Controller are they any other capabilities missing from the PacketCraft controller ?[/quote]

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

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

Hillman007 — Mon, 20 Jun 2022 19:40:46 GMT

[quote userid="87869" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/372674"]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?
[/quote]

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.

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

mtsunstrum — Wed, 15 Jun 2022 22:16:40 GMT

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

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

Karl Ylvisaker — Wed, 15 Jun 2022 21:24:14 GMT

Hello mtsunstrum,

Thank you for your patience with this.

[quote user="mtsunstrum"]Does it have limitations that may prevent developers from working with non-standard LE Audio use cases ?[/quote]

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

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

Karl Ylvisaker — Wed, 15 Jun 2022 21:20:36 GMT

[quote user="Hillman007"]So I think my issue is that I need to use chlild image to compile the net core. But by default the audio application uses a precompiled one. Is this something I can change?[/quote]

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?

Best regards,
Karl

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

Karl Ylvisaker — Wed, 15 Jun 2022 21:19:38 GMT

Hello again,

Thank you for your extreme patience with this - I have been out of office for some time now, but I am now back.

[quote user="Hillman007"]Yes just to show I can receive two streams at the perpherial/headset end. I hope that will be enough for me to measure the power consumption for receiving one or more streams. [/quote]

That should be enough to measure the power consumption of receiving and processing two streams, yes. The main power consumption will come from the added radio traffic and processor usage, while the power used to output the stream to a speaker should be minimal.

[quote user="Hillman007"]I am new do Zephyr and in general to BLE/Nordic.[/quote]

Thank you for saying so, this is good for us to know.

[quote user="Hillman007"]

1. I have added to prj.conf:

CONFIG_BT_LL_SOFTDEVICE=y
CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT=2

So this will run the Nordic softdevice which supports some additional features vs Zephyr Host? And then setting the number of concurrent connections? (which will only apply to the peripheral / headset ? I am hoping - based on another forum post I read, that this is sufficient to make the advertising resume.

[/quote]

The SoftDevice Controller does not support Isochronous streams, and so you should not add these configurations to your prj.conf.
Instead, you should use the rpmsg controller from Packetcraft that is included in the nrf5340_audio application's /bin folder as your network core / controller image.
The Packetcraft controller is the controller we have made available for LE Audio development for the nRF5340, and it is the controller that the nrf5340_audio reference application uses.

[quote user="Hillman007"]This gives me an error of:[/quote]

The errors are likely due to dependencies and supported functions not being present with the SoftDevice controller included instead of the Packetcraft controller.

[quote user="Hillman007"]

2. in overlay headset:

CONFIG_BT_MAX_CONN=2
CONFIG_BT_ISO_MAX_CHAN=2
CONFIG_BT_MAX_PAIRED=2

So I am now thinking I'll need to change the callback behaviour to differentiate the connections - I imagine it was written assume just one connection.

[/quote]

Yes, you will need to duplicate the enabling and handling/processing of the additional stream, since the headset applications indeed are written for receiving a single stream (such as in the earbud / hearing aid use-case).

Best regards,
Karl

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

mtsunstrum — Sun, 12 Jun 2022 00:28:09 GMT

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.

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

Hillman007 — Wed, 01 Jun 2022 09:59:25 GMT

[quote userid="101804" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/370299#370299"]warning: ENTROPY_NRF5_RNG (defined at drivers/entropy/Kconfig.nrf5:14) has direct dependencies !ENTROPY_NRF_FORCE_ALT && HAS_HW_NRF_RNG && ENTROPY_GENERATOR with value n, but is currently being y-selected by the following symbols:
- BT_LLL_VENDOR_NORDIC (defined at subsys/bluetooth\controller\Kconfig.ll_sw_split:11), with value y, direct dependencies SOC_COMPATIBLE_NRF && BT_LL_SW_SPLIT && BT_CTLR && BT_HCI && BT (value: y), and select condition SOC_COMPATIBLE_NRF && BT_LL_SW_SPLIT && BT_CTLR && BT_HCI && BT (value: y)[/quote]

So I think my issue is that I need to use chlild image to compile the net core. But by default the audio application uses a precompiled one. Is this something I can change?

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

Hillman007 — Tue, 31 May 2022 20:44:27 GMT

[quote userid="87869" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/369856#369856"]Do I understand it correctly that you would still like the device to stay in a connection and receive a stream that it is not necessarily outputting to a speaker/headphone, simultaneously as it is playing the audio from the other source[/quote]

Yes just to show I can receive two streams at the perpherial/headset end. I hope that will be enough for me to measure the power consumption for receiving one or more streams.

[quote userid="87869" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/369856#369856"]There is however no issue for the gateway to encode and transfer multiple streams at the same time.
To demonstrate stereo sound you would therefore have to use 2 Audio DKs as headphones, where each of them outputs one of the stereo channels.[/quote]

Yes - I understand that. For now, I dont need to hear it. Just to allow measurements is sufficient. Hopefully you feel this approach is sufficient.

I am new do Zephyr and in general to BLE/Nordic. So a few things:

1. I have added to prj.conf:

CONFIG_BT_LL_SOFTDEVICE=y
CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT=2

This gives me an error of:

warning: ENTROPY_NRF5_RNG (defined at drivers/entropy/Kconfig.nrf5:14) has direct dependencies !ENTROPY_NRF_FORCE_ALT && HAS_HW_NRF_RNG && ENTROPY_GENERATOR with value n, but is currently being y-selected by the following symbols:
- BT_LLL_VENDOR_NORDIC (defined at subsys/bluetooth\controller\Kconfig.ll_sw_split:11), with value y, direct dependencies SOC_COMPATIBLE_NRF && BT_LL_SW_SPLIT && BT_CTLR && BT_HCI && BT (value: y), and select condition SOC_COMPATIBLE_NRF && BT_LL_SW_SPLIT && BT_CTLR && BT_HCI && BT (value: y)

2. in overlay headset:

CONFIG_BT_MAX_CONN=2
CONFIG_BT_ISO_MAX_CHAN=2
CONFIG_BT_MAX_PAIRED=2

So I am now thinking I'll need to change the callback behaviour to differentiate the connections - I imagine it was written assume just one connection.

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

Karl Ylvisaker — Sun, 29 May 2022 13:33:26 GMT

Hello,

[quote user="Hillman007"]approach: modify the audio applicationn sample - good?[/quote]

Yes, if you are using the buildprog tool you will need to modify the application sample directly.
If you would like to use the traditional NCS approach you can do so as well, through using the 'generate application from sample' option in VS code. You will then have to program and flash each kit with each configuration / variation that you make, but there will be a clearer distinction between the application, and easier versioning for complex projects.

[quote user="Hillman007"]So this would mean building two gateways and one headset. The gateways currently have the same name. Do you think that is a problem?[/quote]

Are you working with the CIS or the BIS mode? In case of the CIS mode then the gateways are traditional central devices, and so their name will not be advertised - it is also the centrals who initiate connections, etc.
You should then see your headset device advertise as a traditional peripheral device, displaying its device name.
So as long as the headset keeps advertising as connectable after the first connection it should not be any problem.

[quote user="Hillman007"]To get the headset to allow two connections, I will modify the advertising behaviour to re-advertise to allow the second gateway/controller connect. And increase the maximum number of connecitons. I play to then use a button to make the audio output stream to the headphones to select between the two sent audio streams.[/quote]

This is what I too would recommend you to do. Do I understand it correctly that you would still like the device to stay in a connection and receive a stream that it is not necessarily outputting to a speaker/headphone, simultaneously as it is playing the audio from the other source?

[quote user="Hillman007"]Maybe as an extention I might add a stereo codec and have left for controller A and right for controller B streams. what do you think? [/quote]

The Audio DK can encode and stream stereo (multiple streams concurrently) audio, but the issue you would face here would be the stereo playback capabilities of the Audio DK - the audio DK is made to demonstrate / develop for the 'earbud scenario' - i.e the HEADPHONES audio jack output can only output mono channel audio. That is to say, if you plug in a stereo headset into the HEADPHONES jack you will only have audio on the left ear.
There is however no issue for the gateway to encode and transfer multiple streams at the same time.
To demonstrate stereo sound you would therefore have to use 2 Audio DKs as headphones, where each of them outputs one of the stereo channels.

Please do not hesitate to ask if any part of this should be unclear, so that I may elaborate! :)

Best regards,
Karl

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

Hillman007 — Thu, 26 May 2022 19:01:55 GMT

Karl Ylvisaker progress so far so good. I have got the buildprog chain working and tested. and had a good look over the code - in terms of its architecture. Disabled LC3 for now, whilst I get repo access.

So I wanted to run my approach past you:

aim "I would like to audio senders to one audio receiver".

approach: modify the audio applicationn sample - good?

So this would mean building two gateways and one headset. The gateways currently have the same name. Do you think that is a problem? I couldnt figure out how to generate two individual names. It seemed CONFIG_BT_DEVICE_NAME is somewhat hard coded, and I couldnt find where the build script is pulling that value into the auto_config.h file. For example, I thought I could perhaps use the unused channel paramter in dk_devices.json. I also thought about using CONFIG_BT_DEVICE_NAME_DYNAMIC=y in the overlay. But I was unable to find a "ble set name" function...

To get the headset to allow two connections, I will modify the advertising behaviour to re-advertise to allow the second gateway/controller connect. And increase the maximum number of connecitons. I play to then use a button to make the audio output stream to the headphones to select between the two sent audio streams. Maybe as an extention I might add a stereo codec and have left for controller A and right for controller B streams. what do you think?

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

Karl Ylvisaker — Fri, 20 May 2022 09:58:04 GMT

Hello,

[quote user="mtsunstrum"]

Yes, I stand corrected, the underlying LE Audio framework is quite flexible, and can support that use case.

I was basing off of demonstrated application modes:

[/quote]

Thank you for elaborating - I see how the note in the documentation could be interpreted this way.

[quote user="mtsunstrum"]But I now understand that is not the only configurations that LE Audio supports, but rather limits of nRF Audio DK demo applications.[/quote]

Yes, that is to say: the nrf5340_audio application is still being developed - with new features and improvements still in the making.
However, there are no technical limitations on neither the nRF5340 SoC nor the LE Audio specification that prevents anyone from implementing a multiple-sink scenario themselves independently, based on the nRF5340_audio application.

[quote user="mtsunstrum"]As you have indicated CPU resources may be the limiting factor, if attempting to decode 5+ microphone transmitters simultaneously. This might be overcome, depending on mic audio bandwidth needs, and possible usage of other lower complexity codecs.[/quote]

Yes - the flexibility of the LE Audio specification and the performance of the LC3 codec opens many possibilities for this. However, the biggest bottleneck for 5+ microphones would likely be the CPU load, but these issues could very well be alleviated by the configurations you note in your comment, or for example by relaxing the latency constraint - so long as they are feasible for the application, of course.

Best regards,
Karl

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

mtsunstrum — Wed, 18 May 2022 17:46:09 GMT

Yes, I stand corrected, the underlying LE Audio framework is quite flexible, and can support that use case.

I was basing off of demonstrated application modes:

See https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/nrf5340_audio/README.html#application-modes

But I now understand that is not the only configurations that LE Audio supports, but rather limits of nRF Audio DK demo applications.

As you have indicated CPU resources may be the limiting factor, if attempting to decode 5+ microphone transmitters simultaneously. This might be overcome, depending on mic audio bandwidth needs, and possible usage of other lower complexity codecs.

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

Karl Ylvisaker — Wed, 18 May 2022 15:12:17 GMT

[quote user="Hillman007"]Karl thank you for responding.[/quote]

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

[quote user="Hillman007"]My boards have arrived so I am going to start to implement two to one and see how we do.[/quote]

Great! Please do not hesitate to let us know if you should encounter any other issues or questions when working with this.
I highly recommend familiarizing with the audio application specific 'buildprog' tool, by the way, since it makes building and flashing multiple boards with different versions of the same application (debug/release, gateway/headset) automated and efficient.
You can read about the buildprog tool in the documentation, or use the python buildprog.py --help command to see its options.

[quote user="Hillman007"]I will then look into power optimisitions - is there any specific areas you'd recommend looking at?[/quote]

In general, the best way to save power is to maximize the time spent in SYSTEM_ON sleep. How to best achieve this will wary for each application / use-case, but if you can reduce radio time (reduce retransmissions, increase connection parameters, etc.) you can spend more time in sleep, which should yield more time spent in SYSTEM_ON sleep.
My recommendation would here be that you try out the unmodified nrf5340_audio application from the v1.9.99-dev1 tag, and then use those measurements as a reference for when you try to tweak the different parameters and configurations, to see their impact.

Best regards,
Karl

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

Hillman007 — Wed, 18 May 2022 14:13:20 GMT

I enjoyed reading your thinking on this. Thank you for sharing. I will, of course, reply with how it goes.

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

Hillman007 — Wed, 18 May 2022 14:12:48 GMT

Karl thank you for responding. My boards have arrived so I am going to start to implement two to one and see how we do. I will then look into power optimisitions - is there any specific areas you'd recommend looking at?

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

Karl Ylvisaker — Wed, 18 May 2022 09:01:20 GMT

I would also like to add a comment regarding the possibility to use 'traditional BLE' for real-time audio transfer:

While you in many cases would be able to achieve a microphone-speaker design with a pre-LE Audio BLE connection it is far from ideal, since the BLE connection is loss-less, meaning that either every packet will be transmitted, or the connection will be terminated.
This is a great feature for data-transfer in general, but for Audio in particular it gets a little rocky when you start missing packets and the time of playback for those packets is approaching.
In the pre-LE Audio BLE case, the lost packets will still be transferred, but they will no longer be useful to the receiver.
However, with Isochronous channels the BLE Controller will be able to discard packets that will not make it to the receiver in time for their playback, which enables it to proceed with the next audio instead of building up a backlog of no-longer-relevant packets that still needs to be transferred.
This is just one of the many reasons why LE Audio is a much better fit for audio transmission applications over pre-LE Audio BLE Connections.

Best regards,
Karl

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

Karl Ylvisaker — Wed, 18 May 2022 08:24:57 GMT

Hello Hillman and mtsunstrum,

[quote user="mtsunstrum"]My main point though was that LE Audio with many transmitters to one receiver is not technically possible.[/quote]

This is not correct at all. Could you elaborate on what gives you this impression?
LE Audio definitively allows for multiple transmitters to the same receiver - it is not as prominent a feature as Audio Sharing, but it is definitively possible. The main limitation here would be on the receiver's side in how many concurrent streams it would be able to decode, like I explained in my initial comment.

[quote user="mtsunstrum"]I suspect the current consumption would be roughly comparable.[/quote]

As for expected power consumption I have not been able to find any numbers on this internally, unfortunately.
The nrf5340_audio application does not have any power optimization as far as I know, and so I expect its current draw to be quite high as is, so long as power saving measures are not added.

Best regards,
Karl

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

Hillman007 — Mon, 16 May 2022 19:18:04 GMT

ok thanks - that isnt what I took away from Karl, but thank you for being clear.

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

mtsunstrum — Mon, 16 May 2022 18:40:30 GMT

I suspect the current consumption would be roughly comparable.

My main point though was that LE Audio with many transmitters to one receiver is not technically possible.