Integrate NUS into BLE Audio code

[Dekel]

Hi,

I'm working with nRF5340 Audio DK.

I'm able to successfully run the audio example in BIS mode (with gateway and headset devices), and also to run the Peripheral UART Bluetooth example separately on my DK.

My goal is to open another BT connection, in parallel to the audio broadcast on my gateway device, to which I can connect with the nRF Toolbox App.

Is it possible? If so, which BT controller should be used? How should proj.conf should look like? What other configurations are required?

I've noticed that the UART example code uses adv.c for advertising, while the audio example code uses bt_mgmt.c.

Thank you,

Dekel

[Dekel]

Karl Ylvisaker said:

Does this mean that you have got NUS up and running on your headset device alongside the ISO functionality, so that you are able to see and interact with the NUS service when connecting to the peripheral advertisement that is running alongside the ISO functionality?

No, the NUS is not integrated yet. Only the ability to have a connectable advertisement in parallel to BLE Audio.

Karl Ylvisaker said:

If so, could you share the logs from your peripheral device when it fails those 4-5 times before achieving a stable connection?

I assume I'll have to use SoftDevice in order to be able to debug with VSCode and have logs. Is that correct?

Karl Ylvisaker said:

If nothing stands out in the logs we will need to get a sniffer trace of the communication when you attempt to connect to the peripheral's advertisements - are you familiar with using the nRF Sniffer tool?

I'm not familiar with it, but I'll take a look, thanks.

[Karl Ylvisaker]

Hello,

Dekel said:

No, the NUS is not integrated yet. Only the ability to have a connectable advertisement in parallel to BLE Audio.

Thank you for clarifying. Being able to establish the additional ACL connection in parallel is a big step in the right direction - now all that remains is to include and enable the NUS service (and to debug the instability issue, of course).

Dekel said:

I assume I'll have to use SoftDevice in order to be able to debug with VSCode and have logs. Is that correct?

In general yes - and please remember that the ISO support in the SoftDevice Controller is still experimental - but in this case you can also just provide the log output over the UART from your debugger, if you are using the LE Audio controller.
I.e run the application as usual, and open a serial monitor (like PuTTy, or a nRF Terminal in VSC) to see the applications logs.

Dekel said:

I'm not familiar with it, but I'll take a look, thanks.

All right, great! The sniffer is a very powerful tool to wield when developing BLE applications. Please keep in mind that the nRF Sniffer only supports sniffing of ALC ('regular' BLE communication), and not the contents of ISO channels.
For the debugging we are doing now all we need is to look at what is being sent between the devices leading up to the instability you have observed.
It can be daunting to familiarize with the nRF Sniffer tool at first, so please do not hesitate to ask if you should encounter any issues or questions! :) 

Best regards,
Karl

[Dekel]

I'll share current code modifications with a hope for help:

modifications.rar

[Brian Kim]

Hello Dekel,

I am sharing very initial reference for your application working as a BIS broadcaster and NUS central simultaneously based on NCS1.6.0.

6-8 concurrent ACL link might be challenging, but you can tweak related parameters properly , like the connection interval(currently 20ms) or CONFIG_BT_MAX_CONN(currently 4).

Please note that this is just a rough reference not guarantee the stability, so you should verify and purify it.

The modified files :

nrf/applications/nrf5340_audio/broadcast_source/main.c
nrf/applications/nrf5340_audio/prj.conf
nrf/applications/nrf5340_audio/src/bluetooth/bt_management/bt_mgmt.c

And also please refer the screen shot of the operation. I tested with three devices in total, BIS broadcaster, BIS headset, nRF52DK(1st NUS server) and nRF52840 DK(2nd NUS server).

[updated 20.03] replaced with one zip file for easier access.( also changed one parameter(CONFIG_BT_AUDIO_RETRANSMITS=3 from 10)on prj.conf for faster ACL communication.

nrf5340_audio_gw_central.zip

[Dekel]

Hi Brian,

First of all, thank you so much for your efforts and for sharing all that information! this is very helpful to us.

Based on my tests, things look good! I'll describe my process:

I've installed NCS2.6.0 through the Toolchain Manager and replaced the 3 files you've attached in the zip file.

I've successfully built and flashed the program using this command (flashed gateway & headset units):

python buildprog.py -c both -b debug -d both -p --ctlr="SDC" --recover_on_fail

The gateway receives audio data through USB (I've removed CONFIG_AUDIO_SOURCE_I2S from proj.conf for that) and it's successfully heard on the headset side, to which I've connected a speaker.

I've also flashed a third unit, nRf52833DK, with the "peripheral UART" example code. On startup, while the broadcaster is already running and music is playing, an ACL connection was established automatically and I was able to write from the peripheral (nRf52833DK) to the central (gateway) using TeraTerm.

This is great! It may serve as infrastructure for sending sensor data from the headset units towards the gateway.

I'd like to ask a few questions please:

1. Regarding the automatic ACL connection that the gateway establishes - is it name-based? does it mean that it will try to connect to all units with the name "Nordic_UART_Service"?

2. How can I test the other direction of messaging? Namely, sending data from the gateway to the peripheral over ACL?

3. In order to integrate the ACL into the BLE Audio system, it's necessary for the headset units to be able to serve as preipherals. Is this implementation easier now that we have your implementation on gateway side?

4. Following my previous question, I'll share that in order to achieve the goal of our project, a full solution of this would be to be able to configure the gateway unit both as central and peripheral in terms of ACL connection (for connection with a smartphone app). Is it achieveable? What will it require?

Thank you,

Dekel