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,

[Hillman007]

Karl Ylvisaker said:

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

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. 

Karl Ylvisaker said:

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.

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

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.

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.

[Hillman007]

Hillman007 said:

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)

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?

[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 again,

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

Hillman007 said:

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. 

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.

Hillman007 said:

I am new do Zephyr and in general to BLE/Nordic.

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

Hillman007 said:

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.

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.

Hillman007 said:

This gives me an error of:

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

Hillman007 said:

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.

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

[Karl Ylvisaker]

Hillman007 said:

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?

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