nRF5340 BLE Transmission delay

RE: nRF5340 BLE Transmission delay

JONATHAN LL — Wed, 26 Jun 2024 06:20:21 GMT

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

RE: nRF5340 BLE Transmission delay

AKV — Fri, 21 Jun 2024 09:10:16 GMT

Hi,

Thanks for the response.

[quote userid="91187" url="~/f/nordic-q-a/111883/nrf5340-ble-transmission-delay/488358"]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. [/quote]

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.

[quote userid="73768" url="~/f/nordic-q-a/111883/nrf5340-ble-transmission-delay"]

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?

[/quote]

Could you please answer the question that was previously asked?

RE: nRF5340 BLE Transmission delay

JONATHAN LL — Wed, 12 Jun 2024 10:53:20 GMT

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

RE: nRF5340 BLE Transmission delay

JONATHAN LL — Tue, 11 Jun 2024 14:13:04 GMT

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.

[quote userid="73768" url="~/f/nordic-q-a/111883/nrf5340-ble-transmission-delay"]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. [/quote]

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

RE: nRF5340 BLE Transmission delay

AKV — Tue, 11 Jun 2024 13:21:28 GMT

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.

RE: nRF5340 BLE Transmission delay

AKV — Thu, 06 Jun 2024 13:53:07 GMT

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.

devzone.nordicsemi.com/.../nRF5340_5F00_Sniffer.pcapng

RE: nRF5340 BLE Transmission delay

JONATHAN LL — Thu, 06 Jun 2024 13:31:57 GMT

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