Slave latency and interval connection for GAP advices

RE: Slave latency and interval connection for GAP advices

BHAGYESH — Tue, 28 Feb 2017 11:23:23 GMT

Hey Guys, Any one could help me for android??? What should be the parameters for ANDROID???

RE: Slave latency and interval connection for GAP advices

Sébastien Despont — Fri, 23 Aug 2013 10:27:36 GMT

Thank you for your answer.

It is clear for me now. I have updated the ble_conn_params.c file as you said to specify the new connection interval and slave latency.

Best regards

RE: Slave latency and interval connection for GAP advices

Ole Morten — Thu, 22 Aug 2013 10:03:17 GMT

How often do you see the LED toggle currently? What could be a problem here is that the default implementation in ble_conn_params only checks the connection interval and not slave latency when checking whether current parameters are good. I belive that later versions of iOS often uses an interval of 30 ms when connecting, and if that is the case, there may never be sent an update request, since this is within your max and min. If this is the case, you should see connection events every 30 ms.

One way to change this is to modify ble_conn_params to also check slave latency when considering parameters. This check is done in is_conn_params_ok() in ble_conn_params.c, and it should be fairly easy to extend this to also check slave latency. Doing so, you should see radio notification for every slave-latency-th connection event, if no data is pending.

Remember that the device will wake up and send data every event if any data is queued; the slave latency is only used when no data is currently queued.

RE: Slave latency and interval connection for GAP advices

Sébastien Despont — Thu, 22 Aug 2013 08:31:41 GMT

Thanks for your quick reply.

My parameters now meet the Apple requirements :

#define SECOND_1_25_MS_UNITS 800
#define SECOND_10_MS_UNITS 100
#define MIN_CONN_INTERVAL (SECOND_1_25_MS_UNITS / 100) * 2 /*20ms*/
#define MAX_CONN_INTERVAL (SECOND_1_25_MS_UNITS / 10) * 4 /*400ms*/
#define SLAVE_LATENCY 4
#define CONN_SUP_TIMEOUT (4 * SECOND_10_MS_UNITS) /*4s*/

I am aware that the peripheral can send data immediatly as you explained in this thread.

But in my case, there is no connection problem between the device and the chip. I am able to receive and send data to the chip with my IOS app.

I added breakpoints in the ble_conn_param in the event handler to check if some errors occurred, but I never reach one of the error checked :

// Parameters are not ok, send connection parameters update request.
// Negotiation failed, disconnect automatically if this has been configured
// Notify the application that the procedure has failed

I just want be able to increase the interval connection to move my motors without radio interrupt perturbation.

As I said in my question, I can see when the radio connection event handler is called because I am eneabling and disabling a LED on the dev kit.

Could help me to understand why the connection parameters don't change the frequeny where the event handler for radio notificaiton is called by the softdevice?

Best regards

RE: Slave latency and interval connection for GAP advices

Ole Morten — Thu, 22 Aug 2013 08:04:10 GMT

I assume you're aware of how connection parameters work with BLE, and how the Peripheral can send requests for updated parameters, for example by using the ble_conn_params module from the SDK. When the Peripheral sends such requests, it's up to the Central to either accept or reject them, and if you implement the event handler that the ble_conn_params module suggests, you can get an event when either of this happens with SDK 4.3. If you don't seem to get the connection parameters you want, it's useful to implement this, to see whether you get the FAILED event.

If you're working with Apple devices, it's useful to be aware of the fact that they have their own document detailing their recommendations for connection parameters. This document can be found here. If things doesn't work as you expect, I'd therefore make sure that you comply with these requirements.