nRF5340 BLE Transmission delay

[AKV]

Hi

We are using the nRF5340DK with NCS Version 2.6.1.

Our goal is to send 52 bytes every 20 ms. To achieve this, we have configured the parameters as follows: MTU is set to 66 bytes, Connection Interval is 7.5 ms, and Event Length is 2.5 ms.

We utilize the bt_gatt_write_without_response_cb() function with a transmit complete callback.

We noticed that the time interval between placing data in the buffer using bt_gatt_write_without_response_cb() and receiving the transmit complete callback frequently exceeds 20 ms, even when the device is in close proximity. This should not occur, as we are using the CI 7.5ms, unless there is some internal processing causing the delay.

1. Given the sufficient bandwidth provided by the configured BLE parameters, why is the transmission taking longer than 20 ms?

2. Is this issue related to our use of the transmit complete callback function? The function definition states, "By using a callback, it also disables the internal flow control, which would otherwise prevent sending multiple commands without waiting for their transmissions to complete. Therefore, if this is necessary, the caller should avoid submitting more data until the callback is called."

If we use bt_gatt_write_without_response() without the transmit complete callback function, the system enters a hang state when the stack buffer is full.

3. How can we monitor the stack buffer queue in real-time to prevent deadlock without using the transmit complete callback? Are there any example codes available?

[JONATHAN LL]

Hi,

Can you provide us with a sniffer trace?

How do you measure the timing. A sniffer trace\log would give us some insight to what is going on here. 

Regards,
Jonathan

[AKV]

Hi,

Thanks for the response.

I have attached the sniffer log.

We are transmitting data in both directions—master to slave and slave to master—every 20 milliseconds. 

We are using the function k_uptime_get_32() for time capture. The start time is recorded when data is sent using the bt_gatt_write_without_response_cb() function, and the stop time is recorded upon receiving the callback.

nRF5340_Sniffer.pcapng

[AKV]

Hi,

Update:

I have tried sending packets using the notification method with the bt_gatt_notify_cb() function, which includes a callback. We used this callback to capture the transmission timing, but the data transmission time frequently exceeds 20 ms. Additionally, I observed that the transmission time exceeding 20 ms occurs more often on the peripheral side compared to the central side.

[JONATHAN LL]

Looks like most things are in line and the connection intervall is 7.5ms as you set it to be, so it looks to be ok, but when ever the 20ms or longer delay happens I dont see any specific issue other then that it looks to be more package loss in some situations. This could be due to noise in the area blocking the communication and causing re-transmissions or It could be the sniffer that is not able pick up the packets, most likely senario. 

One thing that you can test is to do this somewhere else, away from other WIFI and BLE devices. 

AKV said:

We noticed that the time interval between placing data in the buffer using bt_gatt_write_without_response_cb() and receiving the transmit complete callback frequently exceeds 20 ms, even when the device is in close proximity.

Also just to clear things up, are you not expecting a response? 



Also, writing something two fast can cause some noise that will interfare with the next, so this can create a situation where there will be 21+ms or more delays.  Do having a connection interval of 7.5ms and then writing something 1ms after the previous one will cause the next 2 to be missed in some cases. 
The callback will first occur after LL has received the packaged from peer.  

So can try to slow things down and see if less delays happen. 

Regards,
Jonathan

[JONATHAN LL]

Adding some debug option here that you can use to speed up the process, you should be able to see what is going on in more detail. 

There could be latencies in the firmware (callbacks, pre processing of data before queueing to transmit in BLE, or post processing of incoming data) 

Not sure which side is the dUT (Central or Peripheral) but it is easy to pin point where the latencies are using Systemviewer. With that you can get a timeline view of every context running in Zephyr in the firmware and we can know which context is using up most of that 20ms.

Regards,
Jonathan

[AKV]

Hi,

Thanks for the response.

JONATHAN LL said:

Also, writing something two fast can cause some noise that will interfare with the next, so this can create a situation where there will be 21+ms or more delays. 

As you mentioned, we have understood the delay issue.

We have tried different write methods: write with response, write without response, and notification. However, all three approaches had the same impact, with no speed improvement. Our understanding is that notification is supposed to be faster, but since it also involves a callback, it isn't actually faster than the write methods.

AKV said:

If we use bt_gatt_write_without_response() without the transmit complete callback function, the system enters a hang state when the stack buffer is full.

3. How can we monitor the stack buffer queue in real-time to prevent deadlock without using the transmit complete callback? Are there any example codes available?

Could you please answer the question that was previously asked?

[JONATHAN LL]

I don't have a reasonable explanation to why it takes that much time as of now, it seems it should not so still looking in to what is causing this behaviour. 


As for examples on real time monitoring technics I am not aware of any examples or setups for this. 

What I think would be the best configuration here is to use a separate thread to that pushes packages to the BLE-stack so that the main thread would not be delayed if the function is blocked. 

Best setup for investigating further would be to use SystemViewer and see what is happening, could give some more insight to what is causing the delays. 

Regards,
Jonathan