Extended Scanning not working on nRF5340 SoftDevice Controller after first connection

[Matthias Ringwald]

We're using nRF53 flashed with SoftDevice and HCI UART example as Controller to implement LE Audio in our Bluetooth stack running on a Mac. Unrelated to BIS/CIS, we run into the issue that we don't receive any advertisings after the first connection was made - required to find the other unicast devices in a connected set, e.g. Earbuds.

On Zephyr Discourd I was recommended to post the issue here.

I've attached the HCI trace from nRF53 DK. I'm using the v2.6 release tag of ncs.

To reproduce, either create a simple Zephyr app that finds a device, connects, then starts scanning again, or use our test code.

Instructions:

# Flash SDC on nRF534 DK
- Store [hci_ipc.conf from nRF5340 Audio example])(raw.githubusercontent.com/.../hci_ipc_release.conf) in `ncs/zephyr/samples/hci_uart/child_image`
- Store usb.overlay and usb-overlay.conf [frome our repo](github.com/.../nrf5340_dongle) in `ncs/zephyr/samples/hci_uart` to route UART over USB CDC (not needed, but more convenient)
- `west build --pristine -b nrf5340dk_nrf5340_cpuapp -- -DDTC_OVERLAY_FILE=usb.overlay -DOVERLAY_CONFIG=overlay-usb.conf`
- `west flash`

# Compile examples
- Checkout out BTstack
- Change to branch `test-scan-after-conenct`
- Follow Readme.md in `port/posix-h4` to compile the examples

# Run
- You can specify the path to the /dev/tty with param -u on the command line
- Run `gatt_counter` example on one device - could be anything, just announce UUID FF10 in advertisement
- Run `scan_after_connect` on the other. It will scan and connect to the first device, after that, it starts scanning again, but there are no advertisements
- HCI trace on Mac/Linux is available in /tmp/hci_dump.pklg
hci_dump_le_audio_unicast_gateway.pklg

[dejans]

Hi,

Could you provide more information about your setup? 

Which board should each of the mentioned samples (hci_uart, gatt_counter, scan_after_connect) be flashed to?

# Flash SDC on nRF534 DK

How did you do this?

# Run
- You can specify the path to the /dev/tty with param -u on the command line
- Run `gatt_counter` example on one device - could be anything, just announce UUID FF10 in advertisement
- Run `scan_after_connect` on the other. It will scan and connect to the first device, after that, it starts scanning again, but there are no advertisements

Where are samples gatt_counter and scan_after_connect located? Could you provide relevant links?

Best regards,
Dejan

[Matthias Ringwald]

The issue seems to be with the HCI_UART (app) + SoftDevice (net) on the nRF5340 DK.

It is used with the scan_after_connect application on the desktop = macOS or Linux.

--

You can use another nRF5340 with the same HCI_UART + SoftDevice on a second nRF5340 DK. I've used this with the gatt_counter example on desktop = macOS or Linux.

--

You can compile the examples in the port/posix-h4 folder with CMake or make and then run them on the command line.

Here's the readme: https://github.com/bluekitchen/btstack/tree/test-scan-after-connect/port/posix-h4

The code for the (trivial) examples is here:

- https://github.com/bluekitchen/btstack/blob/test-scan-after-connect/example/scan_after_connect.c

- https://github.com/bluekitchen/btstack/blob/test-scan-after-connect/example/gatt_counter.c

--

If you check the provided HCI trace for Wireshark, it seems to be rather simple: scanning doesn't work after the first connection was established and should reproduce in a similar setup as well. If not, I'd be curious what I could change to get it to scan again.

If you have a ready-to-run application that you can run on the nRF5340 app core, you can use that as well and first connect and then start scanning again.

Thanks

  Matthias

[dejans]

Hi Matthias,

I would need more information/clarifications about your setup and application functionality.

Regarding your setup, you have your desktop (mac or linux) which runs scan_after_connect application connected to nrf5340-dk board which runs hci_uart. Then, you have another (or the same?) desktop which runs gatt_counter application and is connected to another nrf5340-dk which runs the same hci_uart application as the first board. Is this description of your setup correct?

Could you provide information on how is your setup expected to work? What does each of the applications do and what is your goal with this setup?

Best regards,
Dejan

[Matthias Ringwald]

Hi Dejan

Your description of this test setup is correct. Two applications run parallel on the same desktop and each is connected to a nrf55340 board.

The setup is only intended to show the unexpected behaviour with minimal setup to simplify analysis/debugging. The gatt counter is a simple peripheral application with a gatt service. The scan after connect, first scan for a device, connects to it, then starts scanning again.

The issue was first observed with our LE Audio Unicast Gateway implementation. This application is also running on Mac with the nRF5340 DK and the SoftDevice. It first scans for LE Audio headsets and connects to the first one it finds. It then access the remote CSIP Service to learn about the Coordinated Set Size. If the Set Size is larger than one, e.g. for Ear-Buds, it will enable scanning again and look for a device with the correct RSI. This failed with the SoftDevice as it is not receiving any advertisements. After that ASCS will be used and eventually two or more CIS streams are used to stream audio. I wanted to create a demo that connects to 3 devices, e.g. for a home theater setup.

Thanks,

Matthias

[dejans]

Hi Matthias,

Thank you for additional information.

We will look further into your reported issue during next week. I hope to get back to you by the end of next week.

Best regards,
Dejan

[dejans]

Hi Matthias,

The problem you reported might be related to the known issue #20444 described in the documentation with existing workaround. Can you check if provided workaround resolves your issue?

Best regards,
Dejan

[Matthias Ringwald]

Hi Dejan. Thanks for the hint. Yes, it's exactly issue #20444 and the suggested workaround works here as well. Ok, let's see if I can get 3 unicast streams to work then.