BLE_GATTS_EVT_HVX_TX_COMPLETE triggered too late

[chxt]

Hi,

In our current project we use nordic NRF52832 ble to send some data(~200 Byte / packet) to host, we expect each transmission to be done within 10ms, but results from experiment shows non-deterministic delay varies from 10ms to 60ms, how can we achieve more stable result?

Here is the configuration parameters used:

`MIN_CONNECTION_INTERVAL`: MSEC_TO_UNITS(8, UNIT_1_25_MS)

`MAX_CONNECTION_INTERVAL`: MSEC_TO_UNITS(8, UNIT_1_25_MS)

`NRF_SDH_BLE_GATTS_MAX_MTU_SIZE`: 247

`NRF_SDH_BLE_GAP_EVENT_LENGTH`: 6

delay time is measured using `app_timer_cnt_get()`, started from `ble_nus_data_send()` and stopped when `BLE_GATTS_EVT_HVX_TX_COMPLETE` was received

---

the following shows our experiment's result:

regards,

chxt

[Sigurd]

Hi,

What device are you sending the packets to ? Note that the master could have set the conneciton interval to something else than 8ms. The master is the one that decides what that connection interval will be. A sniffer log should help you see what is happening on-air. See this link.

Note that the BLE_GATTS_EVT_HVN_TX_COMPLETE event, and other SoftDevice events are asynchronous. Also note that this event has a count field. See this link.

[chxt]

Hi, Sigurd,

I'm using a dwm1001-dev board which has a nordic NRF52832 MCU, and a NRF52840 USB Dongle was plugged on host computer for receiving(with pc-ble-driver), both side was using the same BLE parameters.

Today I also did another experiment using only 2 dwm1001-dev boards (NRF52832), with example ble_app_uart / ble_app_uart_c from nRF5_SDK_15.3.0, the results seems much better (20 - 40 ms). Besides, I didn't find any significant difference in the sdk_config.h used for NRF52832 central and NRF52840 central.

[chxt]

I tried to flash nrf-sniffer to either dwm1001-dev (sniffer_pca10040_c87e17d.hex) or NRF52840 dongle (sniffer_pca10056_c87e17d.hex) but both doesn't work, I didn't have any other PCAxxxxx board used for test right now.

[Sigurd]

Hi,

If you are sending a lot of data, several BLE_GATTS_EVT_HVN_TX_COMPLETE can be combined into one with the count field incremented. With pc-ble-driver you have more overhead in the communication, so that could add more delay. Increasing NRF_SDH_BLE_GAP_EVENT_LENGTH might improve it.

[chxt]

Hi, Siguad

thanks for you reply, after many trials, I found this phenomenal is mainly caused by the logic I send packet, where I send packet use a timer at a fixed timeout which may not be aligned with Link timeslot start point, so delay is random distributed with 1-CI variation, the other factor is scanning spends some timeslots which adds additional delay.

regards