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 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

Answer 1

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.

Answer 2

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.