ble_app_uart is too slow for IOS,how to fix it?

[qoboty]

I use ble_app_uart of IOS,but the Tx speed is about 200B/s(send 20B for 100ms), why ? how to speed up to 20KB/s ? Thank you!

[Hieu]

The (20B)/(100ms) most likely is because of two facts:

1. Only up to 20B can be transferred in one BLE data packet
2. The connection interval of the connection between the BLE peripheral and your iOS device is probably 100ms

(This is weird because the default used in SDK v10 ble_app_uart example is set to have a minimum connection interval of 20ms, and maximum connection interval of 75ms... May I ask where you got those numbers? I am assuming some further delay was introduced due to processing.)

If you stick with NUS, one thing you could do is decreasing the connection interval and thus increasing throughput. According to Bluetooth Design Guidelines from Apple, the minimum you can go to is 20ms. You can force this minimum connection interval by setting both the minimum connection interval and maximum connection interval to 20ms. In nRF51 SDK v10.0.0's ble_app_uart example, I did this by having the following modification:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(20, UNIT_1_25_MS) // Line 69
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(20, UNIT_1_25_MS) // Line 70

Notice MAX_CONN_INTERVAL changed to an equivalent of 20ms. This change the connection parameters being used to initialize GAP in gap_params_init() (Line 179)

Running a modified example as such on the nRF51 DK, I could still connect to the DK with my Moto X phone (Android) and observed that the firmware still worked correctly.

With one packet per 20ms interval, you are now at (20B / 20ms) = (1B / 1ms) = (1kB/s).

To increase the throughput even further, you need to modify the code so that multiple packets are notified one after another. Unfortunately, even with this, you could only push it to 4~6 packets/interval. That is limited by the SoftDevice and your iOS device, so there are no way to overcome this. Therefore you are limited to 4~6 kB/s. And this is assuming no other delay get in the way.

You can refer to the following answer for another great explanation on this topic: devzone.nordicsemi.com/.../

[Hieu]

@qoboty: I was actually wrong about that. I was looking at the ble_nus_string_send() method and see that it only call sd_ble_gatts_hvx() once, and thought that that means this service only send one notification at a time. It never occurs to me that I could bypass that helper function and purposefully call sd_ble_gatts_hvx() multiple times.

However, while doing that, I have encountered something pretty strange. Even though I have 13 notification calls every external event, only 7 notifications happened. I am going to open a question on that.

@kristin: Sorry about the mistake. I have updated the question to reflect it now.