Quick connection parameters update

RE: Quick connection parameters update

boby — Mon, 13 Oct 2014 09:14:59 GMT

Hi,

I encounter the same issue than Ziran. After the connection, I do a first update of the connection parameters to a standard rate, that is working well. Then I update the connection parameters to a fast rate but when I try to return in standard parameters, there is disconnection... Sometimes I succes to return in standard params, but this is working only once. I tried on Android v4.4.2 and v4.4.4 and that the same problem.

Is there a solution ? Thanks,

RE: Quick connection parameters update

Ziran — Thu, 07 Aug 2014 09:17:11 GMT

Apparently, on Android 4.4.2 we can change the connection parameters only once . And that's why it does not want to go back to low or high after one update unless I disconnect and reconnect

RE: Quick connection parameters update

Ziran — Wed, 06 Aug 2014 11:48:34 GMT

[13:41:38.7] ConnectionParameterUpdateResponse sent with ACCEPTED response [13:41:38.7] Connection Parameters Update sent. ConnInterval:200.0ms, SlaveLatency:5, SupervisionTimeout:10000.0ms [13:42:33.9] Received a HandleValueNotification on handle 000E with value 01

the last line is when I reclick on the button.

RE: Quick connection parameters update

Ziran — Wed, 06 Aug 2014 11:47:46 GMT

Ok I fell like i'm on the right path ! So I'm still doing the connection parameter update because I really need a good reponse of the device from the smartphone. So my problem now is that the change seems to work only once( the first time I click on the button) then no response .

I got that [13:41:29.1] Received Connection Parameter Update Request [13:41:29.1] ConnectionParameterUpdateResponse sent with ACCEPTED response [13:41:29.1] Connection Parameters Update sent. ConnInterval:100.0ms, SlaveLatency:0, SupervisionTimeout:4000.0ms [13:41:29.5] Received a HandleValueNotification on handle 000E with value 01 [13:41:35.2] Received Connection Parameter Update Request [13:41:35.2] ConnectionParameterUpdateResponse sent with ACCEPTED response [13:41:35.2] Connection Parameters Update sent. ConnInterval:200.0ms, SlaveLatency:5, SupervisionTimeout:10000.0ms [13:41:38.7] Received Connection Parameter Update Request [13:41:38.7] ConnectionParameterUpdateResponse sent with ACCEPTED respons

RE: Quick connection parameters update

Ziran — Wed, 06 Aug 2014 08:50:41 GMT

When I use 100-200ms cnnnection parameters and slave latency of 40 . It's really slow to write a characteristic( maybe 2-3s).

Edit : I tried with 4 slave latency .It's kinda quick but every 5 second I have a little burst in the current consumption.is It because of NEXT_CONN_PARAMS_UPDATE_DELAY(It's 5s for me ) ?

Edit 2 : Nope , I changed it and it's not because of NEXT_CONN_PARAMS_UPDATE_DELAY

RE: Quick connection parameters update

Knut Eldhuset — Wed, 06 Aug 2014 08:46:55 GMT

Then you can use the slow connection parameters always and never change them. Empty LL packets ("keep-alive") will only be sent every (n + 1)'th connection interval if slave latency is n. If you do a notification, it can be sent in any connection interval.

RE: Quick connection parameters update

Ziran — Wed, 06 Aug 2014 08:30:08 GMT

Can you tell me how to check the return code please ? Is it the err_code=function(); APP_ERROR_CHECK(err_code);

RE: Quick connection parameters update

Ziran — Wed, 06 Aug 2014 08:29:46 GMT

Yep I did increase the Slave latency only for slow connection parameters. And changed the CONN_SUP_TIMEOUT

RE: Quick connection parameters update

Knut Eldhuset — Wed, 06 Aug 2014 08:27:17 GMT

ble_conn_params_change_conn_params(...) has a return code that you need to check. It is good practice to check the return code for all functions that have one. You will not be able to change the connection parameters if the previous procedure is not finished, or if the parameters are inconsistent.

RE: Quick connection parameters update

Knut Eldhuset — Wed, 06 Aug 2014 08:22:28 GMT

From the log, there is over 10s between each connection parameter update with 100.0ms connection interval. It does not seem like your timer is working properly. If no Connection Parameter Update Request is seen in the Master Control Panel, it is most likely that you have not successfully called the API function - either because the timer handling is not working, or because you get an error from the API function.

In any case, the better solution is to use slave latency.

RE: Quick connection parameters update

Ziran — Wed, 06 Aug 2014 07:53:06 GMT

I think one of the problem is that the handler is not handled correctly

RE: Quick connection parameters update

Ziran — Wed, 06 Aug 2014 07:20:08 GMT

Another thing . the second request update is not following any of my timers. And I get a [09:17:32.5] Lost connection to device. Reason: BTLE_CONN_INTERVAL_UNACCEPTABLE after the second one is accepted

RE: Quick connection parameters update

Ziran — Wed, 06 Aug 2014 07:01:36 GMT

This is my timer handler

   static void cp_timeout_handler(void * p_context) {
	UNUSED_PARAMETER(p_context);

		gap_params_low();}

Those are the funstion that send the new parameters

static void gap_params_high(void) {
	ble_gap_conn_params_t gap_conn_params_high;
    gp=false;
	memset(&gap_conn_params_high, 0, sizeof(gap_conn_params_high));

	gap_conn_params_high.min_conn_interval = MIN_CONN_ITVL_UPDATE;
	gap_conn_params_high.max_conn_interval = MAX_CONN_ITVL_UPDATE;
	gap_conn_params_high.slave_latency = SLAVE_LATENCY_UPDATE;
	gap_conn_params_high.conn_sup_timeout = CONN_SUP_TIMEOUT_UPDATE;

	ble_conn_params_change_conn_params(&gap_conn_params_high);
			


}
static void gap_params_low(void) {
	ble_gap_conn_params_t gap_conn_params_low;

	gp=true;
	memset(&gap_conn_params_low, 0, sizeof(gap_conn_params_low));

		gap_conn_params_low.min_conn_interval = MIN_CONN_INTERVAL;
		gap_conn_params_low.slave_latency = SLAVE_LATENCY;
		gap_conn_params_low.conn_sup_timeout = CONN_SUP_TIMEOUT;
	ble_conn_params_change_conn_params(&gap_conn_params_low);

			


}

This is my case in on_ble_evt

case BLE_GAP_EVT_CONN_PARAM_UPDATE:
		
		app_timer_start(m_cp_timer_id, CP_INTERVAL,
						NULL);

			break;

This is my button handler

static void button_event_handler(uint8_t pin_no, uint8_t button_action) {
	
     app_timer_stop(m_powermanage_timer_id);
         if (gp){
		gap_params_high();
	          }



	/*Joue le son du Buzzer*/
	set_frequency_and_duty_cycle((uint32_t) (1075), 50);
	nrf_delay_ms(300);
	nrf_pwm_set_enabled(0);

	switch (pin_no) {
	case BOUTON_SONNETTE_PIN_NO:


                ble_lbs_on_button_change(&m_lbs,button_action);

		nrf_gpio_pin_write(LED_LCD_PIN, 1);

		gotoXY(12,2);
		LCDString("Bienvenue",1);

		break;


	default:

		break;
	}

app_timer_start(m_powermanage_timer_id, POWER_MANAGE_INTERVAL,
				NULL);
gp=false;
pm=false;}

gp is a static bool that I use because the event handler is called 2 times ( on push and release)

pm is also a static bool that I use to not go into power manage as long as the smartphone send write(in the handler of some characteristics)

RE: Quick connection parameters update

Ziran — Wed, 06 Aug 2014 06:51:30 GMT

So this morning it's worse than yesterday. It's not even sending the good parameters the second time to go back to slow connection parameters . And I've also seen that the button change is called 2 time when pushed and realeased , I don't know why.

RE: Quick connection parameters update

Ziran — Wed, 06 Aug 2014 06:47:17 GMT

In the Log window in the Master Control Panel their is nothing . It's like the call is not done.

[08:44:27.8]Received Connection Parameter Update Request

[08:44:27.8]ConnectionParameterUpdateResponse sent with ACCEPTED response

[08:44:27.8]Connection Parameters Update sent. ConnInterval:100.0ms, SlaveLatency:0, SupervisionTimeout:600.0ms

[08:44:28.3]Received a HandleValueNotification on handle 000E with value 01

[08:44:28.7]Received a HandleValueNotification on handle 000E with value 00

[08:44:38.4] Received Connection Parameter Update Request

[08:44:38.4] ConnectionParameterUpdateResponse sent with ACCEPTED response

[08:44:38.4] Connection Parameters Update sent. ConnInterval:100.0ms, SlaveLatency:0, SupervisionTimeout:600.0ms

[08:44:56.5]Received a HandleValueNotification on handle 000E with value 01

[08:44:56.9] Received a HandleValueNotification on handle 000E with value 00

RE: Quick connection parameters update

Knut Eldhuset — Wed, 06 Aug 2014 05:22:29 GMT

What do you mean when you say that you can't change the connection parameters? Do you mean that you do the API call successfully, but nothing happens, or do you get an error code from the API call? Please check that you don't get an error code when trying to change parameters.

RE: Quick connection parameters update

Ziran — Tue, 05 Aug 2014 14:59:26 GMT

i have some other problems now. The first one is that when I change the connection parameters (Smartphone one to my quick ones then quick to slow) I can't change it anymore by calling ble_conn_params_change_conn_params. i do this with a timer that is called each time in BLE_GAP_EVT_CONN_PARAM_UPDATE

the second one is that when I call the change from Quick to slow in the Master control Panel I can see that it's doing 2 same request within 20ms gap and both are accepted(weird).

And the last one is that if after the connection and FIRST_CONN_PARAMS_UPDATE_DELAY is passed I can't change the connection parameters anymore.

for the last one I tought to solve the problem by sending connection parameter update when it's connected .

RE: Quick connection parameters update

Knut Eldhuset — Tue, 05 Aug 2014 13:33:52 GMT

Correct me if I'm wrong, but I don't think this solves OP's problem. The question is how to get notification sent as quickly as possible when having a long connection interval. OP is trying to change from long to short connection interval and then sending notification, which has the 6 connection interval delay. This can be solved by choosing a suitable shorter connection interval and slave latency.

This would be similar to a HID over GATT scenario.

RE: Quick connection parameters update

Stefan Birnir Sverrisson — Tue, 05 Aug 2014 13:24:33 GMT

You can adjust when the connection parameter update request is sent from the peripheral to the central. How that is done is described here. In many nRF51 SDK examples, e.g. the heart rate example (ble_app_hrs), the connection parameter update request is sent some time after you enable services on the peripheral device. Services are enabled when the central writes to the CCCD characteristics on the peripheral to make the peripheral start sending notifications/indications to the central. When services are enabled, the application receives a BLE_GATTS_EVT_WRITE event from the softdevice which is captured in the ble_conn_params_on_ble_evt function. The connection parameter negotiation proceidure is then started by calling the conn_params_negotiation() function which starts a timer which starts the connection parameter negotiation procedure after FIRST_CONN_PARAMS_UPDATE_DELAY milliseconds. The first step in the connection parameter negotiation procedure is sending connection parameter update request to the central.

So in order to start the connection parameter negotiation procedure on a button press, simply call the conn_params_negotiation() function from your button handler instead and set the FIRST_CONN_PARAMS_UPDATE_DELAY to relatively short number to make the delay small from the time the button is pressed until the connection parameter update request is actually sent.

RE: Quick connection parameters update

Pål Håland — Tue, 05 Aug 2014 11:21:27 GMT

what about having 250ms conn interval and 3 slave latency? Then you would have 1s sleep usually when the peripheral don't have anything to send, and 250ms latency when it does.

RE: Quick connection parameters update

Ziran — Tue, 05 Aug 2014 10:15:32 GMT

Thks for the reply ^^ My "low" connection parameters are 1s for the max interval connection and 3 slave latency . How high could I go for the Slave latency for maximum current economy ?

RE: Quick connection parameters update

Knut Eldhuset — Tue, 05 Aug 2014 09:34:00 GMT

Hi,

The Bluetooth spec says that the master should allow a minimum of 6 connection events before the new connection parameters are applied. This could easily amount to 10s, depending on the old connection interval.

You could try using a short connection interval and increasing slave latency to send the notifications more quickly. This would also conserve power.