This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Slave latency & communication speed Nordic's trick?

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

  • @Valer_I : Please update the question with the sniffer trace of both cases.

    Why do you want to have slave latency ? Note that not all the time the central would accept slave latency even the peripheral requests it, you need to check if slave latency is actually used.

    We also need to check on how often in your central device (Android) you call write command, and if you queue enough write command on the phone to force it to write more often.

  • Updated. The slave latency used for energy saving purposes. Yes, we check whether central accepts or rejects slave latency. In last case we request conn params without slave latency. However, about 95% of devices we tested with accepts slave latency.

  • It's pretty evident that first "Empty packet" pair after Notification is just on Android and because it's Master (Central) who drives this you can do nothing about it. If it triggers Slave Latency window on the other side then no surprise, Soft Device is doing what you told it to do (miss 16 intervals if there is nothing to do from Peripheral side = your app). If you want to react to any Write from master immediately whenever it sends it then give up your Slave latency.

  • So basically you want to get rid of the Empty Data PDU sent by the master ? I would say it has something to do with how you queue the write command. I would suggest to call it as much as possible until you receive TX buffer full and call again when you have a call back.

  • To make master queue the write commands faster is job of master's software. Ok, we see that Windows software make it faster (in our case) and I have to find out how to make Android to send write commands as fast as in Windows case. Android software sends the empty packet just after notification sent by peripheral. But in both cases Softdevice answers with GATT Notification in case of Windows and with Empty PDU in case of Android.

    So shall we say that Sotdevice hold radio in active state for 1 connection interval after Notification sent and than enables slave latency function? 1? (This was my main question)

Related