BLE L2CAP CoC Reception Delay - nRF54L15 (Android to nRF, 20ms sent / 100-200ms received)

[nikul]

Hello Nordic Support Team,

I'm developing a BLE audio/walkie-talkie application on an nRF54L15 DK using Zephyr, communicating with an Android smartphone. I'm seeing a significant and irregular delay when receiving data on the nRF side over an L2CAP Credit-Based Connection-Oriented Channel (CoC), and would appreciate your input.

ISSUE
The Android app sends audio packets at a steady ~20 ms interval. On the nRF54L15 side, however, packets arrive irregularly, with gaps of roughly 100-200 ms (occasionally more). Example RX log:

BLE RX #1: SEQ=1 packet=164 payload=160 interval=0 ms
BLE RX #2: SEQ=2 packet=164 payload=160 interval=101 ms
BLE RX #3: SEQ=3 packet=164 payload=160 interval=149 ms
BLE RX #4: SEQ=5 packet=164 payload=160 interval=117 ms
BLE RX #5: SEQ=6 packet=164 payload=160 interval=109 ms
BLE RX #6: SEQ=7 packet=164 payload=160 interval=110 ms
BLE RX #7: SEQ=8 packet=164 payload=160 interval=101 ms
BLE RX #8: SEQ=9 packet=164 payload=160 interval=125 ms
BLE RX #9: SEQ=10 packet=164 payload=160 interval=180 ms

As a sanity check, I also tested audio data sent from one Android phone to another Android phone (Android -> Android, i.e. not involving the nRF54L15 at all) over BLE, and in that case I am able to receive audio data every 20 ms without any delay. This suggests the Android side is capable of sending and receiving at a consistent 20 ms interval, which points to the issue being specific to reception on the nRF54L15 side rather than an Android-side sending irregularity.

Expected vs. actual timing:

Expected (Android send / nRF receive both at ~20 ms):
Packet 1 -> 0 ms, Packet 2 -> ~20 ms, Packet 3 -> ~40 ms, Packet 4 -> ~60 ms, Packet 5 -> ~80 ms

Actual nRF reception:
Packet 1 -> 0 ms, Packet 2 -> ~100 ms, Packet 3 -> ~150 ms, Packet 4 -> ~117 ms, Packet 5 -> ~109 ms, Packet 6 -> ~110 ms

This irregularity makes reliable real-time audio streaming impossible.

CONNECTION PARAMETERS
Connection interval: 10 (12.50 ms)
Latency: 0
Supervision timeout: 1000 ms

L2CAP CONFIGURATION
Channel connects successfully:
L2CAP channel connected, PSM=0x0086
RX: CID=0x0040 MTU=245 MPS=247 credits=1
TX: CID=0x004f MTU=65535 MPS=272 credits=0

Android sends ~164-byte application packets (2 bytes sequence number + 2 bytes payload length + 160 bytes audio payload), which fits within the nRF L2CAP MPS of 247 bytes.

ZEPHYR L2CAP RX TIMING INVESTIGATION
I instrumented the Zephyr L2CAP receive path:
bt_l2cap_recv() -> L2CAP RX work processing -> l2cap_chan_le_recv() -> application recv callback (l2cap_recv())

For every packet, the time from bt_l2cap_recv() to my application callback is only a few microseconds, e.g.:
T2: bt_l2cap_recv t=9445 len=166
T3: CID=0x0040 len=166
T4: L2CAP packet queued t=9445
T5: L2CAP RX work processing t=9445
T6: l2cap_chan_le_recv len=166 credits=0
T7: APPLICATION RX len=+

This confirms the 100-200 ms delay is not introduced by Zephyr's host-side L2CAP processing or my application callback - the packets are already arriving at the host irregularly.

I'm happy to share the complete L2CAP channel implementation, prj.conf, Android L2CAP implementation, and additional logs if that would help.

Thank you for your support.

[Hung Bui]

Hi Nikul, 

To be able to get more insight on why you have higher latency with your connection , please try to use a sniffer to capture the communication. 

 We need to check this irregular, if it's because of interference, or wrong connection configuration or some bottle neck. 

I would suggest to try testing with normal BLE communication to see if you have expected latency or not. 

[nikul]

I am testing the data reception speed between two nRF devices. One nRF device is transmitting data to the second nRF device, and I want to measure the packet reception interval and identify any delays on the receiving side.

I have provided the related log file and attached the main.c file of the receiving device. Could you please review the logs and the code and help me identify the possible cause of the delay or slow data reception?

[Hung Bui]

Hi Nikul, 

If you have a nRF5 DK you can use it as a sniffer. You don't need extra hardware for that. 

As I mentioned, please try to test with a simple BLE application to see if you have good latency.
Also try to adjust your application to send say 20 bytes of data via L2CAP CoC to see if you can achieve the same latency. 

[nikul]

I understand that the nRF52840-DK is required to use as a BLE sniffer, but I currently do not have an nRF52840-DK. I only have an nRF54L15-DK, which does not support the BLE sniffer functionality.

As suggested, I tested a simple BLE application with a small 6-byte data packet to check the connection latency. However, I am still seeing the same latency issue even with only 6 bytes of data.

what to do next?

[Hung Bui]

Hi Nikul, 

 We would really need to have a sniffer trace to see if it's the case.
If you have 2 nRF54LDK you can try to use them to test as both sides of the connection so it's not dependent on the Android phone. If you test with the phone, make sure you turn off Wifi when testing. 

Please try to test with the throughput sample https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/samples/bluetooth/throughput/README.html