Understanding connection interval, nRF Sniffer and transfer speed

[Burgers]

Hi everyone,

I'm trying to understand how BLE connection interval works and why my long read is so slow. My slave is nrf51822 with Softdevice 130 v2 and nRF5 SDK v11, and my master is an Android smartphone. The default GATT_MTU_SIZE_DEFAULT is 23.

I send a notification from my nrf51822, it contains 486 bytes. From the moment I read the characteristic, to the moment I get the data, there is a difference of 3673ms measured using nRF Connect with Android.

I'm also printing the connection interval (min and max) on the peripherial on BLE_GAP_EVT_CONNECTED and BLE_GAP_EVT_CONN_PARAM_UPDATE, and for this example I got 60, which if I'm not mistaken, it should be 60*1.25ms = 75ms.

This is what I see with the sniffer (I filtered out empty packets), which gives me a time difference between the last packet and the send request of 3480ms.

With empty packets,

So on nRF Connect I get 3673ms, and using the sniffer I get 3480ms. Is that for some other delays on my Android that are not account in the sniffer?

My issue comes when I trie to estimate the duration having just the connection interval and the number of bytes. If I send 22 bytes of data per packet, and I don't count the first 22 bytes sent on the notification, I should be getting,

Number of bytes sent: 486 - 22 (notification) = 464

Number of packets: 464/22 = 22

Estimated transfer duration: 22 * 75ms = 1650ms

Looking at the Sniffer we can see one packet was resent, so 1650 + 75 = 1725ms, which is about half of the time it actually took to send the data.

Is this because I need one connection interval to request data from the master to the slave, and another connection interval to send the data from the salve to the master?
Or is it because of those empty packets (which I don't know where they come from)?
If the reason is 1, then I guess I just need to decrease the connection interval, which I guess it will increase consumption. If it is 2, can we get rid of them? and how?

Thank you very much!

[Stian Røed Hafskjold]

So one connection interval consists of a RX and TX pair. Seen from the slave, the radio is receiving the request, then switches over to TX immediately. It has not processed the request yet, so sends an empty packet. Then the next connection interval the slave receives an empty packet from the master, and then sends the payload when switching over to TX. So yes doing it this way it requires two connection intervals to send the payload. However, when using notifications you do not have to wait for a request to send data. You just put all the data you want to send in the TX buffer and the slave will burst out the data every TX event.

[Burgers]

Hey Stian, thanks!

I checked my code, and I'm using notifications,

hvx_param.type      = BLE_GATT_HVX_NOTIFICATION
hvx_param.p_data    = value;

where value is my buffer (486 bytes), and, 

sd_ble_gatts_hvx(pressure_service->conn_handle, &hvx_param)

I don't know why I get the empty packets.

[Stian Røed Hafskjold]

Are you requesting data to be sent every time you send a notification? If so, it will require two connection events. An then you will always get two empty packets because of how the RX/TX pair work.