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

[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

[Brian Kim]

Hello Dekel,

Thanks for the good news! 

Dekel said:

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

Yes, it corresponds with REMOTE_DEVICE_NAME_PEER.

Dekel said:

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?

The screen shot I shared below was about sending data from the gateway(ACL central) to the peripherals. If you want to send the other way, it's already implemented. Once data is transmitted from any peripheral, you will see it in ble_data_received.

I simply tried and confirmed it works as intended like this. :)

[P.S] you don't need to use the option,-ctlr="SDC" any more because it's default option since NCS 2.6.0.

//Brian

[Dekel]

Hi Brian,

Brian Kim said:

If you want to send the other way, it's already implemented

I can see that on my devices, similar to the screenshot you've shared.

Brian Kim said:

[P.S] you don't need to use the option,-ctlr="SDC" any more because it's default option since NCS 2.6.0.

Good to know

Brian Kim said:

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?

I would truely appreciate your help with these topics, they're crucial to our project's progress.

Thank you,

Dekel

[Brian Kim]

Thanks for the good news, Dekel!

Now that it seems to be fixed, please close this case. You can create new case any time if you faced another issue. :)

[Dekel]

Hi Brian,

It's actually not completely fixed.

We've figured out that it will be easier if the broadcaster side, which is in peripheral role in terms of audio, will also be the peripheral in terms of ACL connection. Meaning, we'd like it to advertise both audio stream and ACL connection for commands.

I was able to take the code you've supplied and apply it on the headset side. Namely, I have now a headset which is also able to connect through ACL as central (in parallel to audio stream receival) and communicate through NUS.

I would appreciate your help with the broadcast side implementation.

I tried it myself and I'm on the brink of success, but calling bt_le_ext_adv_create() twice (once for audio and once for ACL) fails with EIO (I/O error). It's unclear to me why it happens.

mk102 said:

I came across the following repository through a DevZone post (I am unable to find the original post through a simple google search)

Thank you for that! I took a look on it, but since it relates to CIS while my project is BIS, it's difficult for me to understand the necessary modifications.

[Brian Kim]

Hello Dekel,

Sorry for this delay. I just saw this reply. Now that the new request is totally different one, we should discuss on another thread. I believe this is already requested with another case:

 nRF5340 Audio - configure gateway unit also as ACL peripheral 

If that is about it, we can close this case and keep talking in the the case. Feel free to comment.

//Brian