Bluetooth Low Energy - updating a characteristic value repeatedly

21
votes

Follow-Up question on Electrical Engineering Stackexchange

I want to write the value of a Bluetooth Low Energy characteristic repeatedly in a short amount of time (as a possible use case, imagine a mouse).

  • The characteristic with a 128bit UUID is 20 bytes long. Therefore, it can be written in a single Low Energy transaction.
  • Writes occur at a rate of 50 Hz, that is equal to a write once every 20ms.
  • Therefore, 20 * 50 * 8 = 8 kbit/s are written.
  • I am using the Command / Write without response mode to write the characteristic. Therefore, no acknowledgments happen on the attribute layer.
  • No other Bluetooth or Bluetooth Low Energy devices are connected. Nothing is performed over WLAN. No other characteristics are read or written during the tests.

I test the program by sending packets containing sequence numbers from an iPhone 4S. The sequence number is incremented by one after each sent packet.

On the receiving side, a programmable development board, that incorporates a CSR1000 BLE chip, is used that receives the packets and prints the received sequence numbers to the serial connection.

My problems are the following:

  • After some time, packets start getting dropped. The first ~100 packets work fine @ 50 Hz. From then on, packets start getting dropped.

               0x00 - 0x46   received
            0x47, 0x48   missing
0x49, 0x4a, 0x4b, 0x4c   received
                  0x4d   missing
0x4e, 0x4f, 0x50, 0x51   received
                  0x52   missing
0x53, 0x54, 0x55, 0x56   received
                  0x57   missing
...

    Most often, a pack of four packets is transmitted fine (rarely, only 2 packets). Then, 1-7 packets are missing.

    When I reduce the characteristic value size, the problem still persists.

    When I write at 100Hz instead of at 50Hz, the picture is the same - only that the drops start occuring after around 35 packets and that 5-7 packets are dropped between the successful transmission of four packets.

    With the lost packets, the resulting transmission rate is around 5 kbit/s, regardless of the frequency of writes. This is clearly below the ~305 kbit/s that should be technically possible over Bluetooth Low Energy.

  • The problem also occurs into the opposite direction, when I am sending packets from the development board to the iPhone 4S. Again, 5 kbit/s is the maximum that I am getting. The Notification mechanism is used for this scenario. Again, no acknowledgments happen on the attribute layer.

  • When I try to send in both directions simultaneously, things start to blow up to the point where I have to reset both the development board and the iPhone 4S.

Questions:

  • May this be a problem of the Bluetooth Low Energy chip, that is used on the development board?

    If yes, why does the problem also occur into the opposite direction, where the iPhone acts as the receiver?

    Are there any development boards on the market that support high-frequency access to characteristics?

  • What could be the origin of the problem?

    Please also try to reference parts of the Bluetooth Spec / presentation slides / articles in addition to assumptions.

There exist Bluetooth Low Energy mice on the market. Mice have typical polling rates of 125 Hz and have to at least send two 16 byte values plus additional HID overhead per tick. Therefore, a solution for my problem should be available.

Update

The LE Connection Complete Event is described in Bluetooth Specification Version 4.0 Vol 2 Part E Section 7.7.65.1. I receive the following values for the different connection parameters:

Parameter               Value      Description
--------------------------------------------------
Conn_Interval           0x0054     Time =  105 ms
Conn_Latency            0x0000     Time =    0 ms
Supervision_Timeout     0x00fc     Time = 2520 ms
Master_Clock_Accuracy     0x05              50 ppm
3
iosperformancebluetoothpacketbluetooth-lowenergy
What LE chip/dev board are you using? – Simon Peverett
What parameters have you set for the connection - are you using the default? – Simon Peverett
How do you see the connection timings? – chwi
@Wilhelmsen: The LE Connection Complete Event exposes the parameters. See Bluetooth Core Spec Version 4.0 Volume 2 Part E Section 7.7.65.1. I can look at these values on my peripheral. – Etan
Do you look at the actual timing parameters or the parameters you set the peripheral to ask for? I.e, are the parameter "live" data? – chwi

3 Answers

15
votes

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.

2
votes

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.

2
votes

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