sd_ble_gatts_hvx duration

[nrbrook]

Sometimes when I call sd_ble_gatts_hvx, it can take several ms to return. Most of the time it takes very little time (<1ms), but occassionally it takes up to 34ms, my connection interval is 15ms, I'm not sure if related. I time the call by taking a timer count with app_timer_cnt_get before and after the call and then logging the difference converted to ms. It is my understanding that sd_ble_gatts_hvx should simply add a notification to a queue and return, not wait for space etc. Are there any reasons why sd_ble_gatts_hvx should take so long? I'm using nRF SDK 17.0.2 with S132 7.2.0 on nRF52832.

The call is being made from the main loop (app scheduler). I did wonder if softdevice interrupts were occurring during processing. Sometimes I do get BLE_GATTS_HVN_TX_COMPLETE events during the call, but not always, and the delays only occur in sd_ble_gatts_hvx, not other function calls.

[Simonr]

Hi

Due to the summer vacation period we are currently understaffed, so delayed replies must be expected. I am sorry about any inconvenience this might cause. Karl is out of office for the time being, so I've been assigned this case in his absence.

Can you provide a sniffer trace of the connection and data transmission so we can get a clearer picture of these timings. The timestamps from your iOS log shows when they were received on the iOS device, and not necessarily when they were transmitted from the nRF52. If you don't have a dedicated sniffer, you can use an nRF52 DK and the nRF Sniffer tool with Wireshark to do a sniffer trace of the connection.

For all I know this delay might come from the iOS handling the data as well. Do you see this when connecting using I.E. an Android phone as well, and the same amount and length of delays?

Best regards,

Simon