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?

[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