Packet lost during stream of data transmission - connection interval issue?

[Maz Shar]

SDK Version: 9.0.0 Softdevice: S110 v8.0.0

I'm currently trying to send streams of data from an Android app to a nrf51. However, at some point, Android side writes to the characteristic which the nrf51 does not acknolwedge.

How it works:

1. Android reads file
2. Android sends first data record (16 bytes) to nrf51
3. nrf51 changes a characteristic value to trigger notification
4. Android receives notification and sends next data record

This repeats until all the data has been received by nrf51.

Problem:

At some point, the Android device will send a data record which the nrf51 will not receive. This halts the procedure. I confirmed this by having a counter where my App writes to the characteristic to show it sent X data records then one on the nrf51 (OnWrite function) to show it received only X-1 data records. I do get an acknowledgment on the Android side that the characteristic has been written (from the BluetoothGattCallback onCharacteristicWrite callback). I can get this to work if I put a delay >= 50ms (in Android app) between receiving notification from nrf51 and sending next data record.

I understand a workaround would be to have a timeout on the Android side and retransmit but I believe there must be a way to make this first pass more reliable.

Investigation:

After some research, I discovered a low connection interval could cause issues here. I have started to implement the connection parameters module to negotiate an appropriate connection interval upon connect. However, before I go any further, I would like to confirm that this is the cause and not something completely different.

I looked at the time between nrf51 receiving each data record and discovered it was always in slots - mainly 145ms and sometimes 197ms. Reducing the Android delay from 50ms to 30ms led to 96ms, mostly 145ms and sometimes 197ms. This further suggests that the transmission is missing some sort of window.

---

Has anyone else come across this behaviour before? Am I right in thinking that modifying the connection interval would solve issues with sending large data sequentially? Or is this a known issue with my version of the softdevice?

[Christopher]

First, I am not sure your uses the right primitive here... In my opinion, if you need to write data to the peripheral and you want to be sure it has received the data (I assume your Android phone has the central role), you should use a confirmed service (with response) instead of doing this manually by sending a notification back to the central device. The SoftDevice can manage this for you.

Have a look at this post from Nordic which describes the GATTS Write Commands and Request. Some sequence diagrams are available here.

I do not know the BLE throughput you need/want to achieve, but first try to set a connection interval >= 20 ms. If you use a write request (with response) instead of a write command and a notification you will be able to send BLE packets faster.

[Maz Shar]

Thank you, metch. I have now implemented BLE connection parameters and with a 30ms interval time, I can achieve a throughput which is much closer to what we want!

Is there a way of dynamically renegotiating connection parameters through software lifecycle? E.g. we want 15ms in sleep mode and then 30ms when communicating?