Bluetooth Low Energy - updating a characteristic value repeatedly

Question

Follow-Up question on Electrical Engineering Stackexchange

I want to write the value of a Bluetooth Low Energy characteristic repeatedly in a short amou

Answer 1

The main problem seem to be that it is a buffer problem on the chip you are using. From the core specification, Volume 3, Part F, 3.3.2:

For notifications, which do not have a response PDU, there is no flow control and a notification can be sent at any time.

Commands that do not require a response do not have any flow control. Note: a server can be flooded with commands, and a higher layer specification can define how to prevent this from occurring.

Commands and notifications that are received but cannot be processed, due to buffer overflows or other reasons, shall be discarded. Therefore, those PDUs must be considered to be unreliable.

Answer 2

What you are seeing when packets are dropped are due to buffer overflow either on the iPhone side (most likely I think) or on the host side. Starting with iOS 11.2, apple provides a mechanism allowing you to check if the buffer is ready before writing the next packet; canSendWriteWithoutResponse:

If you wait until canSendWriteWithoutResponse is true before writing a packet, the delivery is guarantied to have been placed in the receiving buffer, but not guarantied that it has been processed (unacknowledged). The other thing that could help is by negotiating a MTU size greater than 20. Apple supports MTU at 185B, and up to 251 (extended data length aka EDL). By chunking your data packets in MTU-3 sizes, your packet==(MTU-3) x 1 per connection interval. @185B MTU, 24 ms connection interval I have throughput around 48kbps with no dropped packets. When sending data to the iPhone from the device, the SDK on that end will need the equivalent to 'canSendWriteWithoutResponse', which in my case using SiLabs hardware/SDK does have e.g

```

 do {
     result = gecko_cmd_gatt_server_send_characteristic_notification(
              0xFF,
              evt->data.evt_gatt_server_attribute_value.attribute,
              chunk.length,
     [chunk bytes])->result;
 } while(result == bg_err_out_of_memory); 
  //retry until buffer is empty and ready for more 
 //then update the offset
 offset += thisChunkSize;

```

Here is a video and .pdf from apple explaining the different BLE techniques and expected speeds. MTU + Connection Interval is what you use to determine max throughput. 48kps should be easily achievable, 96kbps and maybe a little higher are possible.

What's New in Core Bluetooth

video: https://devstreaming-cdn.apple.com/videos/wwdc/2017/712jqzhsxoww3zn/712/712_hd_whats_new_in_core_bluetooth.mp4?dl=1
pdf: https://devstreaming-cdn.apple.com/videos/wwdc/2017/712jqzhsxoww3zn/712/712_whats_new_in_core_bluetooth.pdf 

Answer 3

Issuing a Connection Parameters Update solved the problem and increased throughput from 5 kbit/s to ~33 kbit/s. However, this is still below the expected ~305 kbit/s.

Conn_Interval = 0x000f = 18.75 ms
Conn_Latency  = 0x0000
Supervision_Timeout = 0x00fc

Are there any methods to reach the full ~305 kbit/s?

Follow-Up question on Electrical Engineering Stackexchange

Could get a reply from Apple by burning a TSI and waiting for a month.

Basically, they tell that the behavior is intended in iOS 5.1. It somehow makes sense, because they don't want that your app's performance depends on whether another app uses Bluetooth or WiFi.

Per the engineers comments - Under iOS 5.1 there should be 6 pairs of notifications during a connection interval, meaning 6*packetSize*1000/interval . This should translate to ~55kbps max (min interval is 20ms, packetsize is 23 bytes). We made the decision to limit the number of pairs per interval and have a minimum interval due to the fact that the iPhone and iPad both have shared antenna between BT classic, BT LE and WiFi.

iOS LE is designed to be a low power transport. For higher throughput BT classic is a better transport method.

Back to me - Based on the engineers comments above, if the desire is to achieve a 200 kbs throughput, Classic bluetooth is the answer. However, if the desire is to work with an application on the iPhone, I can understand that this is no simple change - Classic BT requires MFI licensing.