BLE Gatt Read Characteristic Slow Or Normal?

RE: BLE Gatt Read Characteristic Slow Or Normal?

FormerMember — Thu, 18 Jun 2015 04:33:47 GMT

On the BLE_GAP_EVT_CONNECTED: I set the parameters using sd_ble_gap_conn_param_update. For experimental purposes, I used a min interval of 12ms and a max interval of 25 ms. The results were much better, however the reception time difference between packets varied from 16 to 38ms(Android).

I tried 3 settings to match different sensor sample rates on the BLE device.

40 Hz (20ms) 50 Hz (25ms) 100 Hz (10ms)

Over a period of a minute or more, the reception rate at the Android end matched the sensor sample rate. To achieved the increased rates I simply reduced the connection interval. All in all satisfactory results. Over periods of 8 hours or more, the behavious remained the same.

RE: BLE Gatt Read Characteristic Slow Or Normal?

Ulrich Myhre — Wed, 17 Jun 2015 07:44:32 GMT

You could try to send some Connection Parameter Update requests with lower and lower parameters and see what your peer accepts. The numerous threads on DevZone about throughput should be mentioning the minimum connection parameters for various smart phone centrals, here is one of these. It mentions that the latest iOS (at that point) did not allow anything below 30ms, but there is an exception here for device that have a HID profile.

RE: BLE Gatt Read Characteristic Slow Or Normal?

FormerMember — Wed, 17 Jun 2015 07:27:56 GMT

It did strike me as very slow. I'm not sure of the cause. As you say it could be interference caused by numerous other devices using the 2.4GHz band. The results are pretty consistent for different applications.

Notifcations are reasonably fast, 30 ms for IOS, 50 ms for Android. My aim is for about 20ms.

RE: BLE Gatt Read Characteristic Slow Or Normal?

Ulrich Myhre — Mon, 15 Jun 2015 11:45:22 GMT

Hi Paul,

Of all the things that govern the response time and throughput of read requests, the only thing you can tune here is the connection interval. This can be done by sending a connection parameter update request (if you are the peripheral) or by changing them directly (if central). This is done by calling sd_ble_gap_conn_param_update() with the connection parameters your prefer. The PPCP (Peripheral Preferred Connection Parameters) are only an indication of which connection parameters you normally prefer, but not all peers will care about this. PPCP is also only available after you are connected, unless you choose to include the AD field in your advertising data. Each central will also have their own limitations on connection parameters, where e.g. Android will go down to 7.5ms and iOS to 11.5ms (only if HID service available).

You should set the PPCP to whatever parameters you prefer for normal operation, and send a connection parameter update request at the start of the connection if the parameters are unsuitable for your requirements. There are certain rules when it comes to combinations of slave latency, supervision timeout and connection intervals and quite different power usages, so please read through the documentation for sd_ble_gap_conn_param_update() and ble_gap_conn_params_t to get some pointers on these.

The normal delay of a read request should be no more than 7.5ms at normal operating conditions, but this can be much worse in places with lots of interference in the 2.4 GHz band (leads to CRC errors, collisions, etc.)