BLE device fails to send multiple GATT notifications in a row

Question

I'm experimenting with Bluetooth LE with GATT and I have encountered a problem I need your help with.

I'm sending Data back and forth between a Client (One Android Application and one iOS Application) and a Server (Currently running Bleno).

I have chosen an architecture with one Characteristic only (which I think of as a Socket) and I write Requests on it from the Clients. The Server responds to the request with a Notification. Notifications can only be 20 Bytes long, so I sometimes have to split the response into several Chunks and send it as separate notifications.

My problem is that when I split the response into 10 Chunks or more, they are never received on the Clients. (For 1..9 Chunks everything works as expected).

I have used HCIDump ( hcidump -i hci0 -X ) to inspect the commands sent over BLE both when it fails and when it succeeds.

The following output is taken from HCIDump when sending the notifications succeeds:

< ACL data: handle 69 flags 0x00 dlen 27
ATT: Handle notify (0x1b)
  handle 0x000c
  value 0x06 0x09 0x46 0x46 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47

followed by:

> HCI Event: Number of Completed Packets (0x13) plen 5
handle 69 packets 1

(for each of the Notification Chunks)

The next output is taken from HCIDump when failing to send notifications:

< ACL data: handle 68 flags 0x00 dlen 27
ATT: Handle notify (0x1b)
  handle 0x000c
  value 0x08 0x0a 0x46 0x46 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47 0x47

But I get no "Completed packets" events, but instead a simple device: disconnected .

I have yet to figure out on which side of the communication the error occurs. As far as I know, it could be either the Clients not being able to receive and Ack the Notifications "fast" enough, our because I'm queueing too many requests on the Server side.

I have tested to add Sleep() commands between sending each notification on the Server. It does work, but feels too unstable. For 10 notifications, I needed 6 ms delay for the notifications to come through, for 30 notifications, I needed 10 ms delay.

Does anyone know where to start looking for the problem? I'm happy to provide more information if needed.

Notes:

• I have tested and found exactly the same limits with my Android and iOS device.

Answer 1

There's a limit to how many "chunks" you can send before the queue gets filled. You have to wait for the central to confirm that it's ready to receive more data before you send the next chunk.

In bleno's case you'd wait to get back an indication in your characteristic's onIndicate callback before sending the next chunk:

var Characteristic = bleno.Characteristic;

var characteristic = new Characteristic({
    uuid: 'fffffffffffffffffffffffffffffff1',
    properties: [ ... ],
    secure: [ ... ],
    value: null,
    onIndicate: null // <-- Right here
});

At least for iOS, you don't have to change your implementation to get an indication back. As long as you've called setNotifyValue:forCharacteristic: you also enable indications, as per Apple's documentation:

Sets notifications or indications for the value of a specified characteristic.

I'm not sure if more work is required for Android.