Central Latency and BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE

[jmag999]

I have an nrRF52832 central connecting to 16 (nordic-based) peripherals.  We allow up to 20 connections on this design, but only 16 are currently connected during this test.

We are trying to find out why messages are not getting through in the timeframe we expect, so I enabled a gpio toggle on the BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE event.

We are seeing this event triggered 20 times for every packet that goes out.  Is that normal?

Additionally, we are using the following settings on the central

#define SCAN_INTERVAL MSEC_TO_UNITS(200, UNIT_0_625_MS) /**< Determines scan interval in units of 0.625 millisecond. */
#define SCAN_WINDOW MSEC_TO_UNITS(5, UNIT_0_625_MS) /**< Determines scan window in units of 0.625 millisecond. */
#define SCAN_TIMEOUT 0 /**< Timout when scanning. 0x0000 disables timeout. */
#define CONNECT_SCAN_TIMEOUT 1 // 1s /**< Timout when scanning for connect. */

#define MIN_CONNECTION_INTERVAL MSEC_TO_UNITS(55, UNIT_1_25_MS) /**< Determines minimum connection interval in milliseconds. */
#define MAX_CONNECTION_INTERVAL MSEC_TO_UNITS(55, UNIT_1_25_MS) /**< Determines maximum connection interval in milliseconds. */
#define SLAVE_LATENCY 0 /**< Determines slave latency in terms of connection events. */
#define SUPERVISION_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS) /**< Determines supervision time-out in units of 10 milliseconds. */

#define NRF_SDH_BLE_GAP_EVENT_LENGTH 2
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 23

With these settings, we are seeing that packets sometimes take 250ms to be transmitted even though the connection interval is 55ms.

Any idea why this might be?

[tesc]

Hi,

We are seeing this event triggered 20 times for every packet that goes out.  Is that normal?

That doesn't sound right to me. How do you keep count of the number of packets going out? You should expect equally many, or fewer, BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE events as you have calls to sd_ble_gattc_write(). See the GATTC Characteristic Value Write Without Response Message Sequence Chart.

While you have set min and max connection interval to 55 ms you may still experience noise and packet collisions which makes some of the connection events drop out. With supervision timeout of 4 seconds you will still have the connection intact as long as the time between two successful connection events is less than 4 seconds. Even though you use write without response there will still be ACKs at a lower level of the BLE stack, so all the writes will eventually get through as long as the connection is up and running.

A sniffer log would be most helpful in determining what actually happens over the air.

Regards,
Terje

[jmag999]

I can confirm that changing the number max peripheral connections to the central affects the number of BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE events that are triggered.  I believe this may be a bug.

I am designing this system to be as low latency as I can.  I send a message to every peripheral every 2 seconds.  On a logic analyzer, I can see that at least 50% of the time, a packet is not delivered to one of the peripherals in that 55ms window.  Is there any way to find out what the complete link schedule looks like in my system?

[tesc]

Hi,

Regarding the number of BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE events relative to the maximum number of peripheral connections, what is the (potential) but that you see there? Please note that the event does have a data field "count" for the number of write without response transmissions completed, ref. ble_gattc_evt_write_cmd_txt_complete_t.

What do you measure using a logic analyzer? Do you mean a BLE sniffer? In any case, I would like to know a bit more about your setup, it is not clear to me what you measure and how.

Regarding connection timing, there is a lot of information in the SoftDevice Specification for how connections are scheduled. In particular two sections should be of interest to you: Connection timing as a Central, and Suggested intervals and windows.

Regards,
Terje