Slave latency & communication speed Nordic's trick?

[Valer_I]

Hello, I use nRF51822 based device with s110 softdevice. I noticed that data exchange is different on different connected centrals. For test I used Windows and Android powered central. The task is to send request and receive responce in notification from the device. After connection I request similar connection parameters (conn interval 30ms, slave latency 16) and they are accepted by both centrals. The speed results are different. Data exchange with windows is about 10 times faster than with Android. After sniffing I noticed that softdevice send Empty PDU after each notification packet and then enables slave latency functionality (i.e. skipping n central's packets). Windows driver in some way send next write request just after notification sent. And communication is very fast, like with slave latency = 0. In case of Android the driver send Empty PDU after notification from peripheral and than write request, but soft device do not react for it fot slave latency number times. Windows:

M->S  Write Command  (request1)
S->M  Empty PDU
M->S  Empty PDU
S->M  Notification  (responce1)
M->S  Write Command  (request2)      !!!
S->M  Empty PDU
M->S  Empty PDU
S->M  Notification  (responce2)

Android:

M->S  Write Command  (request1)
S->M  Empty PDU
M->S  Empty PDU
S->M  Notification  (responce1)
M->S  Empty PDU     <- This makes data exchange slow 
S->M  Empty PDU
M->S  Write Command  (request2)      !!!
M->S  Write Command  (request2)
M->S  Write Command  (request2)
...
M->S  Write Command  (request2)
S->M  Empty PDU
M->S  Empty PDU
S->M  Notification  (responce2)

I feel the softdevice has some pause after sending the packet before enabling slave latency function. Am I right? If yes what exact pause time is?

Thanks

UPDATED:

Android: from line 730 ANDROID_CAP

Windows: from line 851 WINDOWS_CAP

[Hung Bui]

I don't think there is any kind of "answers" from the softdevice to write command. Unless that what you programmed your program on the chip to do.

It should be noted that on the Windows' case Slave latency was not used.

If you actively queue the notification, the softdevice won't enter slave latency mode but wake up and will wake up in the next connection event and send the packet instead.

We need to have a look at how and when you send the notification. Please provide your code.

[Valer_I]

Hi, in Windows' case slave latency was accepted by central in line 565 in log. So it was only up to softdevice to use slave latency. In code I do not actively queued notifications. The data transfer presented is flash memory readout procedure. Request with memory offset - responce with data if present or empty code. So one request - one responce. Additionaly, I can confirm that only one packet is in queue because I increment tx packet counter when place queue (with limit 6) and set it 0 in BLE_EVT_TX_COMPLETE event. And the value of counter not exceed 1 in this piece of data exchange. I can't provide the source code because of policy of my company.

[Hung Bui]

Sorry I missed the connection parameter update.

Beside what I suggested, of queuing the write command / notification more often to fill up the buffer, I don't have further suggestion.

[Valer_I]

Ok, thanks. Is it possible in some way to fill up tx queue to send empty packets and prevent slave latency functioning? (For energy saving purposes)Like:

uint32_t length = 0;
ble_gatts_hvx_params_t hvx_params;
hvx_params.handle = handle;
hvx_params.p_data = NULL;
hvx_params.p_len  = &length;
hvx_params.type   = BLE_GATT_HVX_NOTIFICATION;
sd_ble_gatts_hvx(conn_handle, &hvx_params);

[Hung Bui]

Yes, you can send empty payload notification, but it's not empty packet, it's a normal notification with empty payload.

I don't really understand, why don't you avoid slave latency at the first place, if you simply want to keep the chip awake ? Or you only request slave latency when you need to.

Note that from S132 v3.0.1 we provided a option api sd_ble_opt_set() to allow application on the nRF52 to disable and enable slave latency on its own. This mean even if the central reject to accept to change slave latency value, the nRF5 can choose to sleep or stay up on its own. But this is only for NRF52 with S132 v3.0.1 and later.